<figure><img src="image_1.png" /></figure>

HAL
open science

Association des utilisateurs dans les réseaux mobiles flexibles et agiles

Romain Pujol

► To cite this version:

Romain Pujol. Association des utilisateurs dans les réseaux mobiles flexibles et agiles. Réseaux et télécommunications [cs.NI]. Université de Lyon, 2022. Français. NNT: 2022LYSEI063. tel-03859479

HAL Id: tel-03859479

https://theses.hal.science/tel-03859479

Submitted on 18 Nov 2022

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.
# THÈSE de DOCTORAT DE L'UNIVERSITÉ DE LYON

opérée au sein de
**INSA Lyon**

École Doctorale EDA 512
**InfoMaths**

**Spécialité/ discipline de doctorat :**
Informatique

Soutenue publiquement le 06/07/2022, par :
**Romain Pujol**

## **Association des Utilisateurs dans les Réseaux Mobiles, Flexibles et Agiles**

Devant le jury composé de :

ALI YAHIA, Tara
CONAN, Vania

Maître de Conférences HDR
Habilité à Diriger des Recherches

Université Paris Saclay
Thales

Rapporteure
Rapporteur

VEQUE, Véronique
LAUNAY, Frédéric
FRENOT, Stéphane
BEYLOT, André-Luc

Professeur des Universités
Maître de Conférences
Professeur des Universités
Professeur des Universités

Université Paris Saclay
IUT de Poitiers
INSA-LYON
ENSEEIHT

Examinatrice
Examinateur
Examinateur
Examinateur

VALOIS, Fabrice
STANICA, Razvan

Professeur des Universités
Maître de Conférences HDR

INSA-LYON
INSA-LYON

Directeur de thèse
Co-directeur de thèse
Département FEDORA – INSA Lyon - Ecoles Doctorales

<table><thead><tr><td>SIGLE</td><td>ECOLE DOCTORALE</td><td>NOM ET COORDONNEES DU RESPONSABLE</td></tr></thead><tbody><tr><td>CHIMIE</td><td>CHIMIE DE LYON<br>https://www.edchimie-lyon.fr<br>Sec.: Renée EL MELHEM<br>Bât: Blaise PASCAL, 3e étage<br>secretariat@edchimie-lyon.fr</td><td>M. Stéphane DANIELE<br>C2P2-CPE LYON-UMR 5265<br>Bâtiment F308, BP 2077<br>43 Boulevard du 11 novembre 1918<br>69616 Villeurbanne<br>directeur@edchimie-lyon.fr</td></tr><tr><td>E.E.A.</td><td>ÉLECTRONIQUE, ÉLECTROTECHNIQUE, AUTOMATIQUE<br>https://edeea.universite-lyon.fr<br>Sec.: Stéphanie CAUVIN<br>Bâtiment Direction INSA Lyon<br>Tél: 04.72.43.71.70<br>secretariat.edeea@insa-lyon.fr</td><td>M. Philippe DELACHARTRE<br>INSA LYON<br>Laboratoire CREATIS<br>Bâtiment Blaise Pascal, 7 avenue Jean Capelle<br>69621 Villeurbanne CEDEX<br>Tél: 04.72.43.88.63<br>philippe.delachartre@insa-lyon.fr</td></tr><tr><td>E2M2</td><td>ÉVOLUTION, ÉCOSYSTÈME, MICROBIOLOGIE, MODÉLISATION<br>http://e2m2.universite-lyon.fr<br>Sec.: Bénédicte LANZA<br>Bât. Atrium, UCB Lyon 1<br>Tél: 04.72.44.83.62<br>secretariat.e2m2@univ-lyon1.fr</td><td>Mme Sandrine CHARLES<br>Université Claude Bernard Lyon 1<br>UFR Biosciences<br>Bâtiment Mendel<br>43, boulevard du 11 novembre 1918<br>69622 Villeurbanne CEDEX<br>sandrine.charles@univ-lyon1.fr</td></tr><tr><td>EDISS</td><td>INTERDISCIPLINAIRE SCIENCES-SANTÉ<br>http://ediss.universite-lyon.fr<br>Sec.: Bénédicte LANZA<br>Bât. Atrium, UCB Lyon 1<br>Tél: 04.72.44.83.62<br>secretariat.ediss@univ-lyon1.fr</td><td>Mme Sylvie RICARD-BLUM<br>Institut de Chimie et Biochimie Moléculaires et Supramoléculaires<br>(ICBMS) - UMR 5246 CNRS - Université Lyon 1<br>Bâtiment Raulin - 2ème étage Nord<br>43 Boulevard du 11 novembre 1918<br>69622 Villeurbanne Cedex<br>Tél: +33(0)4 72 44 82 32<br>sylvie.ricard-blum@univ-lyon1.fr</td></tr><tr><td>INFOMATHS</td><td>INFORMATIQUE ET MATHÉMATIQUES<br>http://edinfomaths.universite-lyon.fr<br>Sec.: Renée EL MELHEM<br>Bât: Blaise PASCAL, 3e étage<br>Tél: 04.72.43.80.46<br>infomaths@univ-lyon1.fr</td><td>M. Hamamache KHEDDOUCI<br>Université Claude Bernard Lyon 1<br>Bât. Nautibus<br>43, Boulevard du 11 novembre 1918<br>69 622 Villeurbanne Cedex France<br>Tél: 04.72.44.83.69<br>hamamache.kheddouci@univ-lyon1.fr</td></tr><tr><td>Matériaux</td><td>MATÉRIAUX DE LYON<br>http://ed34.universite-lyon.fr<br>Sec.: Yann DE ORDENANA<br>Tél: 04.72.18.62.44<br>yann.de-ordenana@ec-lyon.fr</td><td>M. Stéphane BENAYOUN<br>Ecole Centrale de Lyon<br>Laboratoire LTDS<br>36 avenue Guy de Collongue<br>69134 Ecully CEDEX<br>Tél: 04.72.18.64.37<br>stephane.benayoun@ec-lyon.fr</td></tr><tr><td>MEGA</td><td>MÉCANIQUE, ÉNERGÉTIQUE, GÉNIE CIVIL, ACOUSTIQUE<br>http://edmega.universite-lyon.fr<br>Sec.: Stéphanie CAUVIN<br>Tél: 04.72.43.71.70<br>Bâtiment Direction INSA Lyon<br>mega@insa-lyon.fr</td><td>M. Jocelyn BONJOUR<br>INSA Lyon<br>Laboratoire CETHIL<br>Bâtiment Sadi-Carnot<br>9, rue de la Physique<br>69621 Villeurbanne CEDEX<br>jocelyn.bonjour@insa-lyon.fr</td></tr><tr><td>ScSo</td><td>ScSo*<br>https://edsciencessociales.universite-lyon.fr<br>Sec.: Mélina FAVETON<br>INSA: J.Y. TOUSSAINT<br>Tél: 04.78.69.77.79<br>melina.faveton@univ-lyon2.fr</td><td>M. Christian MONTES<br>Université Lumière Lyon 2<br>86 Rue Pasteur<br>69365 Lyon CEDEX 07<br>christian.montes@univ-lyon2.fr</td></tr></tbody></table>

<footnote>*ScSo: Histoire, Géographie, Aménagement, Urbanisme, Archéologie, Science politique, Sociologie, Anthropologie</footnote>
# Table des matières

## 1 Introduction 1

1.1 Contexte 1

1.1.1 Les réseaux classiques 1

1.1.2 Les réseaux hétérogènes 2

1.1.3 Les réseaux auto-déployables 2

1.1.4 Les réseaux cellulaires non terrestres 3

1.1.5 L'évolution des besoins 4

1.2 Motivations 4

1.3 Plan et contributions 5

## 2 Association dans les réseaux cellulaires, limites et évolutions 9

2.1 Introduction 9

2.2 L'association meilleur SINR 10

2.2.1 Pourquoi l'association est-elle réalisée en fonction du SINR? 10

2.2.2 Détails techniques et procédures associées 10

La recherche de fréquences 11

La synchronisation en temps et en fréquence 11

Le décodage du MIB 11

La détection des signaux de référence 11

Le décodage des SIBs 12

La sélection de cellule 12

La procédure d'accès aléatoire au canal (RACH) 13

2.3 Les limites et défis de l'association 15

2.4 Nouveaux concepts d'associations 16

2.4.1 L'association orientée lien backhaul 17

2.4.2 L'association orientée qualité de service 17

2.4.3 L'association orientée mobilité 18

2.4.4 L'association de groupe 19

2.5 Conclusion 19

## 3 État de l'art 21

3.1 Introduction 21

3.2 L'évolution des réseaux cellulaires vers plus de flexibilité et d'hétérogénéité 22

3.2.1 Vers la virtualisation de certains composants 22

3.2.2 Vers un déploiement rapide 22

3.2.3 Le défi de la couverture des stations de base mobiles 24

3.2.4 Le défi de la capacité des liens entre stations de base mobiles 24

3.3 Études sur l'association 25

3.3.1 Formulation mathématique des défis de l'association 26

3.3.2 Apprentissage par machine 27

3.3.3 L'association pour la qualité de service 28

3.3.4 L'association dans les réseaux hétérogènes 28
<table><tbody><tr><td>3.4</td><td>L'association avec partage d'informations</td><td>30</td></tr><tr><td>3.5</td><td>Conclusion</td><td>31</td></tr><tr><td><b>4</b></td><td><b>Plateforme srsRAN</b></td><td><b>33</b></td></tr><tr><td>4.1</td><td>Introduction à srsRAN</td><td>33</td></tr><tr><td>4.2</td><td>L'utilisation de srsRAN dans la littérature</td><td>34</td></tr><tr><td>4.3</td><td>Les éléments de srsRAN</td><td>35</td></tr><tr><td>4.3.1</td><td>srsEPC</td><td>35</td></tr><tr><td>4.3.2</td><td>srsENB</td><td>37</td></tr><tr><td>4.3.3</td><td>srsUE</td><td>38</td></tr><tr><td>4.4</td><td>Les éléments complémentaires</td><td>39</td></tr><tr><td>4.4.1</td><td>Les radios logicielles USRP</td><td>39</td></tr><tr><td>4.4.2</td><td>Cartes SIMs programmables</td><td>39</td></tr><tr><td>4.5</td><td>Création d'une plateforme expérimentale avec srsRAN</td><td>42</td></tr><tr><td>4.5.1</td><td>Les enjeux</td><td>42</td></tr><tr><td>4.5.2</td><td>Installation</td><td>44</td></tr><tr><td>4.5.3</td><td>Validation du fonctionnement</td><td>46</td></tr><tr><td>4.5.4</td><td>Retour d'expérience de l'installation</td><td>49</td></tr><tr><td></td><td>L'installation des pilotes logiciels</td><td>49</td></tr><tr><td></td><td>Changer le mode de performance du processeur</td><td>50</td></tr><tr><td></td><td>Passer des arguments en ligne de commande</td><td>50</td></tr><tr><td></td><td>Allocation des adresses IPs.</td><td>50</td></tr><tr><td>4.6</td><td>Les scénarios de mesure</td><td>51</td></tr><tr><td>4.6.1</td><td>Un besoin de répétabilité et de reproductibilité</td><td>51</td></tr><tr><td>4.6.2</td><td>L'automatisation des mesures</td><td>51</td></tr><tr><td>4.6.3</td><td>Détail d'une itération de boucle</td><td>52</td></tr><tr><td>4.6.4</td><td>Retour d'expérience sur les scénarios de mesure</td><td>54</td></tr><tr><td>4.7</td><td>Conclusion</td><td>54</td></tr><tr><td><b>5</b></td><td><b>Limite de l'association actuelle</b></td><td><b>57</b></td></tr><tr><td>5.1</td><td>Introduction</td><td>57</td></tr><tr><td>5.2</td><td>Sélection de cellules</td><td>57</td></tr><tr><td>5.2.1</td><td>Critère de sélection de cellules S</td><td>58</td></tr><tr><td>5.2.2</td><td>Rang des cellules R</td><td>59</td></tr><tr><td>5.2.3</td><td>La sélection de cellules influencée par des offsets</td><td>60</td></tr><tr><td>5.3</td><td>Mise en place de l'expérimentation</td><td>62</td></tr><tr><td>5.3.1</td><td>Les éléments utilisés et leur placement</td><td>62</td></tr><tr><td>5.3.2</td><td>Les différentes configurations évaluées</td><td>64</td></tr><tr><td>5.3.3</td><td>Mesure du débit et l'outil Iperf</td><td>64</td></tr><tr><td>5.4</td><td>Résultats</td><td>66</td></tr><tr><td>5.4.1</td><td>Évolution du débit moyen</td><td>66</td></tr><tr><td>5.4.2</td><td>Évolution du RSRP</td><td>69</td></tr><tr><td>5.5</td><td>Étude des limites</td><td>71</td></tr><tr><td>5.6</td><td>Conclusion et perspectives</td><td>73</td></tr><tr><td><b>6</b></td><td><b>Association avec facteur de charge</b></td><td><b>75</b></td></tr><tr><td>6.1</td><td>Introduction</td><td>75</td></tr><tr><td>6.2</td><td>Le facteur de charge, une information de charge</td><td>75</td></tr><tr><td>6.2.1</td><td>Les PRB (Physical Resource Blocks) ou les REs (Resource Elements)</td><td>75</td></tr><tr><td>6.2.2</td><td>Les RNTIs (Radio Network Temporary Identifiers)</td><td>76</td></tr></tbody></table>
<table>
  <tbody>
    <tr>
      <td>6.2.3 Les Downlink Control Information (DCIs)</td>
      <td>76</td>
    </tr>
    <tr>
      <td>6.3 Les moyens de diffuser le facteur de charge</td>
      <td>77</td>
    </tr>
    <tr>
      <td>6.3.1 Le Master Information Block (MIB)</td>
      <td>77</td>
    </tr>
    <tr>
      <td>6.3.2 Les System Information Blocks (SIBs)</td>
      <td>79</td>
    </tr>
    <tr>
      <td>6.4 Architecture de srsRAN</td>
      <td>79</td>
    </tr>
    <tr>
      <td>6.5 Proposition d'une nouvelle sélection de cellules avec srsRAN</td>
      <td>81</td>
    </tr>
    <tr>
      <td>6.5.1 Sélection de cellule et classement des cellules voisines</td>
      <td>81</td>
    </tr>
    <tr>
      <td>6.5.2 Utiliser le nombre de RNTIs comme facteur de charge</td>
      <td>82</td>
    </tr>
    <tr>
      <td>6.6 Modification du MIB de srsRAN</td>
      <td>85</td>
    </tr>
    <tr>
      <td>6.7 Etude des limites de l'association avec facteur de charge</td>
      <td>86</td>
    </tr>
    <tr>
      <td>6.7.1 Les différentes sélections de cellules étudiées</td>
      <td>86</td>
    </tr>
    <tr>
      <td>RSRP</td>
      <td>86</td>
    </tr>
    <tr>
      <td>PRBs -&gt; RSRP</td>
      <td>86</td>
    </tr>
    <tr>
      <td>PRBs (borne sup)</td>
      <td>87</td>
    </tr>
    <tr>
      <td>RNTI -&gt; RSRP</td>
      <td>87</td>
    </tr>
    <tr>
      <td>RNTI (borne sup)</td>
      <td>87</td>
    </tr>
    <tr>
      <td>PRBs -&gt; RNTI -&gt; RSRP</td>
      <td>87</td>
    </tr>
    <tr>
      <td>RNTI -&gt; PRBs -&gt; RSRP</td>
      <td>87</td>
    </tr>
    <tr>
      <td>6.7.2 Le scénario des simulations et résultats</td>
      <td>87</td>
    </tr>
    <tr>
      <td>6.7.3 Le tri par RNTI</td>
      <td>88</td>
    </tr>
    <tr>
      <td>6.7.4 Le tri par PRBs</td>
      <td>89</td>
    </tr>
    <tr>
      <td>6.7.5 Les tris avec mélange de métriques</td>
      <td>89</td>
    </tr>
    <tr>
      <td>6.7.6 Distribution des débits</td>
      <td>90</td>
    </tr>
    <tr>
      <td>6.8 Conclusion</td>
      <td>91</td>
    </tr>
    <tr>
      <td><b>7 Conclusion et perspectives</b></td>
      <td><b>93</b></td>
    </tr>
    <tr>
      <td>7.1 Résumé</td>
      <td>93</td>
    </tr>
    <tr>
      <td>7.2 Perspectives</td>
      <td>94</td>
    </tr>
    <tr>
      <td>7.2.1 Évaluation de performances</td>
      <td>94</td>
    </tr>
    <tr>
      <td>7.2.2 Étude des métriques et du placement du facteur de charge</td>
      <td>94</td>
    </tr>
    <tr>
      <td>7.2.3 L'association vers une hétérogénéité des réseaux</td>
      <td>94</td>
    </tr>
    <tr>
      <td><b>A Résultats des mesures du chapitre 5</b></td>
      <td><b>97</b></td>
    </tr>
    <tr>
      <td><b>Bibliographie</b></td>
      <td><b>109</b></td>
    </tr>
  </tbody>
</table>
Table des figures

<table><tr><td>1.1 Réseau cellulaire classique.</td><td>2</td></tr><tr><td>1.2 Réseau cellulaire hétérogène.</td><td>3</td></tr><tr><td>1.3 Réseau cellulaire auto-déployable.</td><td>3</td></tr><tr><td>1.4 Réseau cellulaire satellite.</td><td>4</td></tr><tr><td>2.1 L'association meilleur SINR.</td><td>9</td></tr><tr><td>2.2 La procédure de sélection de cellule.</td><td>14</td></tr><tr><td>2.3 La procédure RACH.</td><td>15</td></tr><tr><td>2.4 La diffusion d'informations au service de l'association.</td><td>17</td></tr><tr><td>2.5 L'association orientée lien backhaul.</td><td>17</td></tr><tr><td>2.6 L'association orientée qualité de service.</td><td>18</td></tr><tr><td>2.7 Déclenchement d'une procédure de changement de cellule suite aux déplacement de deux BS.</td><td>18</td></tr><tr><td>2.8 L'association de groupe.</td><td>19</td></tr><tr><td>3.1 Version allégée d'un EPC embarqué sur un drone.</td><td>22</td></tr><tr><td>4.1 Architecture du cœur de réseau émulé par srsRAN</td><td>35</td></tr><tr><td>4.2 Vue d'ensemble des éléments utilisés.</td><td>40</td></tr><tr><td>4.3 Cartes SIMs programmables et lecteurs.</td><td>40</td></tr><tr><td>4.4 Structure des données à modifier dans le programme en C pour modifier le contenu de la carte SIM.</td><td>41</td></tr><tr><td>4.5 Exécution du programme d'écriture de carte SIM.</td><td>42</td></tr><tr><td>4.6 Exemple du contenu du fichier de config user_db.csv.</td><td>42</td></tr><tr><td>4.7 Carte SIM programmée pour notre réseau srsRAN et test de débit.</td><td>43</td></tr><tr><td>4.8 Plateforme expérimentale srsRAN.</td><td>43</td></tr><tr><td>4.9 Baie de brassage de la salle de TP.</td><td>44</td></tr><tr><td>4.10 Fichier /etc/network/interfaces.</td><td>46</td></tr><tr><td>4.11 Répartition des PRBs d'un eNB entre deux smartphones sur 19 secondes.</td><td>47</td></tr><tr><td>4.12 Répartition des PRBs et REs d'un eNB entre deux smartphones sur 100 millisecondes.</td><td>48</td></tr><tr><td>4.13 Exemple d'exécution de srsUE en ligne de commande sous Python.</td><td>50</td></tr><tr><td>4.14 Chronogramme d'une itération d'un scénario de mesure.</td><td>53</td></tr><tr><td>5.1 Éléments de ressources hébergeant les signaux de références.</td><td>58</td></tr><tr><td>5.2 Capture d'image du fichier .pcap de l'eNB faisant apparaître la diffusion de l'offset Qrxlev<sub>min</sub>.</td><td>61</td></tr><tr><td>5.3 USRP NI-2901 et ses 2 antennes VERT 2450</td><td>63</td></tr><tr><td>5.4 Plan du placement des éléments dans la salle.</td><td>63</td></tr><tr><td>5.5 Contenu du fichier de configuration de la base de données HSS.</td><td>65</td></tr><tr><td>5.6 Matrices des débits moyens et RSRP moyens mesurés.</td><td>67</td></tr><tr><td>5.7 Matrices des SNRs et MCSs moyens mesurés.</td><td>68</td></tr></table>
<table><tr><td>6.1</td><td>Capture d'écran du MIB défini dans le document TS 136 331 de la 3GPP.</td><td>78</td></tr><tr><td>6.2</td><td>Le MIB et ses répétitions.</td><td>78</td></tr><tr><td>6.3</td><td>La requête de SIBs en 5G.</td><td>79</td></tr><tr><td>6.4</td><td>Languages informatiques utilisés dans le projet srsRAN.</td><td>80</td></tr><tr><td>6.5</td><td>Structuration du code source srsRAN 19.</td><td>81</td></tr><tr><td>6.6</td><td>La procédure de tri dans le fichier "rrc_cell.cc" de srsRAN.</td><td>83</td></tr><tr><td>6.7</td><td>Modification de srsRAN pour propager l'information du nombre d'UEs à l'état RRC connecté.</td><td>84</td></tr><tr><td>6.8</td><td>L'encodage du facteur de charge et du MIB dans le canal PBCH par l'eNB.</td><td>85</td></tr><tr><td>6.9</td><td>Le décodage du facteur de charge et du MIB par l'UE.</td><td>86</td></tr><tr><td>6.10</td><td>Taux de meilleure sélection des tris commençant par trier les cellules par RNTIs.</td><td>88</td></tr><tr><td>6.11</td><td>Taux de meilleure sélection des tris commençant par trier les cellules par PRBs.</td><td>89</td></tr><tr><td>6.12</td><td>Comparaison du taux de meilleure sélection des tris PRBs -> RNTI -> RSRP et RNTI -> PRBs -> RSRP).</td><td>90</td></tr><tr><td>6.13</td><td>Résultats préliminaire du gain en débit obtenu par notre proposition de tri comparé au tri RSRP.</td><td>90</td></tr><tr><td>A.1</td><td>Débit moyen mesuré pour 1 UE.</td><td>97</td></tr><tr><td>A.2</td><td>RSRP moyen mesuré pour 1 UE.</td><td>98</td></tr><tr><td>A.3</td><td>SNR moyen mesuré pour 1 UE.</td><td>98</td></tr><tr><td>A.4</td><td>MCS moyen mesuré pour 1 UE.</td><td>99</td></tr><tr><td>A.5</td><td>Débit moyen mesuré pour 2 UEs.</td><td>99</td></tr><tr><td>A.6</td><td>RSRP moyen mesuré pour 2 UEs.</td><td>100</td></tr><tr><td>A.7</td><td>SNR moyen mesuré pour 2 UEs.</td><td>100</td></tr><tr><td>A.8</td><td>MCS moyen mesuré pour 2 UEs.</td><td>101</td></tr><tr><td>A.9</td><td>Débit moyen mesuré pour 3 UEs.</td><td>101</td></tr><tr><td>A.10</td><td>RSRP moyen mesuré pour 3 UEs.</td><td>102</td></tr><tr><td>A.11</td><td>SNR moyen mesuré pour 3 UEs.</td><td>102</td></tr><tr><td>A.12</td><td>MCS moyen mesuré pour 3 UEs.</td><td>103</td></tr><tr><td>A.13</td><td>Débit moyen mesuré pour 4 UEs.</td><td>103</td></tr><tr><td>A.14</td><td>RSRP moyen mesuré pour 4 UEs.</td><td>104</td></tr><tr><td>A.15</td><td>SNR moyen mesuré pour 4 UEs.</td><td>104</td></tr><tr><td>A.16</td><td>MCS moyen mesuré pour 4 UEs.</td><td>105</td></tr><tr><td>A.17</td><td>Débit moyen mesuré pour 5 UEs.</td><td>105</td></tr><tr><td>A.18</td><td>RSRP moyen mesuré pour 5 UEs.</td><td>106</td></tr><tr><td>A.19</td><td>SNR moyen mesuré pour 5 UEs.</td><td>106</td></tr><tr><td>A.20</td><td>MCS moyen mesuré pour 5 UEs.</td><td>107</td></tr></table>
## Liste des tableaux

<table><tr><td>2.1</td><td>Liste des principaux SIBs et de leur contenu.</td><td>13</td></tr><tr><td>4.1</td><td>Contenu modifiable pour l'EPC dans le fichier de configuration epc.conf.</td><td>36</td></tr><tr><td>4.2</td><td>Contenu modifiable de la base de donnée HSS dans le fichier user_db.csv.</td><td>36</td></tr><tr><td>4.3</td><td>Contenu modifiable pour l'eNB dans le fichier de configuration enb.conf.</td><td>37</td></tr><tr><td>4.4</td><td>Contenu du SIB1 dans le fichier de configuration sib.conf.</td><td>38</td></tr><tr><td>4.5</td><td>Contenu modifiable pour l'UE dans le fichier de configuration ue.conf.</td><td>39</td></tr><tr><td>4.6</td><td>Radio configuration of the eNB.</td><td>46</td></tr><tr><td>4.7</td><td>Allocation des adresses IPs.</td><td>51</td></tr><tr><td>5.1</td><td>Variables utilisées pour le calcul du critère S.</td><td>59</td></tr><tr><td>5.2</td><td>Variables utilisées pour le calcul du rang R.</td><td>60</td></tr><tr><td>5.3</td><td>Liste des configurations de la cellule.</td><td>64</td></tr><tr><td>5.4</td><td>Différences de débits et RSRP entre les configurations A et B.</td><td>70</td></tr><tr><td>5.5</td><td>Différences de débits et RSRP entre les configurations A, B et C alors que le nombre d'UEs est fixe.</td><td>70</td></tr><tr><td>5.6</td><td>Nombre de combinaisons de k éléments parmi 140 sans remise.</td><td>72</td></tr><tr><td>5.7</td><td>Pourcentage de réussite du tri des cellules par types de tris réalisés.</td><td>72</td></tr><tr><td>6.1</td><td>Pourcentage de réussite du tri des cellules par types de tris réalisés.</td><td>88</td></tr></table>
# Liste des Abréviations

**2G** Deuxième génération de réseaux cellulaires

**3G** Troisième génération de réseaux cellulaires

**3GPP** 3rd Generation Partnership Project

**4G** Quatrième génération de réseaux cellulaires

**5G** Cinquième génération de réseaux cellulaires

**6G** Sixième génération de réseaux cellulaires

**BS** Base Sation - Station de base

**CN** Core Network - Cœur de réseau

**DCI** Downlink Control Information -
Information de contrôle sur le lien descendant

**DNS** Domain Name -System

**DL** DownLink - Lien descendant

**eNodeB** evolved **NodeB** - Station de base 4G

**eNB** evolved **NodeB** - Station de base 4G

**EARFCN** E-UTRA Absolute Radio Frequency Channel Number

**EPC** Evolved Packet Core - Cœur de réseau 4G

**GPRS** General Packet Radio Service

**GSM** Groupe Spécial Mobile

**HetNet** Heterogeneous Network - Réseau hétérogène

**HPLMN** Home Public Mobile Land Network

**HSS** Home Subscriber Server

**IMEI** International Mobile Equipment Identity -
Identifiant international unique de l'appareil

**IMSI** International Mobile Subscriber Identity -
Identifiant international unique de l'abonné

**ISM** Industrial Scientific Medical

**LTE** Long Term Evolution

**MCC** Mobile and Country Code - Code du pays

**MCS** Modulation and Coding Scheme - Modulation et schéma de codage

**MIB** Master Information Block - Bloc d'information principal

**MME** Mobility Management Unit

**MNC** Mobile and Network Code - Code du réseau

**NAS** Non Access Stratum

**NB-IoT** NarrowBand Internet of Things

**PDN** Packet Data Network - Réseau de données par paquets

**P-GW** Packet data network **GateWay** -
Portail vers le réseau de données par paquets

**PBCH** Physical Broadcast Channel - Canal physique de diffusion

**PLMN** Public Mobile Land Network

**PRB** Physical Resource Block - Bloc de ressource physique

**PDCCH** Physical Downlink Control **CHannel** -
Canal descendant physique de contrôle

**PDSCH** Physical Downlink Shared **CHannel** -
<table><tr><td></td><td>Canal descendant physique partagé</td></tr><tr><td>PSS</td><td>Primary Synchronization Signal - Premier signal de synchronisation</td></tr><tr><td>PUSCH</td><td>Physical Uplink Shared CHannel - Canal montant physique partagé</td></tr><tr><td>QCI</td><td>QoS Class Identifier - Classe de service</td></tr><tr><td>QoE</td><td>Quality of Experience - Qualité d'expérience</td></tr><tr><td>QoS</td><td>Quality of Service - Qualité de service</td></tr><tr><td>RACH</td><td>Random Access CHannel - Canal d'accès aléatoire</td></tr><tr><td>RAN</td><td>Radio Access Stratum - Réseau d'accès</td></tr><tr><td>RNTI</td><td>Radio Network Temporary Identifier - Identifiant temporaire du réseau d'accès</td></tr><tr><td>RRC</td><td>Radio Ressource Control</td></tr><tr><td>RSRP</td><td>Reference Signal Receive Power - Puissance du signal de référence</td></tr><tr><td>RSRQ</td><td>Reference Signal Receive Quality - Qualité du signal de référence</td></tr><tr><td>S-GW</td><td>Serving GateWay - Passerelle de service</td></tr><tr><td>SIB</td><td>System Information Block - Bloc d'information système</td></tr><tr><td>SIM</td><td>Subscriber Identity Module - Module d'identité utilisateur</td></tr><tr><td>SINR</td><td>Signal to Interference and Noise Ratio - Rapport signal sur interférences plus bruit</td></tr><tr><td>SMS</td><td>Short Message Service</td></tr><tr><td>srsENB</td><td>software radio systems ENB - logiciel d'émulation d'eNB par srsRAN</td></tr><tr><td>srsEPC</td><td>software radio systems EPC - logiciel d'émulation d'EPC par srsRAN</td></tr><tr><td>srsLTE</td><td>software radio systems LTE</td></tr><tr><td>srsRAN</td><td>software radio systems RAN</td></tr><tr><td>srsUE</td><td>software radio systems UE - logiciel d'émulation d'UE par srsRAN</td></tr><tr><td>SSS</td><td>Secondary Synchronization Signal - Second signal de synchronisation</td></tr><tr><td>TAC</td><td>Tracking Area Code - Zone de localisation</td></tr><tr><td>TCP</td><td>Transmission Control Protocol - Protocole de contrôle de transmissions</td></tr><tr><td>TMSI</td><td>Temporary Mobile Subscriber Identity - Identité temporaire de l'abonné</td></tr><tr><td>TP</td><td>Travaux Pratiques</td></tr><tr><td>UE</td><td>User Equipement - Équipement utilisateur</td></tr><tr><td>UL</td><td>UpLink - Lien montant</td></tr><tr><td>USRP</td><td>Universal Software Radio Peripheral - Périphérique universel de radio</td></tr><tr><td>UMTS</td><td>Universal Mobile Telecommunication System</td></tr><tr><td>VoIP</td><td>Voice over IP - Voix sur IP</td></tr><tr><td>VoLTE</td><td>Voice over LTE - Voix sur LTE</td></tr></table>
# Chapitre 1

# Introduction

## 1.1 Contexte

Les réseaux cellulaires ont connu leur premier essor avec le déploiement du réseau cellulaire GSM dans les années 90's. À l'époque, ce réseau avait pour principal objectif de fournir un service de communication de la voix grâce à un circuit commuté de bout en bout. Au déploiement de ce réseau, le taux de couverture était l'une des principales priorités des opérateurs, car les stations de bases étaient plus dispersées qu'aujourd'hui. Le processus d'association des utilisateurs au réseau d'accès pour cette technologie se basait déjà sur la mesure de la puissance obtenue de la part de chacune des stations de base voisine à l'équipement utilisateur (UE) pour choisir avec quelle station il était préférable de s'associer, afin d'assurer une bonne continuité de service.

Depuis, les utilisateurs et leurs applications ont besoin de données mobiles et ces besoins tendent aujourd'hui encore vers plus de débit et moins de latence. Plusieurs technologies de réseaux cellulaires se sont enchaînées jusqu'à ce jour, en passant de la 3G à la 4G [1], pour aujourd'hui suivre par le déploiement de la 5G par les opérateurs téléphoniques en France [2].

L'évolution des réseaux cellulaires et de leurs applications ne semble pas pour autant être arrivée à son terme. La course à la sixième génération de réseaux mobiles (6G) est déjà lancée [3].

Alors que les technologies cellulaires se cumulent, puisque les plus anciennes technologies sont toujours utilisées[4], le processus d'association des utilisateurs doit faire face à une hétérogénéité grandissante des réseaux cellulaires. Les réseaux cellulaires actuels peuvent se décliner sous plusieurs formes. Et chacune de ces formes apporte un peu plus de contraintes que l'association doit être capable de gérer.

### 1.1.1 Les réseaux classiques

Comme le montre la figure 1.1, le réseau cellulaire classique, quelle que soit la technologie utilisée, est construit autour de trois briques principales. La première est le réseau d'accès (RAN), composé de stations de bases (BS) qui fournissent et gèrent des ressources radios aux UEs. La deuxième partie est le cœur de réseau (CN), responsable entre autres de l'authentification des utilisateurs, de la mise en place des services, du routage des données et de la gestion de la mobilité des utilisateurs. La dernière brique quant à elle est le réseau de données par paquets (PDN) fournissant des services de données tel que l'accès Internet par exemple.
<figure><img src="image_2.png" /><figcaption>FIGURE 1.1 – Réseau cellulaire classique.</figcaption></figure>

### 1.1.2 Les réseaux hétérogènes

Les réseaux hétérogènes sont composés des mêmes briques que le réseau classique mais leur principale différence intervient au niveau du RAN. Ici le RAN est constitué de plusieurs types de BSs, de différentes capacités, portées et puissances d'émissions. Elles sont appelées, ainsi que la zone qu'elle recouvrent, macrocellule, picocellule ou femtocellule en fonction de leur portée, leur puissance d'émission et leur taille, respectivement décroissantes. Ces cellules sont superposées dans l'espace et les plus petites sont généralement placées sous les plus grosses afin de les délester de leur charge ou de combler leurs trous de couvertures.

Les réseaux hétérogènes sont principalement déployés en milieu urbain. Ils sont une réponse à la mobilité des utilisateurs, au besoin de capacité et au manque de couverture dans des zones restreintes. Les utilisateurs s'associent alors généralement à la picocellule la plus proche, si leur mobilité est nulle, ou à la macrocellule si leur mobilité est forte. Le processus d'association se réalise toujours en fonction de la puissance du signal reçu par l'UE mais est biaisée par des offsets configurés statiquement par les opérateurs pour favoriser l'association aux picocellules, dont la puissance d'émission est plus faible que celle des macrocellules.

Dans les réseaux hétérogènes, la mobilité vient aujourd'hui des utilisateurs qui se déplacent sous les BSs mais dans un futur proche on pourrait imaginer avoir des BSs, de tailles différentes, être équipées sur des unités mobiles tels que des voitures [5]. Le processus d'association devra alors prendre cette double mobilité des utilisateurs et des BSs en compte.

### 1.1.3 Les réseaux auto-déployables

Les réseaux auto-déployables sont des réseaux mobiles développés premièrement à des fins militaires et pour des opérations de secours [6], mais également pour apporter de la couverture lors d'évènements sportifs [7] ou autres regroupant un important volume de personnes à un endroit donné. Dans ces réseaux, le cœur de réseau est co-localisé avec les BSs [8][9] et les deux sont embarqués sur des équipements mobiles, tels que des drones, des voitures ou même un sac à dos.

Dans ces réseaux, les fonctionnalités du CN sont réparties entre les équipements mobiles [10]. Ici le lien entre les BSs est également sans fil et ces liens doivent véhiculer à la fois le trafic du plan utilisateur et le trafic du plan de contrôle, en plus des ressources qui doivent être attribués aux UEs[11]. Les liens radio sont donc ici très
<figure><img src="image_3.png" /><figcaption>FIGURE 1.2 – Réseau cellulaire hétérogène.</figcaption></figure>

fortement sollicités et l'association actuelle des utilisateurs ne prend pas du tout en compte l'état de ces liens.

<figure><img src="image_4.png" /><figcaption>FIGURE 1.3 – Réseau cellulaire auto-déployable.</figcaption></figure>

### 1.1.4 Les réseaux cellulaires non terrestres

Même si certains projets ne se sont pas montrés concluants, tel que le projet Loon [12], ils n'en restent pas moins des exemples d'évolution possible des réseaux cellulaires. Dans cet exemple, le but n'est pas de construire un réseau cellulaire, mais un réseau apportant une connexion Internet à des endroits peu desservis du globe. Des passerelles d'accès sont placées sur des ballons gonflés à l'hélium et qui sont reliés les unes aux autres ainsi qu'au sol par une connexion sans fil. L'objectif de ce projet semblait prometteur mais a connu un échec pour des raisons de viabilité économique.

Dans le même contexte, certaines entreprises envoient dans l'espace des satellites afin d'apporter une connexion Internet pour peu que l'on s'équipe d'une antenne de réception capable de recevoir le signal [13]. Ne pourrait-on pas imaginer un futur des réseaux cellulaires dans lesquels les BSs flotteraient autour de la Terre, comme donné en exemple dans la figure 1.4 ? Et si c'était le cas, l'association actuelle serait-elle pertinente pour assurer aux UEs la meilleure connectivité possible pour eux et leurs applications mobiles ?
<figure><img src="image_5.png" /><figcaption>FIGURE 1.4 – Réseau cellulaire satellite.</figcaption></figure>

### 1.1.5 L'évolution des besoins

Tous ces exemples montrent que les architectures des réseaux cellulaires évoluent. Cependant les besoins des utilisateurs évoluent également. La technologie GSM ouvrait la voie avec un service voix et GPRS, son extension, ouvrait les réseaux cellulaires vers l'utilisation de données mobiles. Nous sommes passés en près de 30 ans de besoins à obtenir des données sur la météo du jour à des besoins de visionnage de vidéos en streaming plusieurs heures par jour, à des besoins de jeux en ligne nécessitant une très faible latence. Nous avons toujours besoin d'une couverture omniprésente du réseau mais la densité des BSs augmentant il ne s'agit plus d'un défi majeur aujourd'hui. Nous avons en revanche, au vu de l'augmentation de la consommation en termes de données mobiles de chacun, des besoins de contrôle du trafic et de la congestion des réseaux. Nous avons également besoin d'une gestion de la mobilité de plus en plus efficace, non pas au vu de l'évolution de la mobilité des utilisateurs uniquement, mais également au vu de l'évolution de la mobilité des équipements du réseau eux-mêmes.

Et pourtant, quels que soient les besoins, les scénarios ou l'architecture du réseau, l'association reste la même et est basée sur le même principe qu'à sa création pour GSM qui ne proposait à l'origine que de la voix.

## 1.2 Motivations

Cette évolution des réseaux décrite précédemment est intrinsèquement liée à l'évolution des besoins des utilisateurs et des applications des utilisateurs. L'association des utilisateurs dans tous ces réseaux, conçue à l'origine pour des réseaux ne fournissant que des applications de voix et de SMS, n'a que peu évolué depuis. Et même si ce mécanisme a depuis été modifié par l'ajout de diverses valeurs de compensation fixées arbitrairement par l'opérateur, cette association est toujours construite autour de la mesure de la puissance du signal reçu par l'UE. Cette mesure de puissance n'apporte des informations que sur la qualité du lien radio et non sur les éventuelles difficultés que va rencontrer la station de base à desservir un utilisateur de plus. Cette constatation nous amène à nous demander comment faire évoluer l'association pour répondre aux besoins ciblés par les réseaux cellulaires
d'aujourd'hui et de demain, en tenant compte à la fois de la capacité offerte et des besoins applicatifs toujours plus important.

Notre contribution dans cette thèse est de montrer que l'association actuelle est agnostique des besoins en bande passante des applications des utilisateurs. Que l'association peut être revisitée pour répondre à des besoins plus récents, propres à l'évolution des réseaux cellulaires. Pour cela nous avons besoin d'étudier le comportement actuel de l'association et de comprendre son fonctionnement, afin de déterminer des leviers d'interactions et de modifications possibles. Nous devons également nous renseigner sur les travaux déjà réalisés par la communauté et confronter nos points de vue sur ce qui doit être modifié dans l'association actuelle.

Nous montrons également que l'association actuelle ne répond plus aux besoins des utilisateurs et de la qualité de service exigée par les applications des utilisateurs, toujours de plus en plus consommatrices en bande passante. Nous concentrons nos efforts sur l'évaluation des performances du réseau d'accès en terme de débit sur le lien descendant obtenu au terme du processus d'association actuel. Nous proposons des résultats expérimentaux grâce à l'utilisation de la suite logicielle srsRAN, partant du constat que la littérature manque de résultats expérimentaux dans ce domaine.

Nous proposons ensuite d'introduire une nouvelle métrique à l'association, le *facteur de charge*. Le facteur de charge est diffusé par la station de base et indique une valeur de charge de cette dernière, permettant d'améliorer de 22% le nombre de fois où l'association se conclue en choisissant la cellule fournissant le meilleur débit. Ces résultats sont obtenus de manière expérimentale suite à des modifications de la suite logicielle srsRAN. À notre connaissance, il s'agit d'une contribution très rare dans la littérature que de proposer une implémentation expérimentale et une modification du fonctionnement du réseau cellulaire 4G pour valider une proposition. Nous ajoutons le facteur de charge dans les mécanismes de diffusion de la station de base et dans le mécanisme de sélection de cellule côté UE. Nous implémentons directement notre solution au sein de la suite logicielle srsRAN et prouvons que cette notion de facteur de charge n'est pas seulement théorique, mais pourrait être entièrement implémentée dès aujourd'hui dans les normes 4G et 5G.

## 1.3 Plan et contributions

Dans le chapitre 2, nous discutons des mécanismes de l'association dans les détails, afin de bien comprendre son fonctionnement. Nous présentons les différents protocoles impliqués dans le processus, ainsi que les différents messages échangés entre l'UE et la station de base. Nous parlons du processus de sélection de cellule, du classement des cellules voisines détectées et des mesures réalisées par l'UE. Suite à cela, nous sommes en mesure de mener une discussion sur l'évolution possible et souhaitée de l'association dans les réseaux cellulaires actuels et futurs. Nous proposons quelques pistes d'évolution de l'association en fonction de plusieurs besoins des nouveaux réseaux cellulaires et expliquons comment ces problèmes peuvent être traités dès l'association.

Dans le chapitre 3, nous présentons les papiers de la littérature qui traitent dans un premier temps de l'évolution des réseaux cellulaires et, dans un deuxième temps, plus particulièrement ceux qui traitent de l'évolution des réseaux hétérogènes. Ces études des réseaux hétérogènes représentent une importante partie des travaux de la littérature car ils apportent un grand nombre de nouveaux défis à relever. Nous présentons ensuite les travaux liés à l'association et à son amélioration. Parmi ces
travaux se trouvent des papiers traitant de l'optimisation de l'association dans le cadre de réseaux hétérogènes. Nous concentrons ensuite notre présentation de la littérature vers des contributions qui, comme nous, pensent que l'association doit être revisitée et que le cœur de réseau et la station de base doivent fournir plus d'information à l'UE pour lui permettre de faire un choix plus adapté de la station de base avec laquelle s'associer. Nous présentons enfin quelques outils de mesure de charge que l'UE peut utiliser pour être informé de la capacité restante des cellules qui lui sont voisines. Nous présentons également des outils d'expérimentations dans les réseaux cellulaires tels que srsRAN, qui permet d'émuler un réseau cellulaire LTE complet, et qui est très souvent utilisé par la communauté dans des travaux s'appuyant sur des résultats expérimentaux.

Dans le chapitre 4, nous expliquons notre choix et notre besoin de mettre en
place une plateforme LTE expérimentale complète. Cette plateforme sera fondée au-
tour de l'utilisation de la suite logicielle libre srsRAN. Ce chapitre a pour but de
détailer les points clefs à mettre en œuvre dans la mise en place d'une telle pla-
teforme. Le premier passe par un bonne compréhension du fonctionnement et de
l'utilisation de la suite logicielle srsRAN. Puis de la présentation des équipements
matériels utilisés et utilisables avec la plateforme. Ensuite nous montrons comment
cette plateforme a servi à la réalisation de nombreuses mesures de débits pour les
travaux présentés dans les chapitres suivants. Nous détaillons la mise en place des
différents éléments qui interviennent dans ces mesures et la mise en œuvre de leur
automatisation afin de laisser ces expérimentations se dérouler en semi-autonomie.
Nous appuyions donc sur les besoins d'automatiser certains aspects de cette pla-
teforme dans le cadre des travaux expérimentaux de cette thèse et travaux futurs,
mais également dans le cadre d'utilisation de cette plateforme pour le département
Télécommunications de l'INSA Lyon dans un contexte pédagogique.

Dans le chapitre 5, nous étudions les limites de l'association actuelle. Pour cela,
nous nous basons sur les résultats d'expérimentations menées sur notre plateforme
srsRAN. L'objectif des mesures réalisées ici est de déterminer expérimentalement
quel est le débit applicatif obtenu par l'UE en fonction de diverses configurations
de la station de base et en fonction du nombre d'UEs exploitant en même temps les
ressources de la station. Ces variations dans les configurations de la station de base
consistent en une variation de la puissance d'émission de la station ainsi qu'une
variation de sa bande passante. Nous expliquons donc dans un premier temps le
détails des mesures qui ont été réalisées. Nous étudions ensuite les résultats obte-
nus et discutons des observations faites sur ces résultats par rapport à nos attentes.
Nous utilisons ensuite les résultats obtenus comme une base pour étudier les limites
de l'association actuelle. Nous montrons, dans une simulation reproduisant le com-
portement de la sélection de cellule réalisée lors de l'association actuelle, que cette
sélection de cellule, basée uniquement sur la puissance du signal reçu, classe en pre-
mière place la cellule qui lui fournirait le meilleur débit dans seulement 41% des
cas si quatre autres utilisateurs sont déjà en train de trafiquer sur la cellule. Nous
discutons suite à ces résultats du besoin d'introduire dans la sélection de cellule de
nouvelles métriques pour réaliser le classement des cellules voisines lors de la sélec-
tion de cellule.

Dans le chapitre 6, suite aux conclusions tirées du chapitre 5, nous expliquons
une nouvelle fois le besoin de faire transmettre par la station de base une informa-
tion sur la capacité restante de cette dernière. Dans le cas où l'UE a des besoins
importants en bande passante pour ses applications, il doit pouvoir être en mesure
de faire un choix pertinent de cellule à laquelle s'associer dans les réseaux modernes
et futurs. Nous discutons quelles sont les manières possibles de diffuser actuellement une information de charge et revenons sur la définition de ce qu'est une bonne information de charge. Nous faisons ensuite le choix de modifier le code source de srsRAN pour mettre en place la diffusion d'un facteur de charge pour pouvoir une nouvelle fois évaluer expérimentalement son impact sur la sélection de cellule et le classement des cellules voisines qui est réalisé par l'UE. Nous utilisons pour cela les résultats expérimentaux précédents et réalisons une nouvelle simulation de classement de cellule, cette fois en fonction d'une information de charge obtenue par notre version modifiée de l'UE de srsRAN. Nous discutons ici également de l'impact qu'apporte cette diffusion d'un facteur de charge sur la sélection de cellule et donc l'association en comparaison avec l'association classique actuelle.

Dans un dernier chapitre nous apportons nos conclusions sur ces travaux et réalisons un liste de pistes de travaux qui peuvent succéder à ces travaux ainsi qu'une liste de compléments qui peuvent être apportés aux travaux actuels.
# Chapitre 2

# Association dans les réseaux cellulaires, limites et évolutions

## 2.1 Introduction

Parmi les technologies de réseaux cellulaires sur le marché au jour de l'écriture de ce manuscrit, la technologie 4G est la plus utilisée et la plus déployée pour les réseaux commerciaux [4]. Les réseaux cellulaires traditionnels comme le réseau LTE ont une séparation claire entre le réseau d'accès (RAN) et le cœur de réseau (CN) [14] (voir figure 1.1). La partie RAN du réseau consiste en de multiples BSs qui fournissent aux UEs un lien radio, des ressources de communication et leur permettent d'atteindre le cœur du réseau, et de là, les services demandés. La partie CN, quant à elle, consiste essentiellement en une agrégation de services regroupés dans des serveurs de l'opérateur qui assurent l'interconnexion entre les BS et les réseaux des autres opérateurs. L'EPC (Evolved Packet Core), nom du CN 4G, est responsable du routage du trafic de l'UE vers le bon service, le bon destinataire. Il s'occupe des mécanismes de sécurité, de l'identification et de l'authentification des utilisateurs. Il est également responsable de la mobilité de l'utilisateur, d'une BS à une autre, durant sa vie au sein du réseau.

L'association des utilisateurs intervient dans la partie RAN du réseau. Il s'agit de l'étape qui consiste, pour l'UE, à choisir une BS autour de lui à laquelle il va demander une réservation de ressources radios. Dans les réseaux 4G, mais également dans les technologies précédentes, l'association des UEs est communément appelée "association meilleur SINR", car l'UE choisit de demander des ressources à la BS dont il mesure la plus forte puissance de signal [15] (voir figure 2.1).

<figure><img src="image_6.png" /><figcaption>FIGURE 2.1 – L'association meilleur SINR.</figcaption></figure>

Cependant, ce mécanisme d'association meilleur SINR est agnostique des besoins de qualité de service des utilisateurs et de leurs applications. Il ne prend pas
en compte la possible mobilité des BS et leur capacité restante. Ce mécanisme résulte
en une association sous optimale, un gaspillage des ressources radios et une faible
performance des applications. Le taux de blocage ainsi que le nombre de change-
ments de cellule résultant de cette association peuvent être importants puisque l'on
ne prend pas en compte la capacité restante de la BS. Nous pensons que cette ap-
proche classique de l'association doit être améliorée pour répondre aux besoins des
applications des utilisateurs au plus tôt de leur arrivée dans le réseau.

Dans ce chapitre, nous ferons premièrement le point sur le mécanisme d'asso-
ciation classique actuel, basé sur la mesure de la puissance du signal reçu. Dans
une deuxième partie nous expliquerons quelles sont ses limites dans des contextes
particuliers d'architectures de réseaux cellulaires. Dans une dernière partie, nous
introduirons des concepts originaux pour concevoir de nouveaux mécanismes d'as-
sociations répondant à des besoins ciblés des utilisateurs et des opérateurs.

## 2.2 L'association meilleur SINR

2.2.1 Pourquoi l'association est-elle réalisée en fonction du SINR ?

L'association basée sur le meilleur SINR mesuré par l'utilisateur est celle utilisée
dans les réseaux cellulaires depuis des décennies, y compris dans le réseau LTE.
Facile à implémenter, facile à gérer, facile à configurer, il n'y a, a priori, pas beaucoup
de raisons de changer ce mécanisme. Le SINR indique une information sur la qualité
du lien radio entre l'UE et la BS. Hors, plus la qualité du lien est bonne, plus il
est possible d'envoyer de bits à la seconde sans rencontrer d'erreur de décodage
de l'information. Le MCS (Modulation and Coding Scheme) est un indicateur du
type de codage et de modulation utilisé pour générer les symboles échangés entre
l'UE et la BS sur le lien radio en fonction de la qualité du lien radio. Le MCS défini
donc combien de bits peuvent être transmis par symbole. Plus la qualité du lien
radio est bonne, plus la valeur du MCS utilisé augmente et plus le nombre de bits
transmis est élevé. À l'inverse, moins la qualité du lien est bonne, plus la valeur
du MCS utilisé est faible et moins le nombre de bits transmis est élevé. L'utilisation
aujourd'hui de l'association basée sur le meilleur SINR a donc un sens, puisqu'elle
se base indirectement sur la quantité de bits par symbole qui pourront être transmis
sur le lien radio. Cependant nous pensons que l'association doit évoluer vers un
partage de beaucoup plus d'informations que seulement la qualité du lien radio et
nous expliquons pourquoi plus loin dans ce chapitre.

2.2.2 Détails techniques et procédures associées

Quand un UE vient d'être allumé et qu'il cherche à accéder au réseau, deux pro-
cédures sont déclenchées. La première est l'association de l'utilisateur à la meilleure
cellule convenable autour de soi. Une cellule convenable est définie comme une cel-
lule qui appartient à l'opérateur téléphonique de l'utilisateur, ou HPLMN (Home
Public Land Mobile Network), et qui fournit un signal d'une puissance suffisante
pour l'UE. Une cellule acceptable est définie comme une cellule qui n'appartient pas
à l'opérateur téléphonique de l'utilisateur mais qui fournit un signal d'une puissance
suffisante pour l'UE. La deuxième procédure est l'attachement, composée des étapes
d'identification et d'authentification de l'abonné par le CN. À la fin d'une procédure
réussie, un UE est dit attaché au réseau, configuré avec une adresse IP lui permet-
tant d'accéder aux différents services du réseau. Le CN garde en permanence en
mémoire dans une base de données la localisation de l'UE, pour pouvoir le joindre
rapidement en cas d'appel de la part d'un autre utilisateur ou en cas d'arrivée de données. La procédure de réveil d'un UE lorsque celui-ci ne trafique plus depuis un certain temps, pour lui demander de réceptionner le trafic entrant, est connue sous le nom de procédure de paging. Le standard 3GPP TS 24.301 [16] apporte plus de détail sur les procédures d'attachement et de paging.

Après avoir été allumé, l'UE scanne la fréquence d'émission de la dernière BS avec laquelle il était associé avant d'avoir été éteint. Si aucune BS de l'opérateur téléphonique souscrit n'est trouvée, l'UE regarde les informations présentes sur sa carte SIM pour récupérer une liste de fréquences dont l'opérateur a les droits d'utilisation. Ceci est connu sous le nom anglais de "Stored Information Cell Selection". Si aucune cellule convenable n'est trouvée sur cette liste de fréquences, le processus de sélection de cellule initial commence. Plus de détails sur les procédures de l'UE à l'état de veille peuvent être trouvés dans le fichier technique 3GPP TS 36.304 [17]. La suite décrit les différentes étapes qu'un UE doit suivre depuis le démarrage de l'équipement jusqu'à la procédure d'accès aléatoire au canal (RACH) qui permet à l'UE d'obtenir des ressources radio depuis la BS.

### La recherche de fréquences

L'UE scanne la liste de fréquences stockée dans sa carte SIM ou bien scanne la totalité des fréquences allouées au spectre radio LTE, dans la limite des capacités accordées à l'UE lors de sa commercialisation.

### La synchronisation en temps et en fréquence

L'UE scanne chaque fréquence à la recherche d'une modulation spécifique du signal diffusé par la BS. Ce signal est un point de synchronisation connu par l'UE et la BS qui leur permettent de se caler sur la même échelle de temps et de fréquence. L'UE connaît ainsi la position de chacun des éléments de ressources de la BS sur les axes temps/fréquence ainsi que la position de début de la prochaine trame LTE.

### Le décodage du MIB

En décodant le signal précédent, l'UE s'est synchronisé en temps et fréquence. Il connaît donc la position exacte du MIB (Master Information Block), qui est un bloc d'information diffusé périodiquement par la BS dans laquelle sont contenues plusieurs informations tel que la bande passante de la BS, le numéro de la sous-trame actuelle et d'autres informations aidant à la synchronisation des autres canaux logiques. Le contenu du MIB est présenté plus en détail dans le chapitre 6 de ce manuscrit.

### La détection des signaux de référence

Grâce au MIB encore une fois, l'UE connaît l'emplacement de plusieurs blocs temps fréquence qui ne sont là que pour servir de signaux de référence. Ces blocs sont répartis de manière stratégique sur toute la bande passante de la BS et répartis dans le temps également. Ils permettent à l'UE de mesurer la qualité du signal obtenue sur la globalité de la BS. Deux valeurs sont calculées à partir de la mesure de puissance du signal fourni sur ces blocs. La première est le RSRP (Reference Signal Received Power) qui quantifie la puissance globale fournie par la BS sur tout le spectre et la deuxième est le RSRQ (Reference Signal Received Quality) qui elle
quantifie la qualité du signal et le rapport entre la force du signal de la BS et celle
des interférences.

Le décodage des SIBs

Les SIBs (System Information Blocks) sont également des blocs de ressources ra-
dios transmis périodiquement par la BS. Ils contiennent des informations de contrôle
variées sur le système, comme le PLMN (Public Mobile Land Network). Le PLMN
est l'identifiant de l'opérateur téléphonique dans le réseau. Chaque opérateur pos-
sède un ou plusieurs identifiants composés de deux éléments, le MCC (Mobile Coun-
try Code) qui est le code du pays et le MNC (Mobile Network Code) qui est le code
de l'opérateur dans le pays. Une liste des codes de la majorité des opérateurs peut,
à l'heure de l'écriture de ce manuscrit, être trouvée sur le site web [18]. Il existe plu-
sieurs SIBs différents ayant chacun leur rôle. Les SIB1 et SIB2 sont indispensables
alors que les suivants sont facultatifs et c'est à l'opérateur de choisir de les implé-
menter ou non. Il y a au total une vingtaine de SIBs facultatifs.

Le SIB1 contient les éléments suivants :

- L'identifiant PLMN de l'opérateur.

- L'identifiant de la BS.

- Le RSRP minimal à mesurer par l'UE pour pouvoir demander l'accès à la BS.

- Une liste de tous les autres SIBs diffusés par la BS ainsi que leur emplacement.

La valeur minimale de puissance que doit mesurer l'UE est utilisée pour s'as-
surer d'une qualité minimale du lien pour entamer la communication. Cette valeur
peut avoir un second usage dans les réseaux hétérogènes, possédant macro, pico et
femto cellules. Elle permet, en jouant sur cette valeur minimale, de décharger les
utilisateurs de la macrocellule vers des cellules émettant bien moins fort mais étant
également bien moins chargées et beaucoup plus proches.

Le SIB2 contient des informations de configuration des ressources radio qui sont
communes à tous les UEs.

Les autres SIBs pour la plupart contiennent d'autres informations très spécifiques
sur la BS ou certains services qu'elle peut fournir (voir table 2.1). D'autres apportent
des informations sur la présence de cellules voisines de l'opérateur à proximité ou
encore des valeurs à utiliser lors de la procédure de résélection de cellule. Les SIB10
et SIB11 eux, par exemple, diffusent les messages d'alerte en cas de tremblement
de terre ou de tsunami. C'est grâce à la diffusion de ces messages d'informations,
qui ne demandent même pas à l'utilisateur du réseau d'y être authentifié, que sont
transmis les messages du système public d'alerte mentionné plus tôt.

La sélection de cellule

Dans le cas où la première cellule trouvée ne serait pas une cellule convenable,
ou bien après avoir réalisé que cette cellule nous fournit en réalité de bien piètres
performances, la sélection de cellule initiale peut commencer. L'UE cherche alors
sur toutes les fréquences du spectre LTE les éventuelles cellules qui seraient actives,
récupère leur identifiant PLMN et mesure les valeurs de RSRP et RSRQ. L'UE classe
chacune des cellules trouvées par ordre décroissant des valeurs de RSRP mesurées.
S'il a besoin de communiquer, l'UE parcourt alors cette liste dans l'ordre et tente
de s'associer à la première cellule de la liste qui appartiendrait au PLMN de son
opérateur ou aux opérateurs ayant passé des accords de roaming avec cet opérateur.
S'il ne parvient pas à s'associer, l'UE choisit l'élément suivant dans la liste, s'il a le
bon PLMN, et ainsi de suite jusqu'à réussir l'association ou atteindre le bas de la
<table><caption>TABLE 2.1 – Liste des principaux SIBs et de leur contenu.</caption><thead><tr><th></th><th>Contenu du SIB</th></tr></thead><tbody><tr><td>SIB 1</td><td>Informations générales sur la cellule et le réseau.</td></tr><tr><td>SIB 2</td><td>Informations de configurations des canaux logiques.</td></tr><tr><td>SIB 3</td><td>Paramètres généraux pour la résélection intrafréquentielle.</td></tr><tr><td>SIB 4</td><td>Paramètres plus précis, pour la résélection intrafréquentielle, par cellule voisine.</td></tr><tr><td>SIB 5</td><td>Paramètres pour la résélection interfréquentielle.</td></tr><tr><td>SIB 6</td><td>Informations de résélection entre cellules UMTS et LTE.</td></tr><tr><td>SIB 7</td><td>Informations de résélection entre cellules GSM et LTE.</td></tr><tr><td>SIB 8</td><td>Informations de résélection entre cellules CDMA2000 et LTE.</td></tr><tr><td>SIB 9</td><td>Informations additionnelles si la cellule est une pico ou femto cellule.</td></tr><tr><td>SIB 10</td><td>Informations primaires propres au système d'alerte de tremblement de terre et de tsunami.</td></tr><tr><td>SIB 11</td><td>Informations secondaires propres au système d'alerte de tremblement de terre et de tsunami.</td></tr><tr><td>SIB 12</td><td>Informations propres au système d'alerte mobile commercial.</td></tr></tbody></table>

liste. Si le bas de la liste est atteint, il réessaie l'opération en choisissant cette fois les BSs n'appartenant pas à son opérateur ou n'étant pas des opérateurs partenaires. Cependant, il n'obtiendra que le droit de passer des appels d'urgences mais pourra tout de même être à l'écoute des messages d'alertes diffusés par les SIBs 10, 11 et 12 de cette BS. Une cellule d'un autre opérateur téléphonique fournissant un signal suffisamment élevé sera appelée "cellule acceptable". La figure 2.2 est une figure extraite et représentant les étapes précédemment décrites du fichier technique 3GPP TS 36.304 [17]. Le mécanisme de classement des cellules est étudié plus en détail dans le chapitre 5 de ce manuscrit.

## La procédure d'accès aléatoire au canal (RACH)

La procédure d'accès aléatoire au canal contient quatre étapes. Il s'agit d'une procédure à base de contention pour gérer les éventuelles tentatives de connexion simultanées des utilisateurs (voir figure 2.3).

- Premièrement, l'UE envoie sur le canal réservé à l'accès aléatoire l'un des 64 préambules possibles et connus des deux entités.

- Deuxièmement, la BS répond en donnant à l'UE un identifiant temporaire, le RNTI (Radio Network Temporary Identifier), et en lui indiquant les ressources radio qui lui sont réservées pour son prochain envoi sur le canal PUSCH (Physical Uplink Shared CHanel).

- Troisièmement, tous les UEs en compétition qui auraient récupéré le message précédent essaient d'émettre leur identifiant temporaire récemment acquis (le RNTI), ainsi qu'un second identifiant unique qui permet de les différencier, le TMSI (Temporary Mobile Subscriber Identity). Cet envoi simultané résultera probablement en une collision.
<figure><img src="image_7.png" /><figcaption>FIGURE 2.2 – La procédure de sélection de cellule.</figcaption></figure>
- Dernièrement, si la BS n'est pas capable de décodeur de message (à cause d'une collision probablement), alors aucun des candidats ne reçoit de réponse et ils recommencent tous depuis le début leur procédure RACH. Si maintenant le BS réussit à décodeur un message, elle répond par un acquittement à l'utilisateur qui est à l'origine de ce message, en retournant l'identifiant unique du gagnant, son TMSI. Cet utilisateur-là est donc associé et les autres doivent recommencer leur procédure RACH.

Sur cette même figure 2.3 apparaît la procédure d'accès aléatoire dite sans contention. Cette procédure intervient lorsque le RAN, après avoir reçu le rapport des mesures de puissance des stations observées par l'UE, décide de lui imposer un changement de cellule. Cette procédure de changement de cellule est appelée "handover". On peut également faire une procédure d'accès aléatoire sans contention lorsqu'on se connecte au réseau suite à la réception d'un message de paging.

<figure><img src="image_8.png" /><figcaption>FIGURE 2.3 – La procédure RACH.</figcaption></figure>

## 2.3 Les limites et défis de l'association

Maintenant que nous comprenons mieux comment fonctionne l'association dans le réseau LTE, nous pouvons souligner quels sont les défauts de cette association.

Pour résumer l'association en LTE, l'UE essaie de trouver la première cellule de son opérateur qui possède des valeurs de RSRP et de RSRQ suffisantes. L'association est donc uniquement basée sur la force du signal. Et cela est complètement agnostique des principaux défis auxquels sont confrontés les réseaux d'aujourd'hui et de demain.

Les réseaux d'aujourd'hui, construits principalement autour des architectures classique (figure 1.1) et hétérogène (figure 1.2), présentées au chapitre précédent, véhiculent principalement trois types de trafic :

- Le trafic de voix sur IP (VoIP), avec réservation de ressources dédiées aux appels vocaux avec une certaine qualité de service.

- Le trafic de contrôle, avec réservation de ressources dédiées à l'envoi, réception de SMS, réception de messages de paging, etc.

- Le trafic de données IP, avec réservation de ressources par défaut sans qualité de service en fonction de la capacité restante de la BS.
L'association actuelle ne prend en compte que la qualité du lien radio entre l'UE et la BS. Elle ne prend pas en compte les besoins de qualité de services des applications des utilisateurs tels que le débit ou la latence requise. Un UE souhaitant regarder une vidéo en ligne peut s'associer à une cellule à la capacité saturée mais dont la qualité de signal est pourtant la meilleure. Cet UE restera soit sur cette cellule avec un débit descendant très faible pour sa vidéo, soit déclenchera un changement de cellule au sein du réseau, entraînant un surplus de trafic de contrôle pour le réseau et un délai supplémentaire pour l'utilisateur avant d'accéder à son service.

Dans les réseaux de demain, ces problématiques sont amplifiées du fait de l'hété-
rogénéité des architectures des réseaux possibles. Voici quelques exemples inspirés
des réseaux futurs présentés au chapitre précédent couplés à quelques scénarios ap-
plicatifs :

- Dans le cadre d'opérations de premiers secours utilisant des réseaux auto-déployables pour apporter de la couverture sur leur zone d'opération. Les sauveteurs veulent diffuser une vidéo de la scène pour demander des renforts adaptés. Cependant l'association ne prend pas en compte la capacité du lien sans fils limitée entre les BSs [19] et la vidéo s'en retrouve dégradée.

- Grâce à l'embarquement possible des BS dans des véhicules volants et auto-
nomes [8], les BSs sont en mouvement au-dessus des utilisateurs. L'associa-
tion ne prend pas en compte le mouvement des BS et peut associer un UE
à une BS s'éloignant. Un handover est généré dans les secondes qui suivent
créant ainsi un surplus de trafic de contrôle sur le lien d'interconnexion des
BSs.

- Dans le cadre de la virtualisation des réseaux, les BSs, le RAN ainsi que le CN peuvent être découpés en tranches virtuelles. Mais l'association ne prend pas en compte les ressources attribuées à chaque tranche ni les ressources restantes sur ces tranches.

- Dans un cadre de réseaux auto-déployables une nouvelle fois, un groupe d'intervention souhaite s'associer à la même BS pour éviter de générer du trafic sur le lien d'interconnexion, cependant l'association actuelle basée sur la puissance du signal peut les séparer sur plusieurs BSs différentes.

- Dans un cadre d'un réseau classique 5G, un utilisateur veut participer à une session de jeux en ligne et à besoin de la plus faible latence possible. Cependant l'association ne prend pas en compte la latence fournie par les BSs.

Tous ces exemples montrent que l'association actuelle, conçue à l'origine pour
assurer un lien solide et une couverture fiable pour des applications de voix n'est
plus pertinente dans la majorité des nouvelles applications des réseaux cellulaires
d'aujourd'hui et de demain. Nous pensons donc que l'association doit être revisitée
pour prendre en compte des métriques plus pertinentes dans l'évolution des réseaux
cellulaires tels que le délai d'association, le débit obtenu ou la proximité des BSs.

2.4 Nouveaux concepts d'associations

Nous présentons ci-dessous plusieurs axes d'améliorations de l'association [20],
afin d'améliorer l'accès des UEs aux ressources dont ils ont besoin, en fonction des
principaux défis apportés par l'évolution des réseaux cellulaires. La figure 2.4 montre
un exemple de ce que pourrait être une association améliorée. Il s'agit d'une diffu-
sion d'information, de la part de la BS vers les UEs, destinée à laisser à l'UE le choix
de la cellule à laquelle s'associer. L'UE peut alors choisir, en fonction des besoins né-
cessaires à ses applications et en fonction des informations obtenues par la BS, la BS
<figure><img src="image_9.png" /><figcaption>FIGURE 2.4 – La diffusion d’informations au service de l’association.</figcaption></figure>

qui lui apportera le meilleur service. Nous proposons ci-après quelques exemples
de cas dans lesquels l'association pourrait être modifiée pour apporter un plus aux
UEs ainsi qu'aux opérateurs.

2.4.1 L'association orientée lien backhaul

<figure><img src="image_10.png" /><figcaption>FIGURE 2.5 – L’association orientée lien backhaul.</figcaption></figure>

La capacité restreinte des liens backhauls dans les réseaux auto-déployables est un problème traité dans la littérature [19]. L'association peut être repensée de manière à minimiser l'utilisation générale du lien backhaul dans le réseau. Un tel mécanisme pourrait dynamiquement donner la priorité à des BSs qui auraient encore une quantité suffisante de ressources disponibles sur le lien backhaul les reliant au cœur de réseau. Cela réduirait le taux de rejet des UEs qui essaieraient de s'associer à une BS qui fournirait le meilleur SINR mais qui serait pourtant saturée sur son lien backhaul. La figure 2.5 donne en exemple un réseau pour lequel deux BSs sont reliées au CN par des liens de capacités différents. Les deux BSs sont ici capables de diffuser l'information de la capacité restante sur leurs liens backhauls respectifs et les UEs sont capables de faire le choix de s'associer à la BS qui possède la plus grande capacité.

2.4.2 L'association orientée qualité de service

Une association orientée vers la qualité de service peut se réaliser en diffusant
des informations supplémentaires tels que la capacité restante sur la BS ou la latence
<figure><img src="image_11.png" /><figcaption>FIGURE 2.6 – L'association qualité de service.</figcaption></figure>

moyenne pour accéder à un service. La BS pourrait également diffuser les informations de charge et latence des cellules voisines, de sorte à ce que l'UE prenne la décision de s'associer à la BS la plus propice à lui donner la qualité de service que nécessite l'application de l'utilisateur. La figure 2.6 donne en exemple deux UEs souhaitant respectivement utiliser une application de jeux en ligne nécessitant une faible latence et une application de visionnage de vidéos nécessitant un débit élevé. Les deux UEs choisissent ici chacun la station qui répondra au mieux à leurs besoins grâce aux informations additionnelles diffusées par les BSs.

La décision d'association pourrait également être prise par le réseau. L'UE pourrait donner durant la procédure RACH des informations sur la qualité de service qu'il souhaiterait obtenir. Le RAN pourrait alors accepter directement son association ou bien le rejeter en lui fournissant une liste des cellules voisines ayant les ressources satisfaisantes pour lui fournir ce qu'il souhaite.

C'est sur ce concept particulier de nouvelle association orientée vers la qualité de service que s'articulera le reste du manuscrit.

### 2.4.3 L'association orientée mobilité

<figure><img src="image_12.png" /><figcaption>FIGURE 2.7 – Déclenchement d'une procédure de changement de cellule suite aux déplacement de deux BS.</figcaption></figure>

Dans les réseaux non-terrestres et auto-déployables, la mobilité des BSs est très bénéfique pour l'autonomie et la flexibilité du réseau, cependant, elle apporte également son lot de contraintes. Le lien backhaul limité est un de ces inconvénients, et le fait que la qualité du lien radio entre l'UE et la BS varie dans le temps en est
un autre. Nous avons vu que l'association est basée sur la force du signal mesuré et le déplacement des BSs peut créer beaucoup de handovers (voir figure 2.7). Ces handovers accroissent la quantité de contrôle de trafic dans le réseau et décroissent par la même occasion les performances globales du réseau.

L'association des utilisateurs pourrait anticiper ou prévoir le déplacement des UEs et des BSs pour réduire ce nombre de handovers. Du point de vue de l'UE, connaître la destination de la BS pourrait améliorer le processus de sélection de celle. La BS pourrait alors encore une fois diffuser des informations sur sa trajectoire dans les secondes ou minutes à venir. D'un point de vue des BSs maintenant, le réseau lui-même pourrait faire une prédiction de la meilleure association possible s'il était en possession des informations de déplacement des UEs et des BSs. En traquant les appareils lui-même ou en récupérant les informations de mobilité des UE durant la procédure RACH, le RAN pourrait calculer quelles sont les BSs les plus profitables à chacun des UEs.

### 2.4.4 L'association de groupe

<figure><img src="image_13.png" /><figcaption>FIGURE 2.8 – L'association de groupe.</figcaption></figure>

L'association de groupe est une fonctionnalité qui pourrait être intéressante dans certains scénarios occasionnels. Si nous prenons l'exemple d'une équipe d'intervention de premiers secours qui se déplace, il serait moins efficace d'associer séparément chacun des membres d'un groupe si ces derniers se retrouvent finalement tous associés à la même BS. Effectuer une association séparée consomme plus de ressources, introduit une perte de temps et crée des collisions dans la procédure RACH. Une association de groupe garantirait également que le groupe entier soit associé à la même BS. Dans ce cas, un seul UE pourrait effectuer la procédure RACH pour le groupe entier et éviter ainsi les collisions. Le RAN pourrait alors prendre la décision de répartir les UEs entre les BSs ou pas, en fonction des informations transmises par l'UE lors de la procédure RACH. Avoir l'ensemble du groupe permettrait également de tirer profit d'une mutualisation des ressources, si les membres du groupe souscrivent tous à un même flux vidéo par exemple. Cela pourrait également limiter le trafic introduit sur le lien backhaul si les membres du groupe communiquent essentiellement entre eux sous couverture de la même BS.

## 2.5 Conclusion

Dans ce chapitre, nous avons discuté de l'association des utilisateurs dans les réseaux cellulaires, en nous appuyant sur l'association des utilisateurs pratiquée dans
le réseau LTE standard, basée sur le meilleur SINR mesuré. Nous avons montré des exemples dans lesquels l'association actuelle atteignait ses limites et ne permettait pas aux UEs de choisir les BSs qui leur conviendraient le mieux. Principalement à cause du fait que les BSs ne partagent pas d'informations sur leur capacité restante, leur mobilité et sur le support de niveaux de qualité de service.

Nous énonçons alors plusieurs concepts d'améliorations de l'association des utilisateurs applicables dans les réseaux cellulaires d'aujourd'hui et de demain. À savoir, l'association orientée lien backhaul pour parer les contraintes de topologies des réseaux auto-déployables. L'association orientée qualité de service pour orienter les UEs vers une BSs capable de répondre à leurs besoins sans générer de handovers. L'association orientée mobilité pour limiter les problèmes liés aux déplacements des UEs et des BSs. Et enfin l'association de groupe, pour réduire le coût du trafic de contrôle généré par de multiples associations et regrouper les UEs sous la même BS.

Dans la suite de ce manuscrit nous revenons dans le chapitre 5 sur les limites de l'association meilleur SINR en nous appuyant sur des résultats expérimentaux, après avoir détaillé dans le chapitre 4 la plate-forme expérimentale et le matériel utilisés. Nous proposons dans le chapitre 6 d'implémenter et d'évaluer expérimentalement l'impact de la diffusion par une BS de ses informations de charge au travers de son MIB et d'améliorer ainsi les débits descendants obtenus par les UEs du réseau suite à la sélection de cellule.
# Chapitre 3

# État de l'art

## 3.1 Introduction

La thèse de Jad Oueis [21] est le point d'entrée de ma thèse dans le domaine des réseaux cellulaires. Plusieurs travaux ont été réalisés par Jad, au sein de l'équipe Inria Agora du laboratoire CITI à l'INSA Lyon, dans un contexte de réseaux cellulaires auto-déployables [22]. Parmi ses travaux, Jad a travaillé sur la distribution des ressources en fréquence et en puissance des stations de base pour les utilisateurs [11] mais aussi sur le placement de fonctions virtuelles du cœur de réseau au sein du réseau d'accès [10]. Il propose également en [19] un mécanisme d'association visant à réduire le trafic du lien backhaul de près de 40%.

À la lecture de son manuscrit, on s'aperçoit que la préservation du lien backhaul et des ressources radio est un important défi dans les réseaux auto-déployables. Ceci est en partie dû à la mobilité des différents acteurs du réseau, l'instabilité des liens radios et la topologie dynamique propre à ces réseaux. De plus, il est fait mention que la qualité de service des applications demandées par l'utilisateur n'est pas prise en considération dans ces réseaux et que cela conduit à des performances générales du réseau réduites. Ces constatations ne sont pourtant pas exclusives aux réseaux auto-déployables et de nombreux papiers de la littérature s'attellent à proposer des solutions dans les réseaux cellulaires 4G et 5G. Nous pensons que la majorité des problèmes des réseaux auto-déployables cités précédemment peuvent être résolus dès l'arrivée des utilisateurs dans le réseau. Et nous allons montrer que l'association actuelle est agnostique de la qualité de service demandé par l'utilisateur et qu'elle ne prend pas en compte la capacité restante des stations de base et des liens backhauls. Les BSs devraient être capables de propager des informations de charge pour améliorer la prise de décision des utilisateurs lors de leur association, la charge ayant un impact direct sur les services supportés.

Ce chapitre sera structuré de la manière suivante. Dans un premier temps, nous présenterons les papiers de la littérature décrivant la construction d'un réseau auto-déployable et leur utilité, notamment dans un cadre de gestion de catastrophes naturelles. Dans une deuxième partie, nous ferons ensuite le point sur les problématiques et défis soulevés par l'utilisation de tels réseaux. Nous verrons également que la plupart de ces défis sont également étudiés dans les réseaux cellulaires traditionnels 4G et 5G. Dans un troisième temps, nous nous concentrerons sur l'association des utilisateurs et comment la répartition des utilisateurs dès leur arrivée dans le réseau peut impacter les performances du réseau et des utilisateurs. Dans un quatrième temps, nous ferons le point sur ce qu'il manque selon nous à l'association actuelle et quels sont les papiers de la littérature travaillant déjà dans cette direction qui nous semble essentielle. Finalement nous ferons la liste d'outils utilisés ou envisagés dans le cadre de nos validations expérimentales.
## 3.2 L'évolution des réseaux cellulaires vers plus de flexibilité et d'hétérogénéité

### 3.2.1 Vers la virtualisation de certains composants

Les auteurs de [8] conçoivent un logiciel, une version allégée d'EPC, ayant pour but de fonctionner à l'extrémité du réseau, embarqué sur des drones. Il s'agit d'une application SDN (Software Defined Network) regroupant les fonctionnalités minimales mais essentielles d'un MME (Mobility Management Entity), d'un SGW (Serving Gateway) et d'un PGW (Packet Data Network Gateway). La base de données HSS (Home Subscriber Server) et le PCRF (Policy and Charging Rules Function) sont quant à eux remplacés par une seule entité codée en dur au préalable. Cette application se veut être la moins énergivore possible tout en assurant de manière fiable les fonctionnalités essentielles d'un cœur de réseau. Il est alors possible d'embarquer ce logiciel directement en bordure de réseau sur plusieurs drones, déplaçant ainsi les fonctionnalités du cœur de réseau dans le réseau d'accès. Sur la figure 3.1, les auteurs de ce même papier montrent que l'on peut joindre sur un même drone leur solution logicielle ainsi qu'une BS. Il est alors possible d'obtenir un réseau autonome dont le réseau d'accès et le cœur de réseau sont fusionnés en un seul, à la bordure du réseau traditionnel. La même équipe propose cette fois une solution d'émulation et de pilotage des BSs en créant le prototype SkyRAN [9]. Cet outil est un logiciel émulant une BS et incluant un algorithme de mesure de l'environnement radio proposant par la suite un déplacement du drone sur lequel il est colocalisé. Une cartographie de la puissance des signaux reçus autour de la BS est maintenue à jour en permanence et permet de calculer le meilleur déplacement du drone à adopter. Leur solution est testée sur de réels équipements disponibles sur étagère. Ils démontrent que leur solution est capable de faire converger les drones vers le point de couverture optimal en termes de débit moyen par UE dans une fenêtre temporelle de 30 secondes.

<figure><img src="image_14.png" /><figcaption>FIGURE 3.1 – Version allégée d'un EPC embarqué sur un drone.</figcaption></figure>

### 3.2.2 Vers un déploiement rapide

Dans le papier [23], les auteurs proposent une nouvelle architecture de répartition des stations de base dans un contexte d'intervention d'une équipe de premiers
secours. Ils montrent qu'en remplaçant la majorité des stations de base fixes existantes par quelques stations mobiles seulement, on peut obtenir les mêmes performances tout en augmentant la couverture possible du réseau. Ils proposent également un mécanisme de désactivation de certaines stations de base les moins utilisées pour réduire les interférences lors du trafic des stations de base mobiles vers les stations fixes.

Dans le papier [24], les auteurs s'interrogent sur l'utilisation des ondes millimétriques comme technologie du réseau d'accès pour les communications entre stations de base et utilisateurs. Ils montrent qu'il est possible, en utilisant pas moins de 16 antennes, de créer au sol des zones géographiques de groupes de communications.

Les papiers précédents nous ont montré la possibilité de faire fonctionner un réseau LTE autonome en ajoutant en prime de la mobilité et un déploiement rapide grâce à la colocalisation des équipements sur des véhicules volants. Les papiers suivants traiteront maintenant d'applications possibles à l'utilisation de ces réseaux.

Dans un premier papier [25], les auteurs font le bilan, suite notamment à de nombreux tremblements de terre au Népal, des bénéfices que peuvent tirer les équipes d'interventions de premiers secours de l'utilisation des réseaux cellulaires 4G/LTE et 5G. Dans le papier [26], les auteurs proposent un nouveau plan d'alerte et de prévention d'incidents naturels à l'échelle nationale en Australie. Ils expliquent quel rôle les réseaux cellulaires ont à jouer dans un tel système.

Dans [6], les auteurs montrent l'intérêt d'avoir à disposition un réseau cellulaire déployable dans des scénarios de recherche de victimes dans des zones non couvertes par le réseau cellulaire standard. Ils montrent des cas d'utilisation en colocalisant des stations de base sur des drones ou un hélicoptère. Dans le papier [27], d'autres auteurs proposent une plateforme de pilotage à distance de divers véhicules volants. Cette plateforme fonctionne sans accès à Internet et permet de piloter à distance plusieurs types de véhicules volants (drones, hélicoptère, etc.) si ceux-ci sont fournis avec un programme permettant de le faire. Cette plateforme vise à centraliser le pilotage des opérations, centraliser les flux vidéos et audio émis par les véhicules volants. Cette plateforme est une base permettant d'accueillir par la suite plusieurs modules de pilotage ou de contrôle que la communauté voudra bien développer.

Le papier [28] propose un algorithme de découverte de points d'intérêts et d'auto-organisation d'une flotte de véhicules volants permettant d'assurer la connectivité de chacun de ces points avec le cœur de réseau. Cette solution dénommée VESPA s'inspire beaucoup des solutions de collecte de données de l'IoT pour l'appliquer en-suite dans un cadre de gestion de désastre et de secours aux personnes. Une validation de cette solution est proposée par simulation et par comparaisons avec d'autres algorithmes de collecte de données similaires.

Dans le papier [29], les auteurs développent une application qui permet des communications saut à saut entre utilisateurs de l'application et le réseau cellulaire traditionnel. Ils expliquent également la bonne pratique d'utilisation de ce logiciel et comment cela pourrait servir à d'éventuelles victimes d'accidents qui se retrouveraient isolées du réseau cellulaire. Ces victimes pourraient alors créer un réseau multisaut entre eux et jusqu'à la station de base la plus proche permettant ainsi aux équipes d'interventions d'être notifiées de leur présence.
### 3.2.3 Le défi de la couverture des stations de base mobiles

Un objectif commun à tous les réseaux cellulaires est historiquement d'assurer aux utilisateurs une couverture radio continue, quelle que soit leur mobilité au sein du réseau et d'assurer une continuité de service sans coupure. Dans le cadre de gestion de catastrophes naturelles, suite à l'éventuelle destruction des réseaux de communications classiques, il est souvent mentionné l'utilisation de véhicules aériens pour pallier à cette infrastructure détruite. Le placement de ces véhicules, est en réalité un des principaux défis des réseaux auto-déployables. Les papiers suivants de la littérature se proposent d'essayer de traiter ce placement des véhicules volants au mieux ainsi que d'améliorer la couverture offerte par ces derniers.

L'habilitation à diriger la recherche d'Enrico Natalizio [30] recense plusieurs travaux autour d'un même axe de recherche qui est l'utilisation des drones dans les réseaux de communication sans fils. Parmi ces travaux on notera notamment la mise en place d'un outil de simulation de déplacement et de communications entre drones ainsi que diverses études de mobilité des drones et d'amélioration de la couverture de zones géographiques lors de la collecte de données.

Dans le papier [31], les auteurs utilisent la force d'attraction de Coulomb pour émuler l'attraction de stations de base mobiles par les utilisateurs afin de maximiser la couverture des stations de base. Les stations de base se repoussent entre elles pour éviter de toutes se regrouper sur un même point mais sont attirées par les utilisateurs pour couvrir au mieux les zones d'intérêts. Dans un second papier [7], les même auteurs montrent un exemple d'architecture d'un réseau auto-dépayable avec tous les éléments nécessaires pour apporter une couverture cellulaire lors d'un évènement sportif large échelle. La durée de vie des drones utilisés étant estimée de l'ordre de 15 minutes, leur contribution ici consiste à proposer un mécanisme de remplacement de drone qui assure la continuité de service sans coupure pour les utilisateurs.

Une étude est réalisée en [32], pour déterminer quel est le nombre minimal de drones nécessaires pour couvrir une zone et quel doit être le placement de ces drones dans un espace 3D pour réaliser un tel objectif. Une validation de la méthode proposée est réalisée par simulation. Dans le papier [33], les auteurs proposent une méthode de prédiction de mobilité d'un groupe d'utilisateurs pour ensuite permettre à une station de base embarquée par un drone de suivre plus efficacement ce groupe. Une validation de cette méthode est également proposée par simulation. Dans [34], les auteurs proposent de déterminer quel serait le meilleur placement de stations de base par apprentissage profond par renforcement. L'objectif étant de placer les stations de manière à apporter une couverture la plus large possible sans jamais créer de rupture de service pour les utilisateurs au sol lors de leur mobilité.

### 3.2.4 Le défi de la capacité des liens entre stations de base mobiles

Dans les réseaux cellulaires auto-déployables, la connectivité entre les BSs et le cœur de réseau utilise très souvent les mêmes ressources radio sans fils que le RAN [22]. Là où historiquement le lien backhaul est un lien filaire souvent approvisionné, il peut ici devenir un goulot d'étranglement pour les communications. Les papiers suivants visent par plusieurs moyens différents à améliorer l'utilisation de ces ressources sans fils en améliorant parfois d'autres métriques au sein du réseau.

L'objectif du papier [35] est de présenter une solution qui permettrait à un réseau cellulaire auto-déployable d'utiliser les équipements utilisateurs comme des relais
afin d'améliorer la latence dans ces réseaux et décharger les liens backhauls. Les eNBs (evolved NodeBs) étant généralement peu nombreux et disséminés sur des larges distances, il n'est pas rare de voir les liens entre les eNBs proches du cœur du réseau être saturés.

Les auteurs de [36] proposent une amélioration des eNBs pour y rajouter la possibilité d'avoir un trafic point à point entre ces derniers. Cette amélioration permet d'ajouter des communications saut à saut entre eNBs sans avoir à atteindre le cœur de réseau. Cette solution baptisée e2NB est compatible avec l'utilisation du réseau LTE actuel et une émulation de la solution est réalisée en utilisant la plateforme OpenAirInterface [37].

Les auteurs de [38] expliquent ici les différences de débit que peuvent atteindre les liens entre les stations de base en fonction de la technologie sans fil utilisée. Par tant du constat qu'il est difficile d'obtenir des liens backhauls très haut débit, les auteurs cherchent à obtenir un placement des stations de base qui maximiserait le débit obtenu pour un maximum d'utilisateur. Pour ce faire, deux approches sont proposées. La première étant orientée réseau et la deuxième orientée utilisateurs. Dans le papier [5], les auteurs proposent d'améliorer l'architecture existante du réseau d'accès qui consiste à densifier le nombre de petites cellules pour améliorer la couverture du réseau et le débit fourni aux utilisateurs. L'objectif ici est de remplacer les petites cellules fixes par une multitude de petites cellules mobiles temporaires embarquées dans des véhicules de particuliers et de prouver que le débit moyen obtenu par les utilisateurs sera augmenté de 120%, et surtout que le coût de déploiement et de maintien par l'opérateur sera réduit. Cette idée tire partie du fait que, généralement, le nombre de véhicules présent dans une zone est proportionnel au nombre d'utilisateurs du réseau.

Toujours dans l'optique de réduire au maximum la quantité des messages de contrôle dans le RAN, certains papiers se proposent de travailler sur la communication directe entre deux UEs (D2D, device-to-device). C'est ce que proposent les auteurs du papier [39]. Ici les auteurs proposent, dans le cadre de communications D2D un mécanisme de découverte de voisinage distribué. Les UEs diffusent un message de présence sur le canal réservé à l'allocation de ressource diffusé par la BS. Pour cela, l'UE doit d'abord signaler sa présence à la BS en effectuant la procédure RACH classique pour que la BS réserve autant de place que le nombre d'UE qui l'ont contacté de cette manière et permettre ainsi aux UEs de se découvrir entre eux. Les auteurs de [40] proposent également de travailler sur le mécanisme de découverte de voisinage des UEs sans intervention de la BS cette fois. Deux stratégies de découvertes de voisinage sont proposées ici et leur efficacité est validée par une simulation numérique sur la plate-forme Matlab.

## 3.3 Études sur l'association

L'association des utilisateurs intervient au moment où les utilisateurs ont besoin d'un accès au réseau pour pouvoir communiquer. À l'heure actuelle les utilisateurs contactent la cellule de leur opérateur ou de ses partenaires commerciaux qu'il perçoit comme celle leur fournissant le signal le plus puissant. Ce mécanisme est complètement agnostique de la qualité de service demandée par les utilisateurs et ne prend pas non plus en compte l'état actuel du réseau et la capacité des liens backhaul. L'association est un moment clef dans la vie de l'UE au sein du réseau car le trafic qui se répandra à travers ses liens résulte directement de l'association effectuée au préalable. Dans la suite nous verrons que de nombreux auteurs proposent
des mécanismes d'associations dont l'objectif n'est pas seulement d'améliorer les performances obtenues par l'utilisateur mais également celles qui en résultent dans le réseau.

Une grande partie des papiers traitant du sujet de l'association sont listés et résumés dans l'étude [41]. Les papiers y sont triés et présentés en fonction des mots clefs suivants : réseaux hétérogènes, massive MIMO, mmWave, récolte d'énergie et autre. La plupart des papiers détaillés par la suite sont listés dans cette étude.

### 3.3.1 Formulation mathématique des défis de l'association

Certains travaux sont basés sur une approche mathématique de l'association et proposent de démontrer quelles sont les performances optimales que l'on peut atteindre si certains paramètres sont pris en compte lors du processus d'association. Ces travaux proposent généralement par la suite une heuristique plus facile à mettre en pratique que le problème complet mais dont les performances se rapprochent au mieux de l'optimal.

Dans [42] par exemple, les auteurs proposent de formuler le problème de l'association sous forme de nombreuses équations. Les métriques, ou plutôt la fonction objective à optimiser, sont la maximisation de la somme des débits descendants obtenus par les utilisateurs, ainsi que la minimisation de la puissance d'émission nécessaire par les utilisateurs pour pouvoir être compris par la station de base sans générer trop d'interférences pour les autres utilisateurs.

Dans [43], les auteurs partent du constat que les UEs consomment de plus en plus de flux vidéos et que certains de ces contenus vidéos pourraient être stockés en cache en bordure de réseau en fonction de leur popularité. Dans un souci d'équilibre de la charge dans le réseau et d'amélioration du délai d'obtention du contenu souhaité, les auteurs proposent de formuler la solution optimale à ce problème avant de proposer une solution s'en approchant. La particularité de ce papier est qu'il prend en compte le fait que ces contenus présents en cache évoluent dans le temps et dans l'espace et que l'association des utilisateurs doit en tenir compte pour améliorer les performances du réseau. Dans [44] également, les auteurs proposent de joindre l'étude du placement de contenu en cache sur les BSs et l'association. Ils prouvent que trouver une solution optimale pour minimiser le délai des flux descendants est un problème NP complet. Ils soumettent donc une solution distribuée, plus simple à calculer et fournissant des résultats proches de la solution optimale.

Dans le papier [45], les auteurs proposent de mémoriser au niveau des BSs la satisfaction des UEs pour le service qu'ils ont reçu. Cette qualité de service obtenue par l'UE est traduite en un score d'opinion moyen qui est retourné à la BS et mémorisé par la BS une fois le service obtenu. En partant de ces informations, les auteurs proposent un mécanisme d'association basé sur une approche de filtrage collectif, permettant d'obtenir des recommandations de quels UEs devraient être servis par quelle BS. Ils proposent ensuite un modèle distribué de cette association grâce à un jeu de correspondance avec des externalités. Le principal gain observé par cette approche est une économie des ressources du spectre radio.

Dans [46], un problème d'optimisation complexe est formulé pour représenter le problème de l'association et de l'allocation des ressources dans les réseaux cellulaires hétérogènes avec des liens backhauls sans fils. L'objectif est de maximiser la somme des débits descendants des utilisateurs. Le problème est divisé en deux sous problèmes qui sont résolus de manière itérative pour atteindre une solution proche de l'optimal. La théorie des jeux est ensuite utilisée pour représenter le problème et prouver que celui-ci converge vers l'équilibre de Nash.
[47] propose plusieurs formulations de problèmes d'optimisations de débit, de délai et congestion, puis propose des approximations linéaires. Leur solution permet d'isoler certaines BS sans utilisateurs et de les désactiver temporairement pour limiter les interférences radio.

#### 3.3.2 Apprentissage par machine

D'autres travaux de la littérature profitent de l'émergence des réseaux de neurones pour s'essayer à l'élaboration d'une solution qui serait calculée dynamiquement et de manière autonome en fonction de plusieurs paramètres. Les solutions présentées ci-dessous proposent que le réseau apprenne de lui-même quelle est la meilleure association possible.

Dans [48], les auteurs détaillent premièrement un problème d'optimisation d'association ayant pour but la maximisation de la somme des débits. Ils expliquent ensuite qu'un tel problème prend beaucoup trop de temps pour être recalculé à la volée à chaque fois qu'un utilisateur arrive dans le réseau. Ils montrent donc comment entraîner un réseau de neurones par apprentissage profond pour obtenir un résultat proche de l'optimal mais qui s'exécute en temps réel. Le réseau de neurones nécessite toutefois de connaître la position géographique exacte de chacun des UEs, ce qui reste un obstacle majeur dans les réseaux cellulaires actuels.

Dans [49], les auteurs proposent un algorithme de prédiction de présence des utilisateurs dans un secteur, basé sur les anciennes associations de ces derniers du point de vue de la BS. La BS peut alors prédire s'il est plus rentable pour elle d'être, par exemple, éteinte. Ce papier, étudiant des traces de donnés GSM, se distingue du fait que la prédiction de présence d'un utilisateur est représentée par une distribution de probabilité de présence entre les différents secteurs catalogués.

Dans [50], les utilisateurs se servent d'un contrôleur à logique floue. Ils se placent dans le contexte d'un réseau cellulaire hétérogène et cherchent à déterminer de manière distribuée si les utilisateurs doivent être associés aux petites cellules à portée ou bien à la macro-cellule. Pour cela chaque petite cellule utilise ce contrôleur et décide si l'utilisateur peut s'associer chez lui ou être envoyé vers la macro cellule. Cette décision est prise grâce à des informations d'entrées qui sont le débit requit par l'utilisateur et le pourcentage de ressources que cela représentent pour la petite cellule. Les auteurs observent alors un gain de débit, une baisse du nombre de blocages mais un plus grand nombre d'envois d'utilisateurs vers la macro-cellule, ce qui n'est pas l'objectif principal recherché dans un réseau cellulaire hétérogène.

Dans le papier [51], les auteurs se placent dans le cadre d'un réseau d'entreprise privé qui fournit un service LTE à la fois à ses employés et à ses invités. L'objectif étant de fournir un service équitable à tous en cas de faible charge sur le réseau puis de favoriser uniquement les UEs employés en cas de saturation du réseau. Les auteurs proposent alors un mécanisme d'association mais également de ré-association basé sur un processus de chaînes de Markov, puis entraîné dans un réseau de neurones. Cette solution ré-associe les utilisateurs déjà associés si nécessaire et oriente les nouveaux UEs vers la BS la plus adaptée à l'objectif initial. Ici, les utilisateurs sont catégorisés comme employés ou visiteurs. Il y a donc une notion de priorité introduite. Il est alors tout à fait envisageable d'utiliser le même procédé dans un contexte de gestion de désastre pour cette fois différencier les équipes d'interventions et les civils. Ou, de la même manière, on pourrait utiliser ce procédé pour différencier les applications comme, par exemple, un UE souhaitant diffuser une vidéo du sinistre de manière prioritaire et un civil souhaitant regarder une vidéo Youtube au même moment.
Dans le papier [52], les auteurs s'intéressent à l'association dans les réseaux Wi-Fi. Ils expliquent que l'association dans les réseaux Wi-Fi est similaire à celle des réseaux cellulaires car également basée sur la force du signal perçu par les utilisateurs. Ils font l'observation que le débit minimal obtenu par les utilisateurs suite à l'association actuelle engendre un taux d'insatisfaction qui peut être amélioré. Et c'est ce taux d'insatisfaction qu'ils cherchent à réduire ici grâce à une solution d'association centralisée dans laquelle les contrôleurs Wi-Fi prennent la décision de la répartition des utilisateurs entre les points d'accès. Cette solution est basée sur de l'apprentissage par renforcement et une simulation est effectuée pour valider que le gain minimal obtenu par les utilisateurs est augmenté. Ce papier est un exemple que l'association n'est pas seulement un problème réservé aux réseaux cellulaires et que certaines solutions déjà apportées aux réseaux Wi-Fi peuvent nous être utiles.

### 3.3.3 L'association pour la qualité de service

Dans [53], les auteurs font le constat que les utilisateurs consomment de plus en plus de données mobiles notamment dû aux fournisseurs de services vidéos. Ils constatent également que dans ces cas là, l'utilisateur n'a pas besoin d'un débit exceptionnellement élevé mais juste d'avoir une qualité de service qui correspond à ces besoins. Ils proposent donc un algorithme d'association des utilisateurs qui a pour but de maximiser le revenu des opérateurs téléphoniques tout en fournissant aux utilisateurs une haute qualité de service.

Les auteurs de [54] étudient une topologie de réseau LTE constitué d'une macro cellule et d'une pico cellule. Ils formulent premièrement l'association et le problème d'optimisation de la somme des débits sous forme théorique en utilisant la relaxation semi-définie. Ils en tirent une borne maximale de la somme des débits atteignables en fonction du nombre d'utilisateurs. Puis, ils proposent une heuristique basée sur l'aléatoire qui répond au même problème et la compare à la borne maximale théorique. Ils concluent en prouvant que leur solution aléatoire apporte au minimum les mêmes débits que l'association actuelle basée sur le meilleur SINR mais qu'en moyenne elle produit un meilleur résultat.

### 3.3.4 L'association dans les réseaux hétérogènes

Nombre de défis des réseaux auto-déployables le sont également pour les réseaux hétérogènes. Ici l'association est pensée pour des réseaux composés de plusieurs types de BSs de différentes capacités, portées et puissances d'émissions. Les cellules sont appelées macro cellule, micro cellule, pico cellule ou femto cellule en fonction de leur portée, leur puissance d'émission et leur taille, respectivement décroissantes. Les papiers suivants ont en commun une contextualisation autour des réseaux hétérogènes.

Dans le papier [55], les auteurs fixent plusieurs problèmes d'optimisation visant à réduire l'énergie globale consommée par le réseau d'accès. Trois points sont pris en compte ici : l'association des utilisateurs, le nombre d'utilisateurs par cellule, ainsi qu'un mécanisme ON-OFF d'utilisation des BSs. Cette solution a pour but de déterminer quelles stations doivent être désactivées et à quel moment pour réduire l'énergie totale consommée par le réseau d'accès.

Dans un contexte de réseaux cellulaires hétérogènes denses, les auteurs de [56] font le constat que les problèmes d'optimisation de l'association étudiés dans la littérature ne prennent pas en compte les différentes topologies d'interconnexions backhaul et la capacité de leurs liens. Ils proposent premièrement un système d'analyse
de l'association en prenant en compte à la fois les paramètres du RAN et du lien backhaul. A savoir plus précisément, l'efficacité spectrale, la charge de la BS, la capacité et la topologie du lien backhaul, le trafic montant et descendant à débit géranti ou pas. Ils proposent ensuite une formulation du problème visant à maximiser la moyenne arithmétique des débits lors de l'association et font varier les différents paramètres cités précédemment pour étudier leur impact sur les débits obtenus. Afin de réduire le trafic sur le lien backhaul, les petites cellules des réseaux hétérogènes peuvent parfois mettre en cache certains contenus. Dans [57], les auteurs formulent un problème d'optimisation d'association d'utilisateur joint au placement de contenus en cache. La logique de ce papier est similaire aux autres papiers d'optimisation : formulation de l'optimal, formulation d'une approximation et validation de l'approximation par simulation. L'objectif cependant ici est de minimiser la consommation énergétique du système entier.

Dans [58], les auteurs se placent dans le contexte d'un réseau hétérogène et cherchent à optimiser l'association et l'équilibrage de charge dans le réseau en prenant en compte la différence de priorité du trafic des utilisateurs. Ils représentent l'association sous la forme d'un modèle de graphique à facteur d'où ils dérivent une approximation plus simple à calculer. Ils vérifient enfin par simulation que l'approximation est proche de l'optimal.

Dans [59], les auteurs joignent le problème de l'association avec celui de la distribution des charges dans le réseau ainsi que celui de la puissance d'émission des BSs. Dans le problème étudié, les utilisateurs sont répartis entre plusieurs niveaux de priorité. Les auteurs expliquent qu'il est très fastidieux de trouver une solution aux problèmes avec autant de paramètres dynamiques. C'est pourquoi ils proposent de formuler leur proposition avec des valeurs de charge et de puissance fixes puis dérivent une approximation qui elle accepte des valeurs dynamiques sans trop s'éloigner de l'optimal.

Les auteurs de [60] proposent un algorithme d'association des utilisateurs et d'allocation de ressources pour des utilisateurs ayant des priorités différentes. Un problème d'optimisation est formulé pour maximiser la satisfaction globale des utilisateurs pour chaque niveau de priorité.

Dans [61], les auteurs proposent d'accroître l'utilisation des femto cellules, implantées dans les boîtiers utilisateurs de certains fournisseurs d'accès à Internet. Ils proposent un mécanisme où les femto cellules ouvrent leur service à tous les clients de l'opérateur moyennant un prix pour ce service. Le réseau se charge ensuite d'envoyer les UEs vers les femto cellules proposant le meilleur ratio ressources/prix.

Dans [62], les auteurs se mettent dans le contexte de réseaux hétérogènes denses. Ils présentent ces réseaux comme non optimisés dans le cas d'un trop grand nombre de petites cellules et d'UEs. Ils proposent alors une méthode décentralisée basée sur la coopération entre plusieurs petites cellules. Ils expliquent comment une bonne répartition géographique des cellules, ainsi qu'une allocation des ressources du spectre de fréquence, accroît les performances. La solution qu'ils proposent coordonne plusieurs petites cellules, améliore la capacité globale du réseau et réduit le nombre d'appels rejetés.

Les auteurs de [63] font ici un constat similaire au notre, que l'association est agnostique des mouvements des utilisateurs et de leur distribution. Ils expliquent qu'une vision à long terme du réseau devrait prendre en compte ces éléments dès l'association. Ils proposent de formuler l'association comme un problème de maximisation du débit à long terme du système. Puis proposent de formuler avec un modèle de théorie des jeux, celui du bandit manchot.
## 3.4 L'association avec partage d'informations

Comme expliqué dans le chapitre 2, nous pensons que l'association a besoin d'un partage d'informations de la part des BSs pour exploiter son plein potentiel. Voici un récapitulatif des papiers de la littérature qui travaillent déjà dans ce sens.

Dans [64], les auteurs formulent l'association avec un problème d'optimisation convexe autour de deux valeurs clefs $ρ$ et $α$. La variable $ρ$ est un vecteur représentant la charge actuelle de la BS alors que $α$ est une valeur pouvant être fixée arbitrairement entre 0 et $∞$. Chaque valeur de $α$ reviendra à modifier la fonction objective du problème : le débit optimal ($α$ = 0), le débit optimal ($α$ >= 1), le délai optimal ($α$ = 2) et l'équilibre des charges entre les BSs ($α$ = $∞$). Les auteurs présentent ensuite une version décentralisée de cet algorithme dans laquelle les BSs diffusent les valeurs de $α$ et $ρ$ et les UEs trient localement les cellules alentour en fonction de ces deux valeurs. Une simulation est proposée dans laquelle les utilisateurs arrivent selon une loi de Poisson et souhaitent tous télécharger un fichier d'une taille fixe. La BS diffuse alors la métrique à optimiser grâce à la valeur de $α$ ainsi que le flot moyen dispensé par chaque BS grâce à la valeur de $ρ$. Dans une extension de leur travail [65], les auteurs étudient leur algorithme décentralisé $α$-optimal dans le cadre d'un réseau surchargé. Ils simulent les performances de leur algorithme et discutent des bénéfices de l'ajout d'un contrôle d'admission des UEs dans un réseau saturé.

Les auteurs de [66] font également le constat que la bande passante du lien backhaul n'est pas toujours sur-approvisionnée et qu'elle peut devenir le premier frein à l'obtention d'une bonne qualité de service des utilisateurs. Ils proposent donc de traiter l'association comme un problème d'optimisation considérant de manière jointe le RAN et la capacité du lien backhaul. Pour cela ils reprennent les travaux de [64] et rajoutent à l'équation la prise en compte de la capacité restante sur le lien backhaul. Ils étudient ensuite par simulation leur algorithme dans diverses topologies de réseaux pour mieux extraire l'impact du lien backhaul.

Dans le papier [67], les auteurs décrivent les règles qui font d'un mécanisme d'association décentralisé une association efficace. Ils expliquent qu'un partage d'information de charge des BS ne peut qu'améliorer la prise de décision côté UE. Ils expliquent que lors de la procédure de sélection de cellule, le calcul et la prise de décision lors du classement des cellules doivent être simples et rapides car effectués souvent. Pour cela, ils regardent de plus près les performances du papier [64] pour plusieurs valeurs de $α$. Ils comparent les performances de $α$-optimal avec un algorithme centralisé avec des simulations avec NS3. Ils concluent que les performances sont meilleures que l'association meilleur SINR actuelle, moins bonne que dans la version centralisée mais qu'elle exige nettement moins de puissance de calcul et qu'elle est donc pertinente.

Les auteurs de [68] font le constat que l'association meilleur SINR est sous optimal et qu'il y a très souvent de meilleures cellules candidates, en termes de débit obtenu, que celle qui nous propose le meilleur SINR. Les auteurs proposent d'ajouter aux smartphones une brique logicielle permettant d'interférer dans le processus de remontée des mesures de puissance des BSs alentour et de mémoriser les débits obtenus pour chaque BS par zone géographique. L'UE peut donc ainsi créer un faux rapport de mesure de puissance qui devrait convaincre le réseau de lui octroyer la cellule de son choix. Ce papier est très intéressant car il appuie sur un point pour lequel nous sommes tout à fait d'accord : la procédure de sélection de cellule actuelle ne fournit pas toujours à l'UE la cellule qui lui aurait donné le meilleur débit. Cependant la solution proposée impose au réseau le choix de cellule d'un UE. Cette méthode est certes efficace si réalisée de manière isolée mais pourrait également
conduire à l'effondrement du réseau et un accroissement des messages de contrôle si elle devenait généralisée.

Les auteurs de [69] proposent un mécanisme d'association dans les réseaux pos-
sédant des tranches virtualisées. Les communications des UEs sont représentées par
des cases temporelles dans lesquelles un seul service unique peut être utilisé à la fois.
Un modèle d'apprentissage renforcé, profond, fédéré et hybride est proposé ici. Les
UEs entraînent un modèle localement avec leurs données locales de débits obtenus
par case et service avant de remonter ces données aux BSs. Les BSs entraînent égale-
ment un modèle avec les données ainsi récupérées et renvoient aux UEs un modèle
d'apprentissage mis à jour. L'association est ensuite réalisée en tenant compte des ré-
sultats du modèle entraîné. Les résultats montrent un gain d'efficacité des communi-
cations de plus 35% par rapport à l'association basée sur le meilleur RSSI. L'énergie
supplémentaire consommée localement sur les UEs par un tel procédé est qualifiée
d'acceptable par les auteurs car "la consommation du processus d'apprentissage est
inférieure à celle des applications typiques d'un smartphone (lecture de vidéos ou
jeux large échelle)".

Là où les auteurs du papier [67] argumentent sur la nécessité d'avoir un méca-
nisme d'association facile à exécuter du côté de l'UE du fait qu'il est réalisé très sou-
vent, les auteurs du papier [69] ont une vision opposée. De notre point de vue l'asso-
ciation devrait être simple du côté de l'UE et nous avons déjà vu dans le cas de réseau
auto-déployables que les équipes de premiers secours n'ont pas le temps d'entraîner
des algorithmes d'apprentissage sur place et n'ont pas toujours les ressources radio
suffisantes permettant un aller-retour de données d'apprentissages entre les UEs,
la BS. Voilà pourquoi nous proposons dans le chapitre 5 de ce manuscrit d'ajouter
des informations de charge des BSs à leurs canaux de diffusion pour que les UEs
puissent classer les BSs selon une métrique plus efficace et sans rajouter de sur-coût
de calcul, de bande passante et de consommation d'énergie.

## 3.5 Conclusion

Nous avons vu dans ce chapitre de nombreux papiers de la littérature traitant
des réseaux auto-déployables et des défis associés. Nombre de ces défis très étudiés
dans ce contexte sont pourtant tout autant pertinents dans les réseaux cellulaires
traditionnels LTE. Il en est le cas par exemple des contraintes de débits des utilisa-
teurs dans les réseaux hétérogènes ou bien de la gestion des liens backhauls à faible
capacité dans certaines topologies des réseaux. Le principal défi qui nous intéresse
ici est de réaliser une association des utilisateurs qui prenne à la fois en compte
l'hétérogénéité de la structure du réseau et l'hétérogénéité des applications utilisées
par les utilisateurs. Ce problème s'applique aussi bien aux réseaux auto-déployables
qu'aux réseaux commerciaux traditionnels et dans aucun de ces deux cas l'associa-
tion standard actuelle ne répond à ce défi. Nous avons présenté plusieurs papiers
de la littérature qui s'orientent dans la même direction que nos travaux et vers un
partage de l'information des BSs vers les UEs. Ce partage permet aux UEs de réaliser
une meilleure sélection de cellule et à terme d'obtenir de meilleures performances en
accord avec les besoins requis par leurs applications. Dans le chapitre 5 nous mon-
trerons, grâce à la plateforme expérimentale srsRAN mise en place dans le chapitre
4, que l'association actuelle est effectivement agnostique des besoins en qualité de
service et de débits des UEs. Puis dans le chapitre 6 nous montrerons comment il
est possible d'intervenir dans le code source de srsRAN pour réussir à partager une
information de charge des BSs sans rajouter de sur-coût de calcul, de bande passante et de consommation d'énergie.
# Chapitre 4

# Plateforme srsRAN

## 4.1 Introduction à srsRAN

Nous souhaitons durant cette thèse proposer une nouvelle manière de réaliser la sélection de cellule pratiquée durant l'association de l'utilisateur au réseau d'accès et de partager une information de charge de la part de l'eNB. Étant donné que très peu de papiers de la littérature implémentent et valident expérimentalement les solutions qu'ils proposent, nous avons décidé d'implémenter la solution que nous proposons et de réaliser une validation de nos idées par l'expérimentation. Pour cela nous avons besoin de déployer une plateforme expérimentale avec suffisamment d'éléments pour réaliser une expérimentation pertinente et suffisamment bien automatisée pour pouvoir réaliser des mesures intensives sans avoir à réaliser manuellement des centaines d'heures d'expérimentations.

Pour réaliser ces expérimentations nous avons décidé d'utiliser la suite logicielle srsRAN. srsRAN[70] est une solution logicielle libre, d'émulation de réseau LTE, dont le code source est facile d'accès et bien commenté. Un premier retour d'expérience de notre équipe et de nos partenaires tendait à confirmer la facilité d'implémentation et de modification de cette solution. Le code source est disponible sur Github au lien suivant [71]. La documentation et le guide d'installation sont disponibles au lien suivant [72]. Après avoir téléchargé l'archive contenant le code source et installé les prérequis, il devient possible de modifier le code via l'environnement de développement de votre choix et de compiler votre propre version de srsRAN. Dans notre cas, nous chercherons dans le chapitre 6 à modifier du côté de l'UE le processus de sélection de cellule et du côté de l'eNB la diffusion des informations complémentaires de la cellule.

Tout au long de ma thèse le logiciel srsRAN a subi des mises à jour successives. Au début de ma thèse, srsRAN existait dans sa version "srsLTE 19". Tous les 6 mois environ, srsRAN subit des mises à jour majeures. Parmi ces mises à jour, certaines ont impacté le code du protocole RRC et de la sélection de cellule, ce qui a été le cas de la version "srsLTE 20". Ces mises à jour visaient à intégrer des éléments plus récents du standard 3GPP ou tout simplement à renommer des fonctions. Ce qui fut le cas lors du passage de l'ancien nom srsLTE vers srsRAN. srsLTE est devenu srsRAN puisque ce dernier cherche maintenant à implémenter le fonctionnement du réseau 5G et également la partie NB-IoT. Un renommage était nécessaire pour représenter l'ensemble de ses fonctionnalités. Même si j'ai suivi de près les modifications apportées à srsRAN tout au long de ma thèse et que j'en ai modifié toutes les versions pour leur permettre d'ajouter une information de charge aux BSs, nous avons décidé de n'utiliser que la version la plus ancienne srsLTE 19 lors de nos expérimentations. Il est en effet trop chronophage d'installer et faire fonctionner chaque nouvelle version de srsRAN sur la plateforme d'expérimentation. De plus, toutes les expérimentations doivent utiliser la même version si on veut pouvoir comparer
nos résultats entre-eux. Dans le chapitre 6 nous expliqueront plus en détail le code
source de srsLTE 19 et l'implémentation de la sélection de cellule effectuée par ce
dernier.

## 4.2 L'utilisation de srsRAN dans la littérature

Les développeurs eux-mêmes de srsRAN partagent dans le papier [70] une expé-
rimentation sur la cohabitation de leur solution libre de droits srsRAN avec la tech-
nologie WiFi. Ils expliquent ici les principaux conseils d'utilisation de leur solution
srsRAN. Ils insistent sur le fait que srsRAN peut fonctionner à la fois sur les bandes
de fréquences des opérateurs mais également sur des fréquences libres d'utilisation
pour le public. Une analyse de performances est effectuée dans le cas de coexistence
du RAN srsRAN et du WiFi dans les fréquences 2,4GHz et 5Ghz.

srsRAN est un outil d'émulation de réseau cellulaire régulièrement cité dans la
littérature. Le site de srsRAN recense le nombre de papiers de la littérature ayant
utilisé srsRAN et ce nombre se porte à 242 à l'heure de l'écriture de ce manuscrit [73].
Nous listons ci-dessous quelques exemples de papiers utilisant srsRAN et modifiant
le code source de srsRAN.

Dans le papier [74], les auteurs présentent OWL, une extension à la suite logi-
cielle srsRAN permettant de décoder les DCI transmis par les BSs. Cette extension
est capable de connaître en temps réel la totalité des UEs ou plutôt leurs identifiants
temporaires dans le RAN (RNTIs) et de savoir combien de blocs de ressources ont été
attribués à chacun. Cette solution libre de droits vise à concurrencer les décodeurs
commerciaux déjà existant dans un cadre d'utilisation pour la recherche en réseaux.
Dans un travail similaire, d'autres auteurs présentent FALCON [75], un plugin srs-
RAN libre de droits ayant les mêmes objectifs que OWL mais un peu plus récent.
Ce dernier compare les solutions pré-existantes [76] [77] et fait le constat que sous
certaines conditions leurs performances décroissent significativement. Deux de ces
conditions sont la mobilité des UEs et la présence de fortes interférences sur le lien
radio. FALCON propose de rajouter un mécanisme de décodage robuste aux envi-
ronnements bruyants du canal de contrôle descendant et compare les performances
obtenues avec les précédentes solutions grâce à une application expérimentale.

Dans le papier [78], les auteurs exposent une faille de sécurité LTE permettant
d'envoyer des messages du système d'alerte publique à près de 90% des spectateurs
d'un stade de foot. Ils expliquent comment forcer une rupture du lien radio entre
l'UE et sa BS actuelle pour forcer une nouvelle procédure de sélection de cellule. Ils
démontrent ensuite qu'une BS malveillante diffusant des messages avec une puis-
sance suffisamment élevée pourra alors diffuser des messages d'alertes à ces UEs. Ils
rentrent ici dans les détails des procédures RRC et d'attachement pour prouver que
l'UE reste suffisamment de temps à l'écoute de la station malveillante pour recevoir
le contenu du SIB 12 et donc le faux message d'alerte. Le tout est démontré et testé en
utilisant du matériel disponible sur étagère et la suite logicielle srsRAN. Ce dernier
papier est un bon exemple du potentiel d'utilisation et de modification possible de
la suite logicielle srsRAN dans un cadre de recherche.

Parmi les papiers cités, certains créés des extensions de srsRAN ou utilisent en
l'état la version officielle de srsRAN pour effectuer des mesures. Mais peu des pa-
piers de la littérature modifient le code source de srsRAN pour implémenter leurs
propres solutions et les expérimenter. Pourtant certains papiers comme [74], [75] et
[78] montrent qu'il est possible de modifier srsRAN. Ce que nous proposons dans
le chapitre 6 est de modifier directement le code source de srsRAN pour y changer
les informations diffusées par l'eNB et pour changer la manière dont la sélection de
cellule est effectuée par l'UE.

4.3 Les éléments de srsRAN

srsRAN propose une émulation des principaux composants et fonctions d'un réseau cellulaire commercial 4G. A savoir, l'EPC, l'eNB et l'UE. Voici ci-après le détail du fonctionnement de chacun de ces éléments.

4.3.1 srsEPC

srsEPC est une version allégée d'un cœur de réseau LTE complet. Il regroupe et fait fonctionner sous un seul et même exécutable les entités suivantes d'un cœur de réseau traditionnel (voir figure 4.1) :

<figure><img src="image_15.png" /><figcaption>FIGURE 4.1 – Architecture du cœur de réseau émulé par srsRAN.</figcaption></figure>

- La base de données HSS (Home Subscriber Service). Elle stocke les informations relatives aux utilisateurs tels que leur identifiant, leurs paramètres d'authentification et leur profil de service.

- Le MME (Mobility Management Entity). Le MME est l'élément central du cœur de réseau. Il gère l'attachement et la mobilité des UEs.

- Le S-GW (Serving Gateway). Le S-GW constitue la porte de sortie du trafic de données de l'UE. Il se charge de construire un tunnel IP de bout en bout entre l'UE et le P-GW en garantissant une certaine qualité de service.

- Le P-GW (Packet Data Network Gateway). Le P-GW constitue la passerelle entre le réseau de l'opérateur et le réseau IP extérieur.

Lors de son exécution, srsEPC récupère certains paramètres d'utilisation dans
deux fichiers que l'utilisateur peut modifier. Ces deux fichiers sont "epc.conf" et
"user_db.csv".

Dans le tableau 4.1 sont recensés les principaux paramètres modifiables pour l'EPC. Il est ici possible de modifier l'identifiant du MME ainsi que celui du groupe auquel il appartient. On peut également modifier le TAC (Tracking Area Code) qui permet d'identifier un ensemble de cellules et de les catégoriser par zones géographiques. Le TAC est principalement utilisé lors de la procédure de paging. Les champs suivants sont le MMC (Mobile Country Code) et MNC (Mobile Network Code), qui représentent respectivement le code du pays et de l'opérateur. Un opérateur peut avoir plusieurs codes différents, mais qui lui sont réservés [18]. Le champs
<table><caption>TABLE 4.1 – Contenu modifiable pour l'EPC dans le fichier de configuration epc.conf.</caption><thead><tr><td>Paramètre</td><td>Valeur par défaut</td></tr></thead><tbody><tr><td>mme_code</td><td>0x1a</td></tr><tr><td>mme_group</td><td>0x0001</td></tr><tr><td>tac</td><td>0x0007</td></tr><tr><td>mcc</td><td>001</td></tr><tr><td>mnc</td><td>01</td></tr><tr><td>mme_bind_addr</td><td>127.0.1.100</td></tr><tr><td>apn</td><td>srsapn</td></tr><tr><td>dns_addr</td><td>8.8.8.8</td></tr></tbody></table>

"mme_bind_addr" définit l'adresse IP à laquelle peut être contacté le MME disponible dans srsEPC. On retrouve ensuite le nom du point d'accès créé par le réseau et l'adresse IP du serveur DNS à contacter.

<table><caption>TABLE 4.2 – Contenu modifiable de la base de donnée HSS dans le fichier user_db.csv.</caption><thead><tr><td>Nom</td><td>ue1</td><td>ue2</td></tr></thead><tbody><tr><td>Algorithme d'authentification</td><td>xor</td><td>millenage</td></tr><tr><td>IMSI</td><td>001010123456789</td><td>001010123456780</td></tr><tr><td>Clef K</td><td>00112233445566...</td><td>00112233445566...</td></tr><tr><td>Code opérateur (OP) ou (OPc)</td><td>opc</td><td>opc</td></tr><tr><td>OP / OPC</td><td>63bfa50ee65233...</td><td>63bfa50ee65233...</td></tr><tr><td>Champs d'authentification</td><td>9001</td><td>8000</td></tr><tr><td>SQN</td><td>000000001234</td><td>000000001234</td></tr><tr><td>QCI</td><td>7</td><td>7</td></tr><tr><td>Allocation d'adresse IP</td><td>dynamic</td><td>172.16.0.1</td></tr></tbody></table>

Le tableau 4.2 représente le contenu de la base de données HSS à l'initialisation de srsEPC et un exemple de valeurs que l'on pourrait avoir pour deux UEs. Ce fichier permet d'ajouter à l'avance des entrées concernant les UEs qui utiliseront le réseau. Parmi les éléments mémorisés pour chaque UE on retrouve les suivants :

- L'IMSI (International Mobile Subscriber Identity), identifiant présent dans la carte SIM et la base de données HSS, unique à l'utilisateur ayant souscrit un forfait chez l'opérateur.

- La clef K. Cette clef de chiffrement est stockée sur la carte SIM de l'utilisateur et dans la base de données HSS. Une comparaison de la valeur obtenue par une opération impliquant cette clef est effectuée lors de la procédure d'authentification. D'autres clefs de chiffrement sont ensuite dérivées de cette clef K, telle que la clef de chiffrement.

- Le QCI (QoS Class Identifier) représente une qualité de service attendue par l'UE pour ses communications.

- L'allocation d'adresse IP peut être effectuée de manière dynamique ou bien être configurée statiquement.
### 4.3.2 srsENB

srsENB est une station de base LTE implémentée entièrement sous forme logicielle. srsENB fonctionne sous le système d'exploitation Linux et se connecte à n'importe quel cœur de réseau, qu'il s'agisse de srsEPC ou d'une autre solution logicielle de cœur de réseau. srsENB fonctionne de pair avec un équipement radio logicielle afin de transmettre et recevoir des signaux radio LTE. Il permet la mise en place d'un réseau d'accès physique auquel peut se connecter la solution logicielle srsUE couplée à une radio logicielle ou un smartphone disponible sur étagère qui disposerait d'une carte SIM personnalisée.

<table><caption>TABLE 4.3 – Contenu modifiable pour l'eNB dans le fichier de configuration enb.conf.</caption><thead><tr><td>Paramètre</td><td>Valeur par défaut</td></tr></thead><tbody><tr><td>enb_id</td><td>0x19B</td></tr><tr><td>cell_id</td><td>0x02</td></tr><tr><td>phy_cell_id</td><td>2</td></tr><tr><td>tac</td><td>0x0007</td></tr><tr><td>mcc</td><td>001</td></tr><tr><td>mnc</td><td>01</td></tr><tr><td>mme_addr</td><td>127.0.1.100</td></tr><tr><td>gtp_bind_addr</td><td>127.0.1.1</td></tr><tr><td>s1c_bind_addr</td><td>127.0.1.1</td></tr><tr><td>n_prb</td><td>50</td></tr><tr><td>dl_earfcn</td><td>2800</td></tr><tr><td>dl_freq</td><td>5120e6</td></tr><tr><td>ul_freq</td><td>5180e6</td></tr><tr><td>txgain</td><td>80</td></tr><tr><td>rxgain</td><td>40</td></tr></tbody></table>

Dans le tableau 4.3 sont recensés les principaux paramètres modifiables pour l'eNB. Il est ici possible de modifier l'identifiant de l'eNB ainsi que de la cellule. On retrouve également les informations du TAC, du MCC et du MNC. On peut également configurer les adresses IP des différents éléments du cœur de réseau auquel l'eNB doit se connecter. Puis viennent les informations qui seront le plus souvent manipulées durant nos expérimentations :

- Le nombre de PRB (Physical Ressource Block). Cette valeur indique la taille de la bande passante de la cellule en nombre de blocs de ressources physiques sur lesquels la cellule va pouvoir envoyer des symboles au cours d'un même créneau temporel.

- Le EARFCN (E-UTRA Absolute Radio Frequency Channel Number) de la voie descendante. Ce nombre traduit la fréquence centrale de la bande passante utilisée pour la voie descendante. Une valeur d'EARFCN sur la voie montante est automatiquement associée à l'EARFCN de la voie descendante. Certains sites Internet comme [79] proposent un outil permettant de retrouver les valeurs de fréquence et de bande associés à un EARFCN.

- Les fréquences des voies montantes et descendantes. Si une valeur est indiquée ici, elle écrase la valeur de fréquence associée au EARFCN. Ce champ là permet d'indiquer des valeurs de fréquences qui n'appartiennent à aucun
spectre licencié pour la technologie LTE. Dans notre cas nous indiquerons des valeurs de fréquences appartenant à la bande libre ISM 5GHz pour nos expérimentations des chapitres 5 et 6.

- Les valeurs de gain en transmission (TX) et en réception (RX), en dB. Ce sont ces valeurs qui permettent de moduler la puissance d'émission et le gain de réception des transmissions radio. Dans le cadre de nos expérimentations, le gain d'émission variera la plupart du temps entre 60 et 90 dB. Ces valeurs ont été déterminées empiriquement. A moins de 60dB la portée de communication est beaucoup trop faible pour pouvoir réaliser nos expérimentations. Et l'alimentation de notre radio logicielle USRP NI-2901 ne nous fournit pas assez de courant pour dépasser les 90dB en gain d'émission.

L'eNB est également responsable de la diffusion du MIB et des SIBs comme expliqué dans le chapitre 2. Les valeurs contenues dans le MIB ne sont pas paramétrables par l'utilisateur mais les valeurs des SIBs le sont dans le fichier "sib.conf". Le tableau 4.4 montre certaines valeurs modifiables des SIBs 1 et 2.

<table><caption>TABLE 4.4 – Contenu du SIB1 dans le fichier de configuration sib.conf.</caption><thead><tr><td>Paramètre</td><td>Sous-paramètre</td><td>Valeur par défaut</td></tr></thead><tbody><tr><td>ré sélection intra-fréquence</td><td></td><td>autorisée</td></tr><tr><td>puissance de réception minimale</td><td></td><td>-65dBm</td></tr><tr><td>Cellule barée</td><td></td><td>"Non barrée"</td></tr><tr><td>taille de la fenêtre de répétition (ms)</td><td></td><td>20</td></tr><tr><td>Info SIBs</td><td>périodicité</td><td>16</td></tr><tr><td>...</td><td>info de placement</td><td>SIB1 et SIB2</td></tr></tbody></table>

Seuls les SIBs 1, 2, 3 et 13 sont implémentés dans le version "srsRAN 19". Il est possible de rajouter ceux qui manquent en modifiant le code source, ce qu'ont fait les auteurs du papier [78] en rajoutant le SIB12.

### 4.3.3 srsUE

srsUE est un UE 4G LTE implémenté entièrement sous forme de logiciel. Il fonctionne sous le système d'exploitation Linux et fonctionne de pair avec un équipe-ment radio logicielle. srsUE se connecte à n'importe quel réseau LTE et apporte une interface réseau permettant le trafic de données, pour peu qu'il soit configuré correctement ou qu'il soit couplé à une carte SIM.

Le tableau 4.5 contient les éléments configurables de srsUE contenus dans le fichier "ue.conf". La plupart d'entre eux ont déjà été expliqués précédemment. La nouveauté ici consiste en la configuration des valeurs que doit contenir la carte SIM virtuelle de cet UE si aucune carte SIM réelle n'est associée à srsUE. On retrouve alors la clef de chiffrement K et l'IMSI qui doivent être identiques aux valeurs présentes dans la base de données HSS de srsEPC, s'ils sont tous deux utilisés ensemble. On note également le paramétrage de l'IMEI et du code pin qui nous intéresse ici beaucoup moins dans le cadre d'un réseau privé expérimental.

Les mécanismes d'appels audios ainsi que la VoLTE ne sont pas encore implémentés dans srsRAN. Il n'est alors pas possible de passer des appels que ce soit entre deux instances de srsUE ou entre deux smartphones disponibles sur étagère. En revanche, le trafic de données est lui bien implémenté. Il est donc possible de monter un serveur du côté de la machine qui exécute srsEPC et d'en avoir les clients
<table><caption>TABLE 4.5 – Contenu modifiable pour l'UE dans le fichier de configuration ue.conf.</caption><thead><tr><td>Paramètre</td><td>Valeur par défaut</td></tr></thead><tbody><tr><td>dl_earfcn</td><td>2800</td></tr><tr><td>#dl_freq</td><td>5180e6</td></tr><tr><td>#ul_freq</td><td>5240e6</td></tr><tr><td>freq_offset</td><td>0</td></tr><tr><td>tx gain</td><td>80</td></tr><tr><td>rx gain</td><td>40</td></tr><tr><td>mode</td><td>soft</td></tr><tr><td>algo</td><td>xor</td></tr><tr><td>#opc</td><td>63BFA50EE6523365FF14C1F45F88737D</td></tr><tr><td>K</td><td>00112233445566778899aabbccddeeff</td></tr><tr><td>imsi</td><td>001010123456789</td></tr><tr><td>imei</td><td>353490069873319</td></tr><tr><td>#pin</td><td>1234</td></tr></tbody></table>

du côté de la machine qui exécute srsUE. On peut également se servir de la machine qui exécute srsEPC comme d'un routeur qui redirigera le trafic de l'UE vers une seconde interface connectée à Internet. L'UE aura alors accès à Internet grâce à notre connexion 4G srsRAN (figure 4.7).

## 4.4 Les éléments complémentaires

### 4.4.1 Les radios logicielles USRP

Comme expliqué plus tôt, les deux logiciels srsENB et srsUE peuvent fonctionner de pair avec un équipement de radio logicielle pour effectuer les communications physiques radios entre les deux éléments. Les équipements que nous avons choisis pour réaliser cette tâche sont des USRP-2901 [80] de la marque National Instrument. Ces équipements font partis de ceux testés et recommandés par les développeurs de srsRAN. Ce choix s'est surtout porté sur le fait que le département Télécommunications, Services et Usages de l'INSA Lyon disposait déjà de plus d'une vingtaine de ces équipements et que réussir à les faire fonctionner signifierait être potentiellement capable de réaliser des expérimentations avec beaucoup d'eNBs et d'UEs. Les USRPs sont agrémentés d'antennes VERT2450 [81] capables d'émettre de manière omnidirectionnelle sur deux bandes de fréquences de 2.4-2.5 et 4.9-5.9 GHz. Sur la figure 4.2 apparaissent nos URSPs, ainsi que le reste du matériel complémentaire utilisé.

### 4.4.2 Cartes SIMs programmables

Il est possible d'utiliser un téléphone disponible sur étagère et de le connecter à srsRAN.

En utilisant votre propre téléphone portable directement en l'état et en essayant de vous attacher au réseau srsRAN avec srsEPC et srsENB allumés, vous pourrez probablement apercevoir le réseau lors d'une recherche avec votre téléphone mais l'accès vous sera refusé.
<figure><img src="image_16.png" /><figcaption>FIGURE 4.2 – Vue d'ensemble des éléments utilisés.</figcaption></figure>

<figure><img src="image_17.png" /><figcaption>FIGURE 4.3 – Cartes SIMs programmables et lecteurs.</figcaption></figure>
Il y a quelques règles à savoir avant de pouvoir s'associer avec une station de base srsRAN et de réussir à trafiquer avec :

1. Votre téléphone doit être compatible avec la bande de fréquences utilisée par votre station de base srsENB. À l'heure d'écriture de ce manuscrit, ce site [82] est un exemple parmi d'autres qui vous permet de savoir avec quelles bandes de fréquences est compatible votre téléphone. Dans le cas de srsRAN, la bande utilisée par défaut est la bande B7. Si votre téléphone n'est pas compatible avec cette bande il ne pourra pas détecter le réseau srsRAN.

2. Si votre téléphone est compatible avec la bande B7 (2600 MHz), il faut main-tenant s'assurer qu'il ne soit pas "simlocké" par votre opérateur actuel et que vous ayez bien la possibilité de vous attacher à un autre réseau que celui de votre opérateur.

3. Il est impossible d'utiliser un téléphone équipé d'une carte SIM d'un opéra-teur de télécommunications classique. Cela est dû au fait que le cœur de ré-seau de votre opérateur, ainsi que votre carte SIM, utilisent une clef de chiffre-ment partagée, la clef K. Une étape d'authentification est réalisée entre votre téléphone et le cœur de réseau lors de la tentative d'attachement de votre té-léphone au cœur de réseau. Et si la clef K de votre carte SIM ne correspond pas à celle connue par le réseau, l'attachement de votre téléphone est rejeté. Et c'est exactement ce qui arrive avec srsRAN si vous utilisez la carte SIM de votre opérateur. Puisque votre clef de chiffrement K est secrètement gardée à l'intérieur de votre carte SIM et que srsEPC ne la connaît pas, votre demande d'attachement est rejetée.

Si les deux premiers points ne sont pas vraiment un obstacle dans la majorité des cas, le troisième l'est beaucoup plus. Ce troisième point nous oblige à utiliser des cartes SIMs dont la clef de chiffrement K est connue, ce qui n'est pas si simple. Heureusement, nous avons pu acquérir des cartes SIMs programmables et des lec-teurs de cartes (voir figure 4.3) grâce au site Open Cells Project [83]. Ce site met également à disposition de ses clients un programme écrit en C qui permet de mo-difier et de réécrire les informations présentes sur la carte SIM (voir figure 4.4). Il est donc possible de créer des cartes SIM avec un MCC, un MNC et surtout une clef de chiffrement K définis arbitrairement, voir figure 4.5. Il faudra alors ajouter au fi-chier de configuration de notre base de données d'utilisateurs HSS ( usr_db.conf ) une ligne correspondant à notre nouvelle carte SIM avec toutes les informations la caractérisant, voir figure 4.6.

```c
struct uicc vals {
    bool setIt=false;
    string adm="0C004646";
    string iccid="";
    string imsi="001010123456780";
    string opc="63bfa50ee6523365ff14c1f45f88737d";
    string op="";
    string isdn="";
    string acc="";
    string key="00112233445566778899aabbccddeeff";
    string spn="RPU LTE";
    int mncLen=2;
    bool authenticate=false;
};
```

<caption>FIGURE 4.4 – Structure des données à modifier dans le programme en C pour modifier le contenu de la carte SIM.</caption>
<figure><img src="image_18.png" /><figcaption>FIGURE 4.5 – Exécution du programme d’écriture de carte SIM.</figcaption></figure>

```
1# 
2# .csv to store UE's information in HSS
3# Kept in the following format: "Name,Auth,IMSI,Key,OP_Type,OP,AMF,SQN,QCI,IP_alloc"
4
5 ue0,mll,001010123456780,00112233445566778899aabbccddeeff,opc,63bfa50ee6523365ff14c1f45f88737d,9000,000000001a4e,,dynamic
```

<caption>FIGURE 4.6 – Exemple du contenu du fichier de config user_db.csv.</caption>

Lorsque toutes ces étapes sont accomplies il nous est alors possible de nous atta-
cher et de trafiquer avec notre téléphone et le réseau srsRAN comme montré dans la
figure 4.7.

4.5 Création d'une plateforme expérimentale avec srsRAN

4.5.1 Les enjeux

Pour réaliser des expérimentations avec beaucoup de matériel il est nécessaire
de passer dans une salle plus grande et avec plus de machines (figure 4.8) que lors
de mes premiers essais dans mon bureau. Nous avons donc décidé d'utiliser la salle
de TP réseau du département Télécommunications de l'INSA Lyon pour mettre en
place une plateforme expérimentale construite autour de srsRAN et des radios logi-
cielles NI-USRP 2901 présentées précédemment. Cette salle de TP permet l'intercon-
nexion de toutes les interfaces réseaux des machines de la salle grâce à une baie de
brassage contenant plusieurs switchs (voir figure 4.9).

Le principal intérêt de cette salle est que l'on peut disperser plusieurs eNBs au travers de la salle et mesurer des RSRP différents en fonction de notre position géographique dans la salle. Chaque machine doit se voir configurer une interface réseau avec une adresse IP qui devra être renseignée dans les fichiers de configuration de srsENB. De même pour la machine qui hébergera le cœur de réseau srsEPC.

Le second intérêt consiste à avoir une plateforme expérimentale à disposition
aussi bien de la recherche que de l'enseignement. L'installation de la partie logicielle
décrite ci-dessous témoigne des difficultés rencontrées lors de la mise en service de
tous ces éléments.
<figure><img src="image_19.png" /><figcaption>FIGURE 4.7 – Carte SIM programmée pour notre réseau srsRAN et test de débit.</figcaption></figure>

<figure><img src="image_20.png" /><figcaption>FIGURE 4.8 – Plateforme expérimentale srsRAN.</figcaption></figure>
<figure><img src="image_21.png" /><figcaption>FIGURE 4.9 – Baie de brassage de la salle de TP.</figcaption></figure>

4.5.2 Installation

Les scripts utilisés pour l'installation de la plateforme sont disponibles dans mon
GitLab Inria [84]. Il contient plusieurs fichiers et scripts utilisés pour l'installation
mais également les scripts d'automatisation des mesures du chapitre 4 écrits en Py-
thon. Les fichiers utiles à l'installation sont les suivants :

- Readme : Il contient les informations nécessaires à l'utilisation des fichiers suivants.

- install.sh : Il s'agit du script qui va mettre à jour les paquets Ubuntu nécessaires, compiler puis installer la version 19 de srsRAN.

- srsuescript.sh : Il s'agit d'un script permettant de configurer l'interface réseau de la machine qui va exécuter l'instance de srsUE.

- ue.conf : Il s'agit d'un fichier de configuration de srsUE prérempli avec les informations qui nous intéressent.

- usr_db.csv : Il s'agit d'un fichier de configuration de la base de données HSS prérempli avec les informations qui nous intéressent.

- release19.tar.gz : Il s'agit d'une archive contenant la version 19 de srsRAN.

Les machines de la salle de TP disposent d'une version d'Ubuntu 16 qui laisse à l'utilisateur les droits d'administrateurs. Cela nous est indispensable pour installer srsRAN sur les machines. La contrepartie pour éviter que les étudiants ne détruisent tout est qu'il s'agit d'une version bac à sable qui permet d'essayer Ubuntu mais qui revient à son installation d'origine à chaque redémarrage. L'installation de srsRAN n'est donc pas permanente sur ce système d'exploitation mais doit être re-effectué à chaque redémarrage de la machine. Voilà pourquoi l'installation de srsRAN a été scriptée par mes soins.
Le script "install.sh" va d'abord mettre à jour la liste des paquets disponibles sur Ubuntu 16 puis installer toutes les dépendances nécessaires au bon fonctionnement de srsRAN et des USRPs. Le script va ensuite s'assurer que le processeur est configuré en mode "performance". Il va ensuite télécharger les images à pouser dans l'USRP pour le faire fonctionner, vient ensuite le désarchivage de l'archive contenant le code source de la version 19 de srsRAN, puis sa compilation et son installation. Deux fichiers de configuration présents dans notre dossier d'installation sont ajoutés à la solution fraîchement installée. Le premier, "ue.conf" contient la majorité des paramètres qui seront communs à tous les UEs qui s'exécuteront pendant nos expérimentations. Les paramètres uniques à chaque UE seront eux ajoutés dans les scripts Python qui seront en charge d'exécuter les différentes instances de srsUE. Le deuxième, "usr_db.conf" contient les informations des UEs qui participeront à l'expérimentation.

Quel que soit le scénario de mesure de performance que l'on souhaite réaliser, il convient d'abord de mettre en place l'ensemble de l'architecture. La configuration du réseau cellulaire minimale nécessaire à une mesure de débit par exemple nécessite un cœur de réseau, une station de base et un équipement utilisateur. Après rappel des procédures d'association et d'attachement détaillées au chapitre 2, on devine qu'il est nécessaire de démarrer ces différents éléments dans un certain ordre. Tout d'abord il faut lancer le cœur de réseau via l'exécutable srsEPC. Vient ensuite l'exécution de la station de base via l'exécutable srsENB. La station de base émulée par srsENB va lancer une procédure de recherche du cœur de réseau via l'interface S1. Une fois cette connexion entre cœur de réseau et station de base établie, on peut démarrer l'équipement utilisateur via l'exécutable srsUE. Cet exécutable va ensuite scanner les bandes de fréquences données en paramètre dans le fichier de configuration "ue.conf" à la recherche d'une station de base et s'en suivront la procédure d'association à cette station de base détectée puis la procédure d'attachement au cœur de réseau.

Une fois l'architecture en place, il faut configurer les interfaces réseaux des deux machines utilisées afin de permettre le routage des paquets entre elles. La machine émulant le réseau (accès et cœur) doit pouvoir transmettre les paquets qu'elle reçoit sur l'interface radio créée avec l'USRP vers son interface réseau la reliant à Internet. Un script bash fourni dans le code source de srsRAN permet de réaliser cette opération. Il s'agit du script "srsepc_if masq.sh" situé dans le répertoire "/srsRAN/srsepc/" du code source du projet. Du côté de l'équipement utilisateur, il faut configurer en ligne de commande une route par défaut passant par l'interface radio créée, ainsi que changer le DNS par défaut.

Puisque nos machines fonctionnent avec une version bac à sable d'Ubuntu, les configurations de réseaux et d'interfaces ne sont pas mémorisées entre chaque rédémarrage. Il faut donc reconfigurer les routes et les interfaces pour qu'elles soient mémorisées pendant toute la durée de nos expérimentations. Cette configuration doit être ajoutée au fichier "/etc/network/interfaces" comme illustré dans la figure 4.10. Sur cette figure, on voit les lignes à rajouter (6 à 9) pour une interface qu'on aurait nommée "tun_srsue1" dans le fichier de config "ue.conf". Pareil pour les lignes 12 à 15 si l'interface est nommée "tun_srsue2" dans le fichier de config "ue.conf". Cette opération est effectuée automatiquement dans notre script dénommé "srsuescript.sh" présent également dans mon GitLab Inria [84].

Ces étapes sont gérées automatiquement dans notre script Python d'exécution des scénarios de mesure. Le détail de son fonctionnement sera présenté au chapitre 5.
<figure><img src="image_22.png" /><figcaption>FIGURE 4.10 – Fichier /etc/network/interfaces.</figcaption></figure>

<table><caption>TABLE 4.6 – Radio configuration of the eNB.</caption><thead><tr><td>EARFCN</td><td>Bandwidth (MHz)</td><td>Emission Gain (dBm)</td></tr></thead><tbody><tr><td>3200</td><td>10</td><td>80</td></tr></tbody></table>

### 4.5.3 Validation du fonctionnement

Il est possible, grâce aux logs srsRAN, d'obtenir le détail de la répartition des PRBs et des éléments de ressources (REs) d'une station de base, sous-trame par sous-trame, pour chaque utilisateur connecté. Nous en avons fait l'expérience ci-après lors d'un test de nos nouvelles cartes SIMs. L'expérience qui suit a pour but d'observer le détail de la répartition des PRBs entre deux utilisateurs souhaitant regarder tous deux une vidéo en streaming via le site de streaming de jeux vidéo Twitch [85]. Les deux smartphones utilisés pour cette expérimentation sont le Galaxay A9 de Samsung et le Huawei P10. Les deux appareils sont donc attachés au réseau et commencent tous deux le visionnage de leur influenceur préféré.

Durant 5 minutes, srsENB va récolter et archiver les informations contenues dans les messages diffusés sur le canal de contrôle du lien descendant (PDCCH). Nous allons utiliser un outil que j'apprécie particulièrement, qui est la suite logicielle Elasticsearch, Logstash et Kibana (ELK). Cette suite logicielle ELK consiste en une base de données (Elasticsearch), qui va être alimentée par un analyseur de lignes de logs (Logstash) pour enfin fournir une interface web visuelle (Kibana) de l'ensemble de notre base de données. Kibana nous permet également d'afficher, grâce à un système d'indexation et de recherche très poussé à l'intérieur de Elasticsearch, des statistiques alimentées par nos données. Il nous suffit donc de donner à Logstash nos fichiers de logs ainsi qu'un fichier de configuration indiquant le format de ces logs pour obtenir rapidement un ensemble de données exploitables.

La figure 4.11 représente le nombre de PRBs alloués à nos deux utilisateurs sur un peu plus de 19 secondes de trafic. La configuration utilisée pour la station de base est donnée dans la table 4.6. Les deux barres noires représentent la partie de l'histogramme qui sera mis en valeur dans la figure 4.12. Ce zoom nous permet de voir à la fois la distribution des PRBs lorsque les deux smartphones trafiquent en même temps puis lorsqu'un des deux smartphones, le Huawei P10, n'a temporairement plus de données à envoyer ou recevoir.
<figure><img src="image_23.png" /><figcaption>FIGURE 4.11 – Répartition des PRBs d’un eNB entre deux smartphones.</figcaption></figure>
<figure><img src="image_24.png" /><figcaption>FIGURE 4.12 – Répartition des PRBs et REs d'un eNB entre deux smartphones sur 100 millisecondes.</figcaption></figure>
La figure 4.12 montre la répartition des PRBs et des REs de notre eNB entre les deux smartphones. Il s'agit ici d'une capture de 100ms de trafic descendant. Cha-cune des barres représente le nombre de PRBs alloués à un utilisateur pour une sous-trame. Le nombre de PRBs maximum par sous-trame est de 50, ce qui cor-respond à une largeur de bande de BS de 10 MHz. Ce nombre est à répartir entre les deux smartphones lors de la même sous-trame. Ici on s'aperçoit cependant que l'ordonnanceur de srsRAN préférera alterner une distribution de 50 PRBs complets entre chacun des smartphones. Le nombre de REs quand a lui peut atteindre une valeur de 6300 REs maximum par sous-trame dans notre configuration actuelle. On remarque toutefois sur la figure 4.12, que toutes les 5 et 10 sous-trames successives, le nombre de PRBs et de REs alloués par l'eNB est plus faible. Cela est dû au fait que le canal PDSCH (Physical Downlink Shared Channel) qui véhicule les données des UEs laisse une partie de ses REs au PSS (Primary Synchronization Signal) et au SSS (Secondary Synchronization Signal) toutes les 5 sous-trames. Mais également à cause du canal PBCH (Physical Broadcast Channel), qui utilise lui aussi des ressources pour diffuser des informations, tel que le MIB, toutes les 10 sous-trames.

#### 4.5.4 Retour d'expérience de l'installation

Cette partie consiste en un petit retour d'expérience sur les problèmes rencontrés lors de l'installation et les moyens mis en place pour y remédier. Cette partie pourra certainement aider ceux qui essayeront de reproduire nos scénarios de mesures des chapitres suivants. Nous rappelons que les outils mis en place pour l'installation et l'exécution des scénarios de mesures sont disponibles dans le GitLab Inria suivant [84].

##### L'installation des pilotes logiciels

La première étape de l'installation consiste à mettre à jour les applications avec le gestionnaire de paquet Ubuntu. Bien que cette opération puisse sembler triviale, elle nous a posé beaucoup de problèmes sur ces machines. En effet, l'installation standard proposée par Ettus Research pour installer et mettre à jour les drivers des radios logicielles USRP (voir code 4.1) fonctionnait très bien sous Ubuntu 20 mais générait des erreurs sur la liaison en série entre l'USRP et la machine sous Ubuntu 16. Cette même commande n'installait pas la même version du driver nommé "uhd-host" sur la machine. Le problème a été résolu en enlevant la première ligne de code du code 4.1, ce qui ne met pas à jour la liste des versions des paquets disponibles. La version de "uhd-host" installée rétrograde donc de la version 15 à la version 9. D'après la documentation de srsRAN, l'utilisation de la version 9 plutôt que la version 15 de "uhd-host" n'est pas un problème car ces deux versions sont considérées comme stables et sont recommandées. Nous avons donc décidé de conserver la version 9 dans notre cas.

```
sudo add-apt-repository ppa:ettusresearch/uhd
sudo apt-get update
sudo apt-get install libuhd-dev libuhd4.1.0 uhd-host
```

<caption>LISTING 4.1 - Installation recommandé des drivers USRP sous Ubuntu</caption>
## Changer le mode de performance du processeur

Un message d'alerte apparaît dans le terminal lors de l'exécution de srsRAN si le
processeur n'est pas configuré par défaut en mode performance. Ce message est là
pour s'assurer que la machine ait bien le temps de traiter toutes les données qu'elle a
à traiter durant la durée d'une sous-trame LTE. Passer en mode performance permet
de minimiser ce risque. Pour pallier ce problème nous avons trouvé, dans le code 4.2,
le moyen de changer en ligne de commande les performances du processeur.

```bash
echo "GOVERNOR=\"performance\"" > /etc/default/cpufrequents
sudo systemctl restart cpufrequents
```

LISTING 4.2 – Passer le processeur en mode performance sous Ubuntu

## Passer des arguments en ligne de commande

```bash
#Création d'un fichier de log
fue = open('./ue.txt', 'w')

#Mise en forme des arguments
args = ["srsue",
        "--rat.eutra.dl_earfn",
        "2800,2900,3000,3100,3200,3300,3400",
        "--log.all_level",
        "none",
        "--log.rrc_level",
        "info",
        "--log.phy_level",
        "info",
        "--log.filename",
        "./ue.log",
        "--general.metrics_csv_enable",
        "1",
        "--general.metrics_csv_filename",
        "./metrics.csv"]

#Lancement de srsUE dans un processus parallèle
srsUE = subprocess Popen(args, stdout = fue)
```

<caption>FIGURE 4.13 – Exemple d'exécution de srsUE en ligne de commande sous Python.</caption>

Ceci peut également paraître trivial mais il est très facile de passer un peu trop vite sur la documentation des différents éléments qui composent srsRAN pour re-marquer que lors de leur exécution en ligne de commande on peut rajouter en argu-ments la totalité des paramètres qui constituent les fichiers de configurations. Dans le chapitre 5 nous utiliserons 28 configurations différentes d'UEs. Il n'est donc pas nécessaire de créer 28 versions du fichier de configuration "ue.conf". La figure 4.13 montre un exemple de comment cette exécution en ligne de commande est effectué dans nos scripts Python d'automatisation des mesures.

## Allocation des adresses IPs.

Lors des premières expérimentations réalisées "à la main" l'un des problèmes rencontrés était celui de l'allocation des adresses IP pour les UEs par srsEPC. Les UEs obtenaient une addresse IP croissante en fonction de leur ordre d'attachement au cœur de réseau. Le problème étant qu'un UE A pouvait, d'une expérimentation
<table><caption>TABLE 4.7 – Allocation des adresses IPs.</caption><thead><tr><td>UE</td><td>IMSI</td><td>Adresse IP</td></tr></thead><tbody><tr><td>ue1</td><td>001010123456789</td><td>172.16.0.2</td></tr><tr><td>ue2</td><td>001010123456792</td><td>172.16.0.3</td></tr><tr><td>ue3</td><td>001010123456793</td><td>172.16.0.4</td></tr><tr><td>ue4</td><td>001010123456794</td><td>172.16.0.5</td></tr><tr><td>ue5</td><td>001010123456795</td><td>172.16.0.6</td></tr></tbody></table>

à une autre, avoir deux adresses IPs différentes. Cela pose problème pour les mesures de débits réalisées avec Iperf et pour le traitement des données par la suite. Pour remédier au problème, il est possible dans la base de données HSS du fichier "usr_db.conf" d'ajouter une adresse IP fixe liée à l'IMSI d'un utilisateur. Le tableau 4.7 est un extrait du fichier "usr_db.conf" présent dans nos fichiers d'installations du chapitre 5 dans notre GitLab Inria [84].

# 4.6 Les scénarios de mesure

## 4.6.1 Un besoin de répétabilité et de reproductibilité

Maintenant que la plateforme est en place, nous pouvons réaliser nos expérimentations. Afin d'obtenir pour chaque scénario de mesure des valeurs représentatives, il est important de répéter le nombre de mesures effectuées. Il est également important que les conditions dans lesquelles sont effectuées ces mesures ne changent pas pendant toute la durée des expérimentations.

Dans le cas des mesures du chapitre 5, chaque mesure dure environ une minute. Nous partons du principe qu'il faut au moins 10 mesures par configuration pour obtenir un résultat représentatif. Nous testons ensuite 28 combinaisons différentes de paramètres et ce pour des configurations qui vont de 1 à 5 UEs. Cela représente un total de 1400 mesures, soit environ 23 heures d'expérimentations dans un cas sans échec et plus de 21000 fichiers générés à analyser.

Automatiser les mesures, ainsi que le traitement des résultats, nous fera gagner du temps et encore plus si d'autres mesures sont à prévoir. Une deuxième motivation à l'automatisation des mesures est qu'il est possible, pour vous lecteurs, de reproduire les mesures effectuées en récupérant les scripts utilisés via notre Gitlab Inria [84].

## 4.6.2 L'automatisation des mesures

Cette partie a pour but de détailler l'exécution des scripts Python d'automatisation des mesures présents dans le dossier "Chapitre 5" du Gitlab Inria [84]. Il y a quatre scripts principaux dans ce dossier :

- AgoraTelecomIsoRoomServer.py : Ce script sert à la synchronisation des trois scripts suivants grâce à l'implémentation d'un serveur TCP ainsi que la mise en place de processus en parallèle.

- AgoraTelecomIsoRoomEPC.py : Ce script permet de synchroniser l'exécution de srsEPC avec les autres éléments grâce à une communication TCP avec le serveur. Il met également en place, dans des processus parallèles, autant de clients Iperf qu'il y a d'UEs pour réaliser une mesure de débit avec les UEs.
- AgoraTelecomIsoRoomENB.py : Ce script permet de synchroniser l'exécution de srsENB avec les autres éléments grâce à une communication TCP avec le serveur. Les paramètres d'exécution de srsENB et le nombre de répétitions pour chaque ensemble de paramètres sont codés en dur au début du fichier.

- AgoraTelecomIsoRoomUE.py : Ce script permet de synchroniser l'exécution de srsUE avec les autres éléments grâce à une communication TCP avec le serveur. Il met également en place dans un processus parallèle un serveur Iperf pour réaliser une mesure de débit avec l'EPC.

Ces scripts effectuent une boucle dans laquelle sont compris le démarrage de srsEPC, srsENB et les différents srsUEs. À l'intérieur de cette boucle s'effectuent les mesures de débit Iperf pour une configuration d'eNB donnée. Cette boucle est répétée le nombre de fois indiqué par la variable de répétition. Et tout ceci est encore une fois répété autant de fois qu'il y a de combinaisons différentes indiquées en dur dans les fichiers. À l'intérieur de chacune de ces boucles, les entités s'assureront que les interfaces des machines ont bien les bonnes configurations et adresses IP pour pouvoir trafiquer.

### 4.6.3 Détail d'une itération de boucle

Nous appellerons "acteurs" les différents éléments du réseau qui participent à la mesure. Ces acteurs sont nominativement les différents EPC, eNBs et UEs qui composent le scénario.

On utilise ici un système d'échange de message par des sockets TCP pour synchroniser les différents acteurs du scénario. Le nombre et le rôle de ces acteurs peuvent ainsi varier du moment que l'on indique dans le code source du serveur le nombre d'acteurs attendus. Une fois ce nombre atteint, le serveur répond à tous ceux qui l'ont contacté. Les acteurs sont donc synchronisés et exécutent la suite de leur programme.

Sur la figure 4.14, les blocs jaunes représentent l'envoi initial au serveur du message d'un acteur souhaitant participer. Les blocs oranges représentent l'attente d'un message coté serveur et l'envoi de la réponse à l'acteur concerné. Le serveur créé dans cet exemple quatre processus d'écoute en parallèle. Il en créera autant que d'acteurs attendus. Les blocs rouges représentent l'attente des acteurs du message de synchronisation envoyé par le serveur. Ils attendent donc que tous les acteurs soient présents avant de lancer l'instance de srsRAN qui leur est propre. Les destinataires de chacun des messages cités précédemment sont pointés par les flèches bleus qui partent des blocs émetteurs.

Un premier échange de message a donc lieu entre tous les acteurs afin de les synchroniser. Ensuite, le serveur se remet à l'écoute d'un message provenant du script EPC. Ce message lui sera envoyé quand toutes les mesures de débit Iperf seront arrivées à terme ou auront échouées.

De leur côté les acteurs créeront tous plusieurs processus qu'ils exécuteront en parallèle. Ils lanceront tout d'abord l'exécution de srsRAN qui leur est propre (srsEPC, srsENB, srsUE) en bleu. srsEPC sera lancé dès la réception du message de synchronisation, les autres attendront pendant une durée qui leur est propre pour s'assurer que les éléments se lancent dans le bon ordre pour favoriser le succès de la mise en marche du réseau. Les options associées au lancement de srsRAN suivront dynamiquement les paramètres de mesures préalablement inscrites dans un tableau au début du script.
<figure><img src="image_25.png" /><figcaption>FIGURE 4.14 – Chronogramme d’une itération d’un scénario de mesure.</figcaption></figure>
Les scripts UEs créeront en parallèle un processus serveur Iperf en vert foncé pour la mesure de débit descendant. Le script EPC créera lui en parallèle autant de processus Iperf clients en vert clair qu'il n'y a d'UEs dans le scénario.

Les scripts UEs et eNB attendent un message de la part du serveur leur indiquant que le script EPC a fini les mesures Iperf et que tous les processus doivent être arrêtés avant de recommencer l'exécution d'une boucle si nécessaire.

Pour les autres expérimentations, les blocs verts Iperf peuvent être remplacés par une autre exécution.

### 4.6.4 Retour d'expérience sur les scénarios de mesure

Même si la mise en place de l'automatisation des mesures fût globalement un succès, il arrive dans certains cas et pour certaines configurations que les éléments n'arrivent pas à s'associer entre eux ou bien qu'il y ait une erreur lors des mesures Iperf. Le premier problème que cela engendre est qu'il n'est pas possible de se rendre compte qu'une mesure n'a pas fonctionné avant d'ouvrir le fichier de résultat généré. Cela nous a donc obligés à créer un script qui indique combien de mesures sont réellement réussies et à écarter les mesures échouées. Le deuxième problème est que l'on ne peut connaître à l'avance le bon nombre de mesures à demander aux scripts d'automatisation pour avoir au final au moins 10 mesures réussies pour chacune des configurations. Le dernier problème est finalement de choisir quelles mesures garder si le script d'automatisation ressort plus de 10 mesures valides pour une configuration.

Après réalisation de cette campagne de mesures, plus de 50 heures d'expérimentations auront été réalisées pour pallier certaines erreurs de mesure. Plus de 90 000 fichiers ont été générés par la plateforme. Parmi ces fichiers, 50 000 fichiers sont extraits et correspondent à des mesures valides. Et parmi ce dernier ensemble, 20 000 fichiers sont utilisés pour générer les résultats présentés dans le chapitre 5. Les 30 000 fichiers valides restants correspondent à un surplus de mesures lancées par anticipation d'éventuelles erreurs de mesures impossible à prédire.

Les résultats sont fournis sous un certain format dans les logs de srsRAN. Cependant ce format ne permet pas de tracer directement les courbes qui nous intéressent. Il faut donc réarranger ces fichiers, en extraire les informations pertinentes et tracer les graphes adéquats. Toutefois, comme mentionné précédemment, il s'agit de plus de 90 000 fichiers à traiter. Ces scripts sont également disponibles dans le Gitlab Inria [84].

## 4.7 Conclusion

Dans ce chapitre nous avons présenté srsRAN, une suite logicielle d'émulation de réseau cellulaire LTE grandement utilisé par la littérature. Nous avons expliqué son fonctionnement, présentés les briques et les mécanismes LTE qu'elle émule. Nous avons ensuite montré comment nous mettons en place une plateforme expérimentale basée sur srsRAN dont le but est de réaliser des mesures de manière intensive et automatisée. Nous utilisons par la suite cette plateforme expérimentale dans le chapitre 5.

Cette plateforme est automatisée grâce à l'utilisation de scripts qui sont détaillés dans ce chapitre. L'automatisation est nécessaire pour réaliser une exécution coordonnée des différentes entités qui composent les expérimentations mais également
pour éviter de réaliser manuellement des mesures qui se sont déroulées sur plu-
sieurs dizaines d'heures. Plus de 48Go de données ont été générés par l'intermé-
diaire de cette plateforme dont le traitement a également été scripté.
# Chapitre 5

## Limite de l'association actuelle

### 5.1 Introduction

Dans ce chapitre nous allons étudier les limites de l'association actuelle et mon-
trer expérimentalement que l'association meilleur SINR est bien agnostique de la
qualité de service demandé par les utilisateurs et leurs applications. Dans un pre-
mier temps, nous reviendrons sur les détails de la sélection de cellule réalisée par
l'UE afin de mettre en lumière la nécessité de revisiter l'association et le processus
de sélection de cellules. L'UE classe les cellules par ordre de puissance du signal
perçu (le RSRP) mais la cellule ayant le meilleur signal perçu ne fournit pas toujours
à l'UE le meilleur débit. La puissance du signal reçu n'est qu'une indication de la
qualité du lien radio entre UE et eNB, mais si l'eNB ou ses liens d'interconnexions
sont saturés, le débit que l'eNB fournira ne sera pas pour autant plus élevé. Nous
utiliserons la plateforme expérimentale srsRAN décrite précédemment pour mener
à bien une expérimentation visant à mesurer le débit obtenu par un UE en fonction
de divers paramètres de la station de base. Ces mesures se feront en concurrence ou
non d'autres UEs, essayant également d'obtenir le meilleur débit possible de cette
même station de base. Nous analyserons ensuite les résultats obtenus et réaliserons
une étude des limites de l'association meilleur SINR grâce à une simulation exploi-
tant les résultats expérimentaux obtenus dans ce chapitre.

### 5.2 Sélection de cellules

On donne à l'association meilleur SINR un nom légèrement trompeur. Cette asso-
ciation se sert en réalité des mesures du RSRP et du RSRQ réalisées par l'UE comme
métriques de la procédure de sélection de cellule. Le RSRP est une mesure de la
puissance reçue d'un signal de référence sur des éléments de ressources (REs) dont
la position est connue d'avance. Le RSRP est défini par le 3GPP dans la section 5.1.1
du document TS 36.124[86]. Le RSRQ mesure la qualité du signal de référence reçu
sur les REs de références. Le RSRQ est défini par la 3GPP dans la section 5.1.3 du
même document TS 36.124[86].

Les signaux de références sont répartis uniformément sur des éléments de res-
sources de la trame LTE. La figure 5.1 donne un exemple de placement de ces blocs
en rouge sur une trame LTE d'une station ayant une bande passante de 1,4 MHz.
Ces éléments sont appelés symboles de références et ne servent à aucun transfert
de données utiles entre l'UE et l'eNB. Ces éléments sont répartis, de manière fixe et
uniforme, en temps et en fréquence, sur toute la bande du spectre de la station. La
différence entre le RSRP et le RSSI (Reference Signal Strength Indicator) est que le
RSSI est une mesure de puissance générale sur toute la bande de fréquence, alors
que le RSRP mesure la puissance de quelques blocs de référence dispersés à des
<figure><img src="image_26.png" /><figcaption>FIGURE 5.1 – Éléments de ressources hébergeant les signaux de références.</figcaption></figure>

positions fixes sur toute la bande. L'association meilleur SINR est appelée ainsi par simplicité de compréhension sur la nature des métriques utilisées. Le RSRQ quant à lui est un indicateur de la qualité du lien radio. Le RSRQ est le résultat du rapport $N * RSRP / RSSI$, avec N le nombre de blocs de ressources de la bande passante mesurée.

La sélection de cellule est une étape importante de l'association. Comme déjà expliqué dans le chapitre 2, la sélection de cellule consiste à créer ou maintenir une liste de cellules proches susceptibles de nous fournir des ressources radios. Lorsque l'UE découvre une nouvelle station de base à ajouter à cette liste, il mesure le RSRP et le RSRQ de cette station. L'UE calcule d'abord une valeur appelée le critère de sélection (critère S), basé sur le RSRP et le RSRQ, qui vient s'assurer que la cellule fournit une puissance de signal et une qualité de signal minimale pour pouvoir accepter un nouveau trafic. Si le critère S est validé, la cellule obtient une valeur de rang R, qui est le résultat d'un second calcul basé sur le RSRP. Toutes les cellules connues sont ensuite classées par ordre décroissant de leur valeur de R et l'UE demande à s'associer à la première station de cette liste.

### 5.2.1 Critère de sélection de cellules S

La formule du critère de sélection de cellule est définie dans le 3GPP TS 136 304 [17] section 5.2.3.2 :

$$ (Srxlev > 0) \text{AND}(Squal > 0) \qquad (5.1) $$

$$ Srxlev = Qrxlev_{meas} - (Qrxlev_{min} + Qrxlev_{min_{offset}}) - P_{comp} - Q_{offset_{temp}} \quad (5.2) $$

$$ Squal = Qqual_{meas} - (Qqual_{min} + Qqual_{min_{offset}}) - Q_{offset_{temp}} \quad (5.3) $$

Le critère de sélection de cellules représenté par l'équation 5.1 est rempli si le niveau de puissance en réception (*Srxlev*) et le niveau de qualité en réception (*Squal*) sont supérieurs à zéro.

L'équation 5.2 détaille le calcul de la valeur de *Srxlev*. *Srxlev* est obtenu à partir de la mesure directe du RSRP à laquelle sont ajoutés ou soustraits divers éléments de compensation. Ces éléments de compensation viennent ajouter des informations
<table><caption>TABLE 5.1 – Variables utilisées pour le calcul du critère S.</caption><tr><td>Pcomp</td><td>Compensation de puissance par l'UE en transmission (dBm)</td></tr><tr><td>Qoffset<sub>temp</sub></td><td>Offset appliqué temporairement à une cellule (dB)</td></tr><tr><td>Qqual<sub>meas</sub></td><td>RSRQ mesuré (dB)</td></tr><tr><td>Qqual<sub>min</sub></td><td>Qualité minimale requise pour cette cellule (dB)</td></tr><tr><td>Qqual<sub>min offset</sub></td><td>Lié à l'itinérance (3GPP TS 23.122[87], section 4.4.3.3)</td></tr><tr><td>Qrxlev<sub>meas</sub></td><td>RSRP mesuré (dBm)</td></tr><tr><td>Qrxlev<sub>min</sub></td><td>Puissance minimale requise pour cette cellule (dBm)</td></tr><tr><td>Qrxlev<sub>min offset</sub></td><td>Lié à l'itinérance (3GPP TS 23.122[87], section 4.4.3.3)</td></tr><tr><td>Squal</td><td>Qualité en réception pour la sélection de cellule (dB)</td></tr><tr><td>Srxlev</td><td>Puissance en réception pour la sélection de cellule (dB)</td></tr></table>

extérieures à la mesure du RSRP, traduites en valeurs de puissances. En fonction de $Srxlev$, l'UE décide également de réaliser ou pas des mesures de puissance des stations autour de lui.

L'équation 5.3 détaille le calcul de la valeur de $Squal$. $Squal$ est calculé à partir de la mesure du RSRQ à laquelle sont également ajoutés ou soustrait des éléments de compensation.

Les variables utilisées dans le calcul du critère S sont détaillées dans la table 5.1.

### 5.2.2 Rang des cellules R

Le rang R de chacune des cellules remplissant le critère S est lui défini dans la section 5.2.4.6 du document 3GPP TS 136 304 [17] :

$$R_s = Qmeas_s + Qhyst - Qoffset_{temp} \quad (5.4)$$

$$R_n = Qmeas_n - Qoffset - Qoffset_{temp} \quad (5.5)$$

Il y a deux calculs différents pour le rang R de la cellule. Le calcul du rang $R_s$ de la cellule sur laquelle notre UE est en train de stationner (équation 5.4) et le calcul du rang $R_n$ d'une cellule voisine (équation 5.5).

Les deux calculs utilisent comme valeur de base le RSRP mesuré pour la cellule en question. À cela est soustrait, dans les deux cas, une valeur dénommée $Qoffset_{temp}$. Cette valeur vaut zéro en temps normal mais prend la valeur $connEstFailOffset$ diffusée dans le SIB2 si le timer T300 arrive plusieurs fois de suite à expiration. Si $connEstFailOffset$ n'est pas présent dans le SIB2 une valeur infinie est utilisée à la place (voir [88] section 5.3.3.6). Le timer T300 est initialisé lors de l'envoi des messages RRCConnectionRequest et RRCConnectionResumeRequest à la station de base. Si la station de base ne répond pas à ces messages dans le temps, le timer T300 expire. $Qoffset$ a donc pour objectif de reléguer une station qui ne répond pas ou une station avec un lien radio instable au bas de notre liste de cellules candidates.

Enfin, dans le cas du rang $R_s$ (équation 5.4), une valeur d'hystérésis $Qhyst$ est utilisée pour empêcher un effet ping-pong entre deux cellules ayant une mesure de RSRP trop proche. Cette valeur de $Qhyst$ peut prendre trois valeurs différentes en
<table><caption>TABLE 5.2 – Variables utilisées pour le calcul du rang R.</caption><tr><td>R<sub>s</sub></td><td>Rang de la cellule actuellement utilisée</td></tr><tr><td>R<sub>n</sub></td><td>Rang d'une cellule voisine</td></tr><tr><td>Qmeas<sub>s</sub></td><td>RSRP de la cellule actuelle mesuré (dBm)</td></tr><tr><td>Qmeas<sub>n</sub></td><td>RSRP de la cellule voisine mesuré (dBm)</td></tr><tr><td>Qhyst</td><td>Marge d'hystérésis dépendant du niveau de mobilité de l'UE (dB)</td></tr><tr><td>Qoffset</td><td>Prend la valeur de q-offsetcell correspondante :<br/>q-offsetcell (intra) si la cellule est sur la même fréquence<br/>q-offsetcell (inter) si la cellule est sur une autre fréquence</td></tr><tr><td>Qoffset<sub>temp</sub></td><td>Qualité minimale requise pour cette cellule (dB)</td></tr><tr><td>q-offsetcell (intra)</td><td>Diffusé dans le SIB4</td></tr><tr><td>q-offsetcell (inter)</td><td>Diffusé dans le SIB5</td></tr></table>

fonction de l'état de mobilité de notre UE : normal, moyen et fort. L'UE peut être considéré comme ayant une mobilité forte s'il réalise beaucoup de changements de cellules pendant une certaine durée. À l'inverse il est considéré comme étant à l'état de mobilité normal si son nombre de handover par minute ne dépasse pas un certain seuil.

Dans le cas du rang $R_n$ (équation 5.5), la valeur $Qhyst$ est remplacée par une valeur $Qoffset$, diffusée dans les SIBs 4 et 5 de la cellule voisine. Le calcul prendra en compte la valeur du SIB4 si la cellule est sur la même fréquence que celle sur laquelle l'UE campe actuellement. Il prendra pour valeur celle du SIB5 si la cellule voisine est sur une fréquence différente. $Qoffset$ est un paramètre fixé par l'opérateur qui permet de favoriser ou de défavoriser la sélection de la cellule qui diffuse ce paramètre, sa valeur peut être positive ou négative.

Les variables utilisées dans le calcul du rang R sont détaillées dans la table 5.2.

L'ensemble des variables utilisées précédemment sont définies dans la section 5.2.4.7 du document 3GPP TS 136 304 [17].

### 5.2.3 La sélection de cellules influencée par des offsets

Les stations de base ont la possibilité d'essayer d'influencer la sélection de cellule par différents moyens :

1. La variable $Qrxlev_{min}$ de la table 5.1 utilisée dans le calcul du critère S. Cette valeur est diffusée par chacune des cellules dans le SIB1 et détermine le niveau de puissance minimal requis pour pouvoir communiquer avec la cellule (voir figure 5.2). Cette valeur peut être paramétrée par l'opérateur pour interdire l'accès à la cellule aux UEs les plus éloignés.

2. La variable $Qoffset$ de la table 5.2 utilisée dans le classement des cellules. $Qoffset$ est un paramètre fixé par l'opérateur qui permet de favoriser ou de défavoriser la sélection de la cellule qui diffuse ce paramètre, sa valeur peut être positive ou négative. Cette variable est très utilisée dans les réseaux héterrogènes afin de favoriser les petites, pico et femto cellules par rapport aux macro cellules.
<figure><img src="image_27.png" /><figcaption>FIGURE 5.2 – Capture d'image du fichier .pcap de l'eNB faisant ap-
paraître la diffusion de l'offset $Qrxlev_{min}$.</figcaption></figure>

3. Le SIB3 contient également d'autres variables fixées et diffusées par la station de base dans le but de forcer la mesure de puissance des cellules alentour et donc la re-sélection de cellule. Ces variables répondent aux noms de Sintra-searchP, SintrasearchQ, SnonintrasearchP, SnonintrasearchQ et cellindividualoff-set.

Certains papiers de la littérature[89][90] font le constat que tous ces paramètres sont difficilement paramétrables à la main par l'opérateur. Les auteurs du papier [89] proposent un outil basé sur de l'apprentissage pour régler ces paramètres. Le but de ces réglages étant de maximiser le SINR mesuré par l'UE de la cellule à laquelle il finira par s'associer.

Tous les mécanismes détaillés précédemment impactent la sélection ou la re-sélection de cellules. Ces mécanismes sont basés sur la mesure du RSRP des stations voisines par l'UE. Ces mécanismes sont également impactés par des variables, non dynamiques, souvent déterminées par l'opérateur réseau. Ces variables, qui ont souvent pour objectif de réorganiser l'allocation des UEs aux différentes stations alentour, sont toutes traduites en unité de puissance. L'avantage de cette traduction est qu'elle est transparente pour l'UE qui prend ses décisions sur une seule métrique qu'il perçoit comme la puissance reçue. Cependant l'inconvénient de cette traduction est que des informations différentes sont écrasées sous une seule valeur et qu'il y a donc une perte d'information. L'information du RSRP réel mesuré est lui-même parfois perdue suite à l'ajout de tous ces offsets. Un autre inconvénient à l'utilisation actuelle de ces offsets est qu'ils ne sont pas dynamiques. Ces offsets sont fixés par les opérateurs dans un souci de répartition des UEs et de leur trafic entre les BSs mais l'actualisation de leur valeur peut prendre des mois avant d'être réalisée, alors que le trafic lui, peut fortement évoluer d'une BS à l'autre à l'échelle de la minute.

L'UE n'a à aucun moment accès à une réelle information concernant la charge actuelle de la station de base. Or, comme nous allons pouvoir le constater grâce à
l'expérimentation présentée dans la section suivante, les performances obtenues par un UE ne dépendent pas uniquement du SINR entre la station de base et l'UE.

## 5.3 Mise en place de l'expérimentation

Nous venons de montrer comment l'UE choisissait parmi les BSs autour de lui celle avec laquelle s'associer. Ce choix s'effectue en fonction du RSRP mesuré. Or cette mesure est agnostique de la qualité de service que l'UE peut espérer obtenir de la part de la BS. Le RSRP n'est qu'un reflet de la qualité du lien radio entre l'UE et la BS, mais il ne garantit en rien que la BS est en capacité de lui fournir les ressources qu'il souhaite obtenir pour ses applications. Nous souhaitons montrer dans cette section que la valeur du RSRP mesuré par un UE n'est pas un bon indicateur du débit que l'UE peut espérer obtenir de la part de cette BS.

Dans le scénario suivant, nous réalisons des mesures de débits obtenus par un seul UE en fonction de divers paramètres de la station de base. Cet UE est ensuite mis en concurrence avec jusqu'à 4 autres UEs se partageant tous la même cellule. L'objectif étant de montrer que la charge de la BS, non prise en compte lors de l'association, impacte le débit obtenu. Parmi ces mesures de débits nous faisons également varier les paramètres de la station de base. Nous faisons varier la puissance d'émission de la BS pour impacter le RSRP mesuré par l'UE. Et nous faisons aussi varier la taille de la bande passante de la BS, non prise en compte lors de l'association, mais qui a également un impact sur le nombre maximum de ressource que la BS peut offrir. Cette section détaille le matériel utilisé et la mise en place de tous les éléments pour la réalisation des mesures expérimentales. Les résultats et les observations de l'expérimentation sont, eux, discutés dans la section suivante.

### 5.3.1 Les éléments utilisés et leur placement

Afin de réaliser nos scénarios de mesure nous avons eu besoin d'utiliser les éléments suivants :

- un EPC (srsEPC) sur une machine dédiée. (Machine srsEPC)

- un eNB (srsENB) sur une machine dédiée. (Machine srsENB)

- un à cinq UEs (srsUE) sur des machines dédiées. (Machines srsUEA, srsUEB, srsUEC, srsUED, srsUEE)

- un serveur Python servant à la coordination des machines précédentes. (Machine Serveur)

- un switch de la baie de brassage de la salle réseau du département Télécommunications, Services et Usages.

- six radios logicielles NI USRP-2901 (voir figure 5.3) utilisées comme interfaces des UEs et de l'eNB pour la communication radio.

La figure 5.4 représente le placement des divers équipements et machines dans la salle. Nous avons placé dans la salle un cœur de réseau srsEPC qui va fonctionner sur une machine srsEPC. Cette machine se situe sur une première table de la salle. Sur une machine srsENB, située sur la table en face de la première, nous exécutons srsENB qui a le rôle d'émuler l'unique station de base que nous utiliserons pour toutes nos configurations d'eNB et pour toutes nos mesures. À cette machine est connecté sur un port USB 3.0 un USRP NI-2901 orienté en direction de la première table. Sur la première table à nouveau nous avons placé les UEs utilisés lors des différents scénarios de mesures sur les machines srsUEA, srsUEB, srsUEC, srsUED, srsUEE.
<figure><img src="image_28.png" /><figcaption>FIGURE 5.3 – USRP NI-2901 et ses 2 antennes VERT 2450</figcaption></figure>

<figure><img src="image_29.png" /><figcaption>FIGURE 5.4 – Plan du placement des éléments dans la salle.</figcaption></figure>
<table><caption>TABLE 5.3 – Liste des configurations de la cellule.</caption><thead><tr><th># Configuration</th><th>1</th><th>2</th><th>3</th><th>4</th><th>5</th><th>6</th><th>7</th><th>8</th><th>9</th><th>10</th></tr></thead><tbody><tr><td>BP (MHz)</td><td>2.5</td><td>2.5</td><td>2.5</td><td>2.5</td><td>2.5</td><td>2.5</td><td>2.5</td><td>5</td><td>5</td><td>5</td></tr><tr><td>BP (PRBs)</td><td>15</td><td>15</td><td>15</td><td>15</td><td>15</td><td>15</td><td>15</td><td>25</td><td>25</td><td>25</td></tr><tr><td>Gain (dBm)</td><td>60</td><td>65</td><td>70</td><td>75</td><td>80</td><td>85</td><td>90</td><td>60</td><td>65</td><td>70</td></tr><tr><td># Configuration</td><td>11</td><td>12</td><td>13</td><td>14</td><td>15</td><td>16</td><td>17</td><td>18</td><td>19</td><td>20</td></tr><tr><td>BP (MHz)</td><td>5</td><td>5</td><td>5</td><td>5</td><td>10</td><td>10</td><td>10</td><td>10</td><td>10</td><td>10</td></tr><tr><td>BP (PRBs)</td><td>25</td><td>25</td><td>25</td><td>25</td><td>50</td><td>50</td><td>50</td><td>50</td><td>50</td><td>50</td></tr><tr><td>Gain (dBm)</td><td>75</td><td>80</td><td>85</td><td>90</td><td>60</td><td>65</td><td>70</td><td>75</td><td>80</td><td>85</td></tr><tr><td># Configuration</td><td>21</td><td>22</td><td>23</td><td>24</td><td>25</td><td>26</td><td>27</td><td>28</td><td></td><td></td></tr><tr><td>BP (MHz)</td><td>10</td><td>20</td><td>20</td><td>20</td><td>20</td><td>20</td><td>20</td><td>20</td><td></td><td></td></tr><tr><td>BP (PRBs)</td><td>50</td><td>100</td><td>100</td><td>100</td><td>100</td><td>100</td><td>100</td><td>100</td><td></td><td></td></tr><tr><td>Gain (dBm)</td><td>90</td><td>60</td><td>65</td><td>70</td><td>75</td><td>80</td><td>85</td><td>90</td><td></td><td></td></tr></tbody></table>

### 5.3.2 Les différentes configurations évaluées

Le but de cette expérimentation est de mesurer le débit qu'obtient un UE seul ou en concurrence avec jusqu'à 4 autres UEs et pour plusieurs paramètres d'eNB. La liste des paramètres de l'eNB utilisé est présentée dans la table 5.3. Les paramètres que nous faisons varier sont la bande passante de la station de base, de 3 MHz à 20 MHz, ce qui correspond à un nombre de PRBs allant de 15 à 100. Nous faisons varier la bande passante de la station pour montrer que le débit obtenu dépend de la capacité maximale de la station à délivrer des ressources, alors que cette information n'est pas prise en compte lors de l'association. Nous faisons également varier le gain en émission de la station de base, puisqu'il s'agit de notre seul levier d'interaction avec srsRAN pour modifier la puissance d'émission de notre eNB. En effet, srsENB étant un logiciel, seul l'équipement radio, l'USRP ici, a la capacité de modifier la puissance d'émission. Et comme srsENB peut fonctionner avec de multiples radios logicielles différentes et qu'il ne connaît pas à l'avance laquelle sera utilisé, le seul paramètre modifiable dans srsENB est le gain d'émission de la radio logicielle. Ce gain d'émission variera entre 60 dBm et 90 dBm dans notre scénario. Ces valeurs de gain sont déterminées empiriquement. Nous choisissons la valeur minimale 60 dBm car en dessous de cette valeur l'émission est trop faible pour que les entités arrivent à communiquer entre elles. Et nous choisissons la valeur maximale 90dBm car au-delà, l'alimentation de notre USRP, par port USB, devient insuffisante pour alimenter correctement l'appareil. Il y a en tout 28 combinaisons de configurations d'eNB mélangeant les paramètres cités. Nous pourrons alors observer à quel point le gain d'émission de l'eNB et donc le RSRP correspondant mesuré par l'UE sont important par rapport à la capacité maximale de l'eNB et par rapport au nombre d'UEs déjà présents lorsque nous souhaitons obtenir le meilleur débit descendant possible.

### 5.3.3 Mesure du débit et l'outil Iperf

Pour la réalisation des mesures de débit nous prenons l'outil Iperf souvent utilisé par la communauté réseau et dans la littérature. Nous réalisons des mesures de
débit utilisant le protocole de transport TCP au dessus d'IP. Nous cherchons à mesurer dans nos scénarios le débit descendant applicatif obtenu par l'UE. Les avantages d'utiliser Iperf avec TCP sont que le débit maximal sera graduellement atteint grâce aux mécanismes propres à TCP et qu'il s'agit d'un protocole de transport représentatif du trafic présent dans un réseau cellulaire commercial. Nous plaçons alors un serveur Iperf sur la même machine que l'UE et un client Iperf sur la même machine qui héberge srsENB. Si plusieurs UEs sont présents dans notre scénario, chaque machine hébergeant un UE aura son propre serveur Iperf et la machine qui héberge l'EPC aura autant de clients Iperf que d'UEs présents dans le scénario. Le client Iperf connaît par avance l'adresse IP de la machine à laquelle il doit se connecter car nous avons fixé dans la base de données HSS de l'EPC une règle d'adressage IP fixe pour chaque UE comme expliqué dans le chapitre 4. La figure 5.5 est une capture de la base HSS utilisée et contient les adresses IPs imposées à chacun des UEs lors de son attachement au réseau cellulaire. Un exemple des lignes de commandes bash exécutées par les scripts Python présentés précédemment est donné dans le code ci-après :

```
# exemple de serveur Iperf execute sur la machine A (UE1)
iperf -s -p 5002
# exemple de serveur Iperf execute sur la machine C (UE2)
iperf -s -p 5002
# exemple de serveur Iperf execute sur la machine D (UE3)
iperf -s -p 5002
# exemple de clients Iperf executes sur la machine F (EPC)
iperf -c 172.16.0.2 -t 10 -p 5002
iperf -c 172.16.0.3 -t 10 -p 5002
iperf -c 172.16.0.4 -t 10 -p 5002
```

Le paramètre "-c" indique que Iperf doit être utilisé en tant que client. Il est suivi de l'adresse IP du serveur Iperf avec lequel se connecter. Le paramètre "-s" indique que Iperf doit être exécuté en tant que serveur. Le paramètre "-t" spécifie la durée de la mesure et le paramètre "-p" le numéro de port utilisé par le serveur.

```
1# .csv to store UE's information in HSS
2# .csv to store UE's information in HSS
3# Kept in the following format: "Name,Auth,IMSI,Key,OP_Type,OP/OPc,AMF,SQN,QCI,IP_alloc"
4# Kept in the following format: "Name,Auth,IMSI,Key,OP_Type,OP/OPc,AMF,SQN,QCI,IP_alloc"
5# Name: Human readable name to help distinguish UE's. Ignored by the HSS
6# Auth: Authentication algorithm used by the UE. Valid algorithms are XOR
7# (xor) and MILENAGE (mil)
8# IMSI: UE's IMSI value
9# Key: UE's key, where other keys are derived from. Stored in hexadecimal
10# OP_Type: Operator's code type, either OP or OPC
11# OP/OPc: Operator Code/Cyphered Operator Code, stored in hexadecimal
12# AMF: Authentication management field, stored in hexadecimal
13# SQN: UE's Sequence number for freshness of the authentication
14# QCI: QoS Class Identifier for the UE's default bearer.
15# IP_alloc: IP allocation strategy for the SPGW.
16# With 'dynamic' the SPGW will automatically allocate IPs
17# With a valid IPv4 (e.g. '172.16.0.2') the UE will have a statically assigned IP.
18# With a valid IPv4 (e.g. '172.16.0.2') the UE will have a statically assigned IP.
19# Note: Lines starting by '*' are ignored and will be overwritten
20 ue1,xor,001010123456789,00112233445566778899aabbccddeeff,opc,63bfa50ee6523365ff14c1f45f88737d,9001,0000000001b3e,7,172.16.0.2
21 ue2,xor,001010123456792,00112233445566778899aabbccddeeee,opc,63bfa50ee6523365ff14c1f45f88737d,9002,0000000001a99,7,172.16.0.3
22 ue3,xor,001010123456793,00112233445566778899aabbccddeedd,opc,63bfa50ee6523365ff14c1f45f88737d,9003,000000000000,7,172.16.0.4
23 ue4,xor,001010123456794,00112233445566778899aabbccddeeee,opc,63bfa50ee6523365ff14c1f45f88737d,9004,000000000000,7,172.16.0.5
24 ue5,xor,001010123456795,00112233445566778899aabbccddeebb,opc,63bfa50ee6523365ff14c1f45f88737d,9005,000000000000,7,172.16.0.6
25 ue6,xor,001010123456796,00112233445566778899aabbccddeaaa,opc,63bfa50ee6523365ff14c1f45f88737d,9006,000000000000,7,172.16.0.7
```

<caption>FIGURE 5.5 – Contenu du fichier de configuration de la base de données HSS.</caption>

Nous testons donc les débits applicatifs obtenus par notre/nos UE/UEs pour les 28 configurations de la station de base. Comme expliqué au chapitre 4, la durée d'un
cycle de mesures étant relativement long, à cause de la mise en place des diverses en-
tités srsRAN, nous ne pouvons réaliser un nombre trop important de mesures pour
chaque scénario ni faire durer nos mesures de débits sur une trop longue période.
Pour chaque configuration, nous choisissons d'en réaliser 10 et nous extrayons la
moyenne du débit obtenu. La durée de chaque mesure est fixée à 10 secondes. Les
valeurs de 10 mesures et de 10 secondes sont choisies afin de trouver un compromis
entre représentativité et durée totale des expérimentations. En effet, il faut réaliser
ici au total 1 400 mesures (28 combinaisons * 5 UEs * 10 répétitions) et plus s'il y a
un échec lors de la mesure. Chaque mesure est réalisée au sein d'un cycle de notre
script Python qui dure en moyenne 1 minute par cycle, le temps de s'assurer que tous
les éléments soient prêts à la réalisation de la mesure. Ce qui conduit au minimum
à 23 heures d'expérimentations. À ce temps minimum viennent s'ajouter le temps
d'installation de la plateforme, des changements de matériels et de logiciels entre
certaines configurations. Puisque nous utilisons une salle de TP du département Té-
lécommunications, Services et usages, il a fallu plusieurs fois ranger le matériel pour
laisser place au déroulement d'autres TP avant de réinstaller la plateforme. Il vient
également s'ajouter un temps de récupération des données sur les machines utilisées
qui disposent d'une mémoire de stockage extrêmement limitée (2 Go), alors que le
nombre total de fichiers récupérés sur l'ensemble des machines est lui de plus de 94
000, ce qui représente un volume de 48Go. De plus, il faut être capable de détecter
dans tous les fichiers récupérés s'il y a eu une erreur lors d'une mesure et recommen-
cer lesdites mesures si nécessaire. Ce qui est arrivé plus fréquemment qu'anticipé,
à cause principalement d'un échec de la procédure RACH d'un des UEs à l'eNB.
Parmi les 48Go de données récupérés au total, nous extrayons 10 Go de données
utiles au traitement des résultats. Le reste étant des mesures ayant échouées ou des
mesures réalisées en surplus par anticipation d'éventuelles erreurs. Les résultats ob-
tenus sont présentés dans la section suivante.

5.4 Résultats

Suite aux expérimentations et au traitement des données nous obtenons plu-
sieurs matrices de débits moyens obtenus et de RSRP moyens mesurés. Tous ces
résultats sont rassemblées dans la figure 5.6 pour une plus grande facilitée de com-
paraison des résultats entre eux. Sur la colonne de gauche apparaissent les matrices
de débits moyens obtenus triées par nombre d'UEs ayant participé simultanément
à la mesure. Sur la colonne de droite apparaissent les matrices de RSRP moyen me-
suré pendant ces mêmes mesures. Cette figure peut être considérée comme une carte
de l'association qui permet de choisir quelles configurations de stations nous per-
mettent d'atteindre un débit minimal souhaité.

La figure 5.7, quant à elle, affiche sur la colonne de gauche le MCS (Modulation et Schéma de Codage) moyen utilisé par la station pour communiquer sur le canal descendant et sur la colonne de droite le SNR moyen mesuré par les UEs. Ces matrices sont classées de la même manière et correspondent également aux mêmes mesures que la figure précédente. Toutes ces matrices sont disponibles individuellement en annexe A pour une meilleure visibilité.

5.4.1 Évolution du débit moyen

En nous concentrant premièrement sur la première colonne de la figure 5.6 on
constate sans trop de surprise que, quels que soient le nombre d'UEs et la bande
<figure><img src="image_30.png" /><figcaption>FIGURE 5.6 – Matrices des débits moyens et RSRP moyens mesurés.</figcaption></figure>
<figure><img src="image_31.png" /><figcaption>FIGURE 5.7 – Matrices des SNRs et MCSs moyens mesurés.</figcaption></figure>
passante de la cellule, le débit moyen obtenu augmente avec la puissance d'émission utilisée par la station de base. Ceci s'explique dans 5.7 par le fait qu'avec une meilleure puissance du signal, la station de base peut émettre des symboles sur ces éléments de ressources utilisant des MCS plus complexes. Plus le MCS utilisé est élevé, plus le nombre de bits transmis par symbole, et donc par seconde, est important. Et ici, le MCS moyen utilisé augmente avec le gain en émission utilisé. Pour rappel, en LTE, les valeurs de MCS utilisés vont de 0 à 31.

De la même manière, quels que soient le nombre d'UEs et le gain utilisé en émission, le débit moyen obtenu augmente avec la taille de la bande passante de la cellule. Ceci s'explique par le fait que, plus la bande est large, plus le nombre de blocs de ressources utilisés pour la communication par unité de temps augmente. On notera toutefois ici que le SNR mesuré ainsi que le MCS utilisé décroissent eux légèrement lors de l'augmentation de la taille de la bande passante. Le débit moyen mesuré étant lui en augmentation lorsque le nombre de PRBs augmente, on peut supposer que l'augmentation de la taille de la bande passante est plus importante que la réduction du MCS moyen utilisé.

Troisièmement, pour des paramètres de PRBs et de gains fixes, le débit moyen mesuré décroît alors que le nombre d'UEs se partageant les ressources de la station augmente. Ce comportement n'a rien de surprenant non plus car la station de base ne dispose que d'un montant fixe de ressources radios à fournir. Et si un utilisateur peut prendre la totalité des ressources lorsqu'il est seul, la station de base doit distribuer les ressources entre les UEs s'ils sont plus nombreux.

Dans un dernier temps nous allons discuter les résultats non attendus. On peut constater sur la figure 5.6 que, pour plusieurs résultats, notamment lors du passage de configurations d'un gain de 80 dBm à un gain de 90 dBm, les tendances évoquées plus tôt sont fausses. Lors de se passage de 80 dBm à 90 dBm, le débit à tendance dans plusieurs cas à être constant, voir même à décroître. Nous attribuons ce phénomène à deux raisons principales qui s'impactent l'une l'autre :

1. L'alimentation insuffisante des USRP pour la plus grande valeur de gain. Les USRP étant alimentés par port USB, certains n'arrivent pas à fournir plus de puissance lors de l'émission pour un passage de gain supérieur à 80 dBm. Ce constat est d'autant plus élevé dans les configurations impliquant 4 ou 5 UEs, puisqu'il suffit qu'un seul de ces UEs soit moins performant que les autres pour faire chuter la moyenne.

2. La deuxième raison intervient surtout dans les scénarios impliquant 4 ou 5 UEs. Plus le nombre d'UEs dans nos scénarios est important, plus la probabilité d'avoir un UE qui ne réussit pas à faire sa mesure est élevé. Nous avons, dans ces scénarios, réalisé plus de tentatives que dans les autres pour obtenir nos 10 mesures et d'en faire la moyenne. Et ces tentatives se sont vues êtres réalisées sur plusieurs journées différentes, avec des conditions radios différentes et avec potentiellement des USRPs ou des antennes différentes sur les 10 mesures réussies.

## 5.4.2 Évolution du RSRP

Le RSRP est actuellement utilisé comme base du tri des différentes cellules voivesines. Il devrait donc être étroitement lié au débit obtenu pour chacune de ces stations puisque l'objectif de ce tri est de s'associer à la meilleure. Observons l'évolution du RSRP au travers de nos résultats.

En nous concentrant maintenant sur la deuxième colonne de la figure 5.6, on constate que, quels que soient le nombre d'UEs et la bande passante de la cellule, le
<table><caption>TABLE 5.4 – Différences de débits et RSRP entre les configurations A et B.</caption><thead><tr><td>Configuration</td><td>PRBs</td><td>Gain</td><td>Nombre d'UEs</td><td>RSRP moyen</td><td>Débit moyen</td></tr></thead><tbody><tr><td>A</td><td>100</td><td>90</td><td>1</td><td>-75,8 dBm</td><td>50 Mb/s</td></tr><tr><td>B</td><td>100</td><td>90</td><td>5</td><td>-73,1 dBm</td><td>6,8 Mb/s</td></tr></tbody></table>

<table><caption>TABLE 5.5 – Différences de débits et RSRP entre les configurations A, B et C alors que le nombre d'UEs est fixe.</caption><thead><tr><td>Configuration</td><td>PRBs</td><td>Gain</td><td>Nombre d'UEs</td><td>RSRP moyen</td><td>Débit moyen</td></tr></thead><tbody><tr><td>A</td><td>100</td><td>70</td><td>4</td><td>-93,1 dBm</td><td>6,0 Mb/s</td></tr><tr><td>B</td><td>50</td><td>75</td><td>4</td><td>-89,6 dBm</td><td>4,9 Mb/s</td></tr><tr><td>C</td><td>25</td><td>90</td><td>4</td><td>-81,0 dBm</td><td>3,3 Mb/s</td></tr></tbody></table>

RSRP moyen mesuré augmente avec la puissance d'émission utilisée par la station de base. Le RSRP a donc le même comportement que le gain sur ce point.

Quels que soient le nombre d'UEs et le gain utilisé en émission, le RSRP moyen mesuré augmente avec la taille de la bande passante de la cellule. Ce comportement est donc similaire à celui du débit mesuré. En revanche, le SNR a le comportement inverse, le SNR décroît lorsque la taille de la bande passante augmente. Le SNR est un rapport entre la puissance du signal et le bruit sur la bande passante. Le RSRP quant à lui est uniquement une mesure de puissance des signaux de références sur les REs de références. Mon hypothèse est donc que, si le bruit augmente à la taille de la bande passante, le SNR va décroître, car le bruit est le dénominateur de ce rapport, alors que le RSRP non.

C'est sur le point suivant que le comportement du RSRP diverge avec celui du débit mesuré. Dans le cas où le gain et les PRBs de la station sont fixes, le RSRP reste constant, alors que le débit moyen décroît lors de l'ajout d'UEs concurrents. Si on prend pour exemple deux configurations de cellules A et B détaillées dans le tableau 5.4, on constate que le RSRP mesuré est supérieur de 2,7 dBm dans la configuration B alors que la perte de débit engendrée, de -86,4%, est très significative. Cet exemple-là fait partie des raisons qui motivent notre argumentation d'un besoin pour l'UE d'obtenir une information de charge restante de la station à laquelle il pourrait s'associer, ce qui est en accord avec les travaux de la littérature sur le partage d'information [67] sur l'association α-optimale [64].

De plus, d'après nos résultats, le RSRP n'est ici pas proportionnel au débit obtenu et ce même dans le cas où le nombre d'UEs se partageant la station de base est égal. Un exemple de cette assertion est présenté dans le tableau 5.5 où les cellules sont classées par ordre de RSRP croissant mais que les débits obtenus sont décroissants. Cet exemple ici montre dans notre cas que l'augmentation de la bande passante impacte plus le débit moyen gagné que le RSRP moyen. Ce qui entraîne un déséquilibre dans la relation RSRP et débit espéré.

Dans la section suivante nous allons pousser plus loin l'étude des limites de l'association meilleur SINR. Nous allons quantifier la probabilité que l'association meilleur SINR choisisse, sans information de charge, la station donnant le meilleur