débit.

5.5 Étude des limites

Dans cette section nous allons étudier les limites de l'association meilleur SINR grâce aux résultats obtenus dans la section précédente. L'association meilleur SINR pratique, si l'on met de côté les offsets fixés par l'opérateur, un classement des cellules basé uniquement sur le RSRP mesuré des stations de bases voisines. Les stations sont triées par ordre de RSRP décroissant et celle avec le meilleur RSRP est donc choisie comme station hôte. Le problème que l'on constate avec les résultats précédents est que l'on peut, dans de nombreux cas, trouver des configurations de stations de bases qui fournissent à l'utilisateur un débit plus important alors que le RSRP de ces stations perçues par l'UE est plus faible.

Cette étude a pour but, dans un premier temps, de quantifier par simulation, le nombre de fois où le tri des cellules réalisé par l'association meilleur SINR fournit à l'UE la station qui donne expérimentalement le meilleur débit.

Sans avoir à changer le fonctionnement de la station de base, l'UE a déjà accès, grâce au MIB, à l'information de la bande passante totale de la station. Même si cette information n'est pas une information sur la charge instantanée de la station, il s'agit tout de même d'une information de charge maximale qui peut être exploitée par notre UE. Notre second objectif est de rajouter deux autres types de simulations dans lesquelles le tri des cellules s'effectuera en premier lieu sur le nombre de PRBs de la station détectée, afin de comparer son impact par rapport au tri réalisé en fonction du RSRP. Nous utilisons le jeu de données présenté à la section précédente comme source de valeurs de débits, de RSRPs et d'utilisateurs concurrents présents à l'état "RRC connecté" sur la cellule lors de nos simulations. La liste suivante détaille les différents types de tris réalisés :

- Tri **RSRP**: Les cellules sont classées par ordre de leur **RSRP** décroissant. On compte combien de fois la première cellule est celle qui donne le meilleur débit parmi les cellules de notre tirage.

- Tri **PRBs -> RSRP**: Les cellules sont classées par ordre décroissant de leur nombre de **PRBs**. En cas d'égalité, elles sont départagées par ordre de **RSRP** décroissant. On compte combien de fois la première cellule est celle qui donne le meilleur débit parmi les cellules de notre tirage.

- Tri **PRBs (borne sup)**: Les cellules sont classées par ordre décroissant de leur nombre de **PRBs**. En cas d'égalité en première position, on regarde si une de ces cellules à égalité fournit le meilleur débit. On obtient alors ainsi une **borne supérieure** théorique du nombre de fois où l'on pourrait choisir la meilleure cellule en triant d'abord par nombre de PRBs décroissants.

Nous réalisons dans cette section des simulations des trois types de tris proposés précédemment. Le scénario des simulations est le suivant :

Un UE réalise des mesures de RSRP de K cellules candidates voisines. La configuration $C_K$ de chaque cellule candidate est tirée aléatoirement sans remise parmi les N configurations issues de nos expérimentations précédentes. L'UE réalise un tri de ces K cellules en fonction de chacune des règles de tris énoncées plus tôt. Il existe $C_N^K$ combinaisons différentes possibles de cellules voisines. Nous simulons le tri réalisé par l'UE pour l'ensemble de ces $C_N^K$ combinaisons. Puis nous comptons le pourcentage de combinaisons pour lesquels le tri réalisé résulte en un classement en première position de la cellule qui fournit à l'UE le meilleur débit.
<table><caption>TABLE 5.6 – Nombre de combinaisons de k éléments parmi 140 sans remise.</caption><thead><tr><td>Nombre de cellules K voisines</td><td>Nombre de combinaisons C<sup>K</sup><sub>N</sub> différentes</td></tr></thead><tbody><tr><td>2</td><td>9 730</td></tr><tr><td>3</td><td>447 580</td></tr><tr><td>4</td><td>15 329 615</td></tr><tr><td>5</td><td>416 965 528</td></tr></tbody></table>

<table><caption>TABLE 5.7 – Pourcentage de réussite du tri des cellules par types de tris réalisés.</caption><thead><tr><td></td><td>RSRP</td><td>PRBs -> RSRP</td><td>PRBs (borne sup)</td></tr></thead><tbody><tr><td>2 eNBs</td><td>67,42%</td><td>75,03%</td><td>83,32%</td></tr><tr><td>3 eNBs</td><td>53,54%</td><td>63,97%</td><td>74,98%</td></tr><tr><td>4 eNBs</td><td>46,00%</td><td>57,21%</td><td>70,70%</td></tr><tr><td>5 eNBs</td><td>41,23%</td><td>52,55%</td><td>68,45%</td></tr></tbody></table>

Nous disposons de 28 configurations possibles de paramètres de cellules qui sont listées dans le tableau 5.3. Puisque nous utilisons le jeu de données obtenu plus tôt dans ce chapitre, nous disposons de résultats d'une cellule qui applique ces 28 combinaisons de paramètres pour un nombre d'UE connectés et actifs allant de 1 juqu'à 5. Nous disposons donc de résultats pour un ensemble de configurations de cellules N égal à 140.

Le tableau 5.6 donne le nombre K de cellules voisines utilisés pour nos simulations ainsi que le nombre $C_N^K$ de combinaisons résultantes du calcul 5.6.

$$C_N^K = \frac{N!}{K!(N-K)!} \qquad (5.6)$$

Le script python ayant servi à effectuer la simulation est disponible dans mon GitLab INRIA [84] sous le nom de "combinaisons.py".

Les résultats de la simulation sont affichés dans la table 5.7. On constate que le tri **RSRP** de l'association meilleur SINR classe en premier la meilleure cellule en termes de débit dans 67,42% des combinaisons de 2 cellules issues de nos mesures expérimentales. Ce nombre décroît jusqu'à 41,23% quand des combinaisons de 5 cellules de nos mesures expérimentales sont classées. Ce résultat témoigne que l'association meilleur SINR actuelle n'est pas parfaite et peut être améliorée.

Le tri **PRBs -> RSRP** donne une sélection de meilleure cellule améliorée de 7,5% de plus que l'association meilleur SINR lorsque deux cellules sont à portées et jusqu'à 11% de plus lorsque 5 cellules sont à portée radio. La simulation du tri **PRBs (borne sup)** indique ici une borne supérieure du pourcentage de bonne sélection que l'on peut réaliser, avec un premier tri réalisé en fonction des PRBs de la cellule, pour notre jeu de données. On constate donc que le tri des cellules basé premièrement sur la bande passante de la cellule apporte déjà un gain par rapport à la sélection de cellule classique.

Dans le chapitre 6 nous comparerons les résultats obtenus ici avec ceux d'une association basée sur le nombre d'UEs concurrents à l'état "RRC connecté" sur la
cellule.

## 5.6 Conclusion et perspectives

Dans ce chapitre nous avons réalisé des mesures expérimentales de débit obtenu par un UE en fonction de la configuration de la station de base à laquelle il est as-socié, ainsi qu'en fonction du nombre d'UEs concurrents associés à la même cellule. Ces résultats démontrent que le débit obtenu n'est pas uniquement lié au RSRP me-suré par l'UE mais qu'il dépend de plusieurs paramètres qui ne sont actuellement pas pris en compte lors de l'association meilleur SINR. Parmi ces paramètres non pris en compte se trouve notamment l'information de charge actuelle de la station de base qui peut s'avérer être la cause de très grosses baisses de performances.

Nous essayons ensuite de quantifier grâce à nos données expérimentales quel est le pourcentage de scénarios dans lequel l'association meilleur SINR donne à l'UE la cellule qui fournit le plus grand débit. Nous constatons que ce pourcentage est de 67,42% dans le meilleur des cas et qu'il peut être amélioré jusqu'à 83,32% dans un cas prenant comme information supplémentaire une information déjà présente dans le MIB : la bande passante de la station.

Nous pensons toutefois que ces résultats peuvent encore être améliorés en dis-posant d'une information de charge dynamique de la cellule si elle pouvait être dif-fusée par cette dernière. Nous parlions précédemment de la figure 5.6 comme d'une carte de l'association. Les résultats obtenus ici peuvent servir de guide quant à une association visant à obtenir le meilleur débit possible en fonction de différents pa-ramètres des stations de base alentour. En effet, si nous avons autour de nous, par exemple, 3 stations avec des combinaisons de paramètres différents, nous pourrions grâce à cette carte déterminer directement laquelle de ces trois stations nous apporte-rait le meilleur débit. Le problème d'une telle association dans les réseaux cellulaires actuels est que l'UE ne peut pas obtenir le nombre d'UEs actuellement connectés avec le protocole RRC sur les stations de base. Nous avons donc besoin d'un par-tage d'information de la station de base concernant le nombre d'UEs connectés avec le protocole RRC sur cette dernière. Ou à défaut n'importe quelle information de charge qui pourrait remplir ce rôle-là.

Dans le chapitre suivant, nous discutons des choix possibles d'information de charge à diffuser à notre disposition. Nous discutons ensuite de l'emplacement au-quel diffuser cette information de charge. Nous montrons enfin l'impact d'une telle diffusion sur la sélection de cellule et proposons de réaliser cette expérimentation en modifiant directement le code source de srsRAN.
# Chapitre 6

## Association avec facteur de charge

### 6.1 Introduction

Dans le chapitre précédent nous avons montré que l'association dite "meilleur SINR" n'est pas optimale car elle est complètement agnostique de la charge courante de la station de base et donc de la capacité qu'elle est capable de fournir à un nouvel arrivant. Nous proposons donc de modifier l'association en considérant une association basée sur une information de charge que l'on nommera *le facteur de charge*. Nous proposons que cette information soit dynamique, en fonction du nombre d'utilisateurs, de la charge de trafic et qu'elle soit diffusée par les stations de base. Nous discutons cette proposition puis nous discutons de sa faisabilité dans srsRAN.

Dans ce chapitre nous discutons d'abord de ce qui serait une pertinente information de charge, sur quelle métrique elle doit être basée et comment obtenir cette information. Puis nous discutons de comment diffuser cette information de charge par la station de base. Pour cela nous devons d'abord réintroduire quelques notions sur le MIB. Nous discutons de pourquoi nous choisissons le MIB comme porteur de cette information et expliquons comment il est possible d'implémenter ce partage d'information dans srsRAN ainsi que sa bonne réception et utilisation du côté de l'UE pour réaliser sa sélection de cellule principalement en fonction de cette information. Pour cela nous détaillons l'architecture du code source de srsRAN et les modifications à lui apporter pour implémenter *le facteur de charge* et son utilisation. Nous réalisons ensuite, de la même manière qu'au chapitre 5, une étude du nouveau tri des cellules proposé, basé sur le facteur de charge, et le comparons aux résultats du chapitre 5. Puis nous concluons ce chapitre en ajoutant plusieurs perspectives à ces travaux.

### 6.2 Le facteur de charge, une information de charge

Nous pensons que les stations de base devraient diffuser une information de charge concernant leur capacité courante pour laisser aux UEs le choix de la station à laquelle s'associer. Mais quelle est exactement cette information de charge et en quoi consiste-t-elle ? Plusieurs métriques sont candidates pour remplir ce rôle et nous allons discuter de ces candidats.

#### 6.2.1 Les PRB (Physical Ressource Blocks) ou les REs (Ressource Elements)

La première métrique à laquelle nous avons pensé est le nombre de PRBs ou REs alloués aux UEs, à chaque sous-trame, par la station de base. Ces deux métriques sont similaires, les PRBs sont constitués de REs, mais tous les REs d'un PRB ne sont pas forcément tous utilisés dans le même but que le PRB qui les englobe. Obtenir le nombre de REs total alloués par sous-trames aux UEs est l'information la plus
précise que l'on peut obtenir pour représenter la charge de la BS. Cependant nous n'avons pas nécessairement besoin d'une telle précision pour le facteur de charge, le nombre de PRB alloué est suffisamment représentatif de la charge de la BS pour être utilisé également.

Pour obtenir cette information du nombre de PRBs ou de REs alloués aux UEs, il est nécessaire de récupérer la grille d'attribution des ressources générée par l'ordonnanceur de la station de base à chaque sous-trame. Cette opération n'est pas triviale mais nous avons trouvé l'emplacement de cette fonction dans srsRAN et le moyen d'extraire ces informations si nous choisissons cette métrique comme facteur de charge à diffuser.

Bien que, théoriquement, connaître le pourcentage de PRBs utilisé en temps réel soit une bonne idée, son utilisation dans un cas pratique est plus compliquée. Comme montré dans le chapitre 4 lors de l'utilisation d'un téléphone pour trafiquer sur le site Twitch, l'utilisation des PRBs dans la figure 4.11 passe aussi tôt de 50 à 0 PRBs en une sous-trame d'écart. Cette valeur varie trop vite et trop grandement pour être utilisé en temps réel. La station risque d'utiliser le nombre maximum de PRBs pour un seul utilisateur mais cela ne signifie pas qu'elle ne peut pas fournir un très bon débit à un deuxième utilisateur. Il faudrait réaliser un traitement sur cette valeur pour avoir une information de charge pertinente tel que réaliser une fenêtre glissante sur l'évolution de cette valeur au cours des sous-trames.

### 6.2.2 Les RNTIs (Radio Network Temporary Identifiers)

La seconde métrique à laquelle nous avons pensé est le nombre de RNTIs utilisés par la station de base. Lorsqu'un UE réalise une association avec la BS ou qu'il reçoit un message de paging, il doit réaliser une procédure RACH et ainsi obtenir un identifiant temporaire, le RNTI, qu'il conservera tant qu'il aura besoin de ressources de la part de la station. Ce RNTI est conservé tant que l'UE est connecté à la station avec le protocole RRC. Si l'utilisateur n'utilise plus de ressources pendant 30 secondes, il passe à l'état inactif et son RNTI est libéré. Le nombre total de RNTI utilisateurs alloués par la station de base est donc un indicateur de charge potentiel de la station de base. La présence d'un RNTI ne donne pas avec précision la quantité de ressources que l'UE utilise, mais du fait qu'au bout de 30 secondes d'inactivité le RNTI soit libéré, cela nous garantit que l'UE utilise bien des ressources tout de même. Cette valeur est bien moins précise que celle des PRBs et REs mais est tout de même représentative de l'activité d'une cellule à l'échelle de la minute.

Pour obtenir cette information il faut compter le nombre de RNTI utilisateurs actuellement utilisés par la station de base. Nous avons également trouvé dans srsRAN la liste des RNTI attribués.

### 6.2.3 Les Downlink Control Information (DCIs)

Plusieurs papiers de la littérature proposent des outils d'analyse des trames LTE qui permettent à l'UE d'obtenir une estimation de la charge actuelle de la station de base. Pour cela, ces outils, tels que OWL [74], Falcon [75] et LTEyes [76], proposent de scanner les DCIs contenus dans le canal PDCCH pour obtenir l'ordonnancement réalisé par l'eNB des PRBs attribués aux UEs et ainsi, une estimation de sa charge sur le lien descendant. Les DCIs sont notifiés aux UEs par leur identifiant temporaire dans le réseau, le RNTI. Les DCIs fournissent aux UEs un planning des PRBs qui leur sont alloués en émission ou en réception. Les informations de la distribution
des PRBs sur le lien descendant s'effectuent via le canal PDCCH. Les informations de la distribution des PRBs sur le lien montant s'effectuent via le canal PUCCH.

Si on disposait de toutes ces informations à l'avance sur un UE on pourrait connaître la charge totale actuelle de la station en temps réel et baser son choix des-sus. Cependant l'utilisation des outils de scan semble bien trop consommatrice en énergie et trop lente pour que l'UE puisse s'en servir efficacement pour la sélection de cellule. Il n'y a pas besoin de gaspiller l'énergie de l'UE à décodeer tous les DCIs de toutes les trames alors que l'information désirée pourrait tenir dans un seul champ d'information diffusé à une position connue à l'avance. De plus, décodeer tous ces DCIs pour toutes les cellules candidates serait beaucoup trop long.

Nous proposons pour la suite de ce chapitre d'utiliser le RNTI comme information de charge pour être diffusée dans le facteur de charge. Tout d'abord car, dans un souci de validation expérimentale de notre proposition, il nous a été plus simple de modifier le code source de srsRAN dans ce sens. Puis également car nous pensons que cette métrique, comparée à celle de l'utilisation des PRBs, fourni en l'état et sans avoir besoin d'un traitement, une information de charge plus stable.

Nous pensons tout de même que l'utilisation des PRBs mérite d'être étudiée plus en détail dans de futurs travaux.

## 6.3 Les moyens de diffuser le facteur de charge

### 6.3.1 Le Master Information Block (MIB)

Le MIB a pour rôle de donner les principales informations concernant la station à l'UE. Lorsqu'un UE cherche une nouvelle station il ne connaît que sa fréquence porteuse. Il ne connaît donc pas la largeur de la bande passante du système, l'em-placement et la taille des divers canaux évoqués précédemment et n'est pas synchro-nisé de manière temporelle avec les différentes trames. Le MIB est là pour aider un nouvel arrivant à se synchroniser avec la station de base. Étant donné que l'UE ne connaît pas à l'avance la largeur de la bande passante de la station, le canal PBCH, qui contient le MIB, est toujours placé au centre de la bande passante sur 6 PRBs placés autour de la fréquence porteuse. Ainsi, peu importe la taille de la bande pas-sante, l'UE trouvera toujours le MIB. Le MIB indique premièrement la largeur de la bande passante de la porteuse, aidant ainsi l'UE à se synchroniser en fréquence. Il contient aussi le numéro de la trame actuelle. Le canal PBCH étant également tou-jours situé sur la première sous-trame de la trame LTE, l'UE a ainsi une meilleure perception temporelle d'où se situe la suite des informations qu'il cherche, contenus dans les SIBs. La figure 6.1 est une capture d'image du document 3GPP TS 136 331 [88] qui détaille le contenu du MIB. Le contenu du MIB et de ses champs est détaillé ci-après :

- dl-Bandwidth : représente la bande passante du système, en nombre de PRBs. Il prend des valeurs allant de 6 PRBs jusqu'à 100 PRBs.

- phich-Config : représente la configuration du canal PHICH et le format utilisé pour la représentation d'acquittements positifs ou négatifs sur cette cellule.

- systemFrameNumber : ce terme exprime le numéro de la trame en cours.

- schedulingInfoSIB1-BR-r13 : l'information donnée ici pointe vers un index d'un tableau que l'UE connaît à l'avance. Ce tableau contient diverses com-binaisons de placement du SIB1 au travers de la trame LTE. Les informations du placement des autres SIBs sont quant à eux contenu dans le SIB1.

- systemInfoUnchanged-BR-r15 : ce champ est un booléen qui indique qu'il n'y a pas eu de modification récente du contenu d'un des SIBs, permettant à un
MasterInformationBlock

-- ASN1START

<table><caption>FIGURE 6.1 – Capture d'écran du MIB défini dans le document TS 136 331 de la 3GPP.</caption><thead><tr><th></th><th></th></tr></thead><tbody><tr><td>MasterInformationBlock ::=</td><td>SEQUENCE {</td></tr><tr><td>dl-Bandwidth</td><td>ENUMERATED {</td></tr><tr><td>phich-Config</td><td>n6, n15, n25, n50, n75, n100},</td></tr><tr><td>systemFrameNumber</td><td>PHICH-Config,</td></tr><tr><td>schedulingInfoSIB1-BR-r13</td><td>BIT STRING (SIZE (8)),</td></tr><tr><td>systemInfoUnchanged-BR-r15</td><td>INTEGER (0..31),</td></tr><tr><td>spare</td><td>BOOLEAN,</td></tr><tr><td></td><td>BIT STRING (SIZE (4))</td></tr></tbody></table>

UE qui aurait déjà récupéré ces informations de ne les décodeur à nouveau que s'il y a du changement dans les informations diffusées.

- spare : ce champ d'une taille de 4 bits est actuellement inutilisé et initialisé à une valeur de zéro. Ce champ est réservé en cas de besoin d'extension des informations à diffuser au travers du MIB.

<figure><img src="image_32.png" /><figcaption>FIGURE 6.2 – Le MIB et ses répétitions.</figcaption></figure>

Cette information d'un champ inutilisé de 4 bits à l'intérieur du MIB constitue une opportunité parfaite d'emplacement pour introduire notre valeur de facteur de charge à diffuser et à coût nul, puisque le champ existe déjà. Le MIB a de plus l'avantage d'être le premier champ d'information diffusé par la station. Son contenu cependant ne peut être modifié que toutes les 4 trames. Comme le montre la figure 6.2, l'information contenue dans le MIB est une première fois diffusée sur le premier PRB d'une trame LTE, puis il est répété 10 milisecondes plus tard, la durée d'une trame LTE, pour réapparaître dans le premier PRB de la trame suivante. Il y a ainsi 3 répétitions du MIB d'origine avant de pouvoir en diffuser un autre avec de nouvelles valeurs. De plus, le décodage du MIB est une étape obligatoire lorsqu'un UE cherche à acquérir des ressources auprès d'une station de base. Ce champ dénommé "spare" contenu dans le MIB nous apparaît donc comme un excellent moyen de diffuser une information de charge pour notre proposition. Ainsi, chaque UE pourrait connaître l'état de chaque BS avec un délai maximum de 40ms. Par ailleurs, utiliser le champ spare ne nécessite pas d'apporter de modification à l'architecture de diffusion de l'information actuelle mais simplement de donner à ce champ rempli de 4 bits à zéro une autre valeur qui serait définie comme la charge de la station de base actuelle. L'inconvénient toutefois d'utiliser le champ "spare" est qu'il n'est composé que de 4 bits et ne peut donc contenir une information de charge qui peut prendre uniquement des valeurs allant de 0 à 15.
### 6.3.2 Les System Information Blocks (SIBs)

Nous avons également envisagé l'utilisation des SIBs comme une alternative de placement de notre facteur de charge. Nous avons déjà évoqué les SIBs et leur utilité à chacun dans le chapitre 2 de ce manuscrit.

Le SIB1 est le premier SIB décodé par l'UE. L'avantage d'utiliser ce SIB là est que l'information de charge serait rapidement décodée par l'UE, en même temps qu'il obtient les informations d'identités de la cellule et de l'opérateur. L'inconvénient de l'utilisation du SIB1 et des SIBs en général vient du fait que les SIBs véhiculent normalement des informations qui n'ont pas pour but de varier rapidement. D'après les informations extraites de la section 5.2 du TS 136 331[88] traitant des SIBs, lorsqu'une modification à lieu dans un SIB, un message de paging est envoyé à l'UE pour l'avertir qu'il y a une modification. De plus, nous avons montré plus tôt que le MIB est responsable de diffuser un booléen du nom de *systemInfoUnchanged* – *BR* – *r15*. Ce booléen certifie qu'il n'y a pas eu un changement dans le SIB1 au cours d'une durée passée, indiqué par le booléen *si – ValidityTime*, diffusé par le SIB1. Si ce booléen est fixé à l'état VRAI, cette durée est de 3h, s'il est fixé à FAUX, cette durée est de 24h.

Tous ces mécanismes montrent que les SIBs n'ont pas vocation à véhiculer des informations changeant rapidement. Changer trop fréquemment la valeur du facteur de charge dans un SIB entraînerait beaucoup trop d'envois de messages de paging aux UEs dans l'implémentation LTE.

En revanche, dans l'implémentation de la 5G, d'après la section 5.2 du document TS 138 331 [91], certains SIBs seraient uniquement partagés avec les UEs qui en font la demande, comme le montre la suite de messages échangés en 5G par la figure 6.3 extraite de ce document. Il serait alors possible d'utiliser un de ces SIBs ou d'en créer un dédié à cette tache sans avoir les contraintes évoquées précédemment.

<figure><img src="image_33.png" /><figcaption>FIGURE 6.3 – La requête de SIBs en 5G.</figcaption></figure>

Pour la suite de ce chapitre nous allons cependant faire le choix de propager notre information de charge au travers du MIB, à cause de sa facilité d'implémentation dans la suite logicielle srsRAN.

## 6.4 Architecture de srsRAN

D'après les informations extraites de la page web [71] le code source du projet représente environ 6500 éléments constitués d'un total d'environ 665 000 lignes de code. La composition des langages informatiques contenus dans ces lignes de code
peut être aperçue sur la page principale du projet et au travers de la capture d'écran
réalisé de celle-ci (figure 6.4).

<figure><img src="image_34.png" /><figcaption>FIGURE 6.4 – Languages informatiques utilisés dans le projet srs-RAN.</figcaption></figure>

L'architecture logicielle de srsRAN présentée dans la figure 6.5 est celle d'une
version antérieure à srsRAN, encore dénommé à l'époque srsLTE. Cette figure pré-
sente les principaux dossiers de l'arborescence ainsi que l'emplacement d'une partie
des fichiers clefs qui ont été modifiés par mes soins. Il est possible que l'architecture
du code courant de srsRAN à la lecture de ce manuscrit ait évolué.

On note ici 6 dossiers principaux qui sont listés si après :

1. **cmake** : ce dossier contient les fichiers propres à l'outil de compilation cmake ainsi que le Makefile responsable de définir les règles de compilation. Ces règles sont importantes car elles sont conçues de manière à ne recompiler que les derniers fichiers modifiés. Le temps de compilation de la solution complète peut alors se voir réduire de 10 minutes en cas de première compilation à seulement une poignée de secondes en cas de modification de quelques fichiers.

2. **debian**: ce dossier contient plusieurs scripts bash utiles notamment lors de l'installation de la solution, ou d'une partie seulement de srsRAN, pour le système linux.

3. **lib**: ce dossier contient le code source du projet qui est commun à au moins deux des trois entités srsEPC, srsENB et srsUE. Ce dossier est lui-même divisé en quatre sous dossiers :

- **examples**: contient du code de fonctions de srsRAN exécutables indépendemment de srsEPC, srsENB et srsUE.

- **include**: contient l'ensemble des fichiers d'en-tête pour les fonctions communes à srsEPC, srsENB et srsUE.

- **src**: contient le code source des fonctions communes à srsEPC, srsENB et srsUE.

- **test**: contient le code des tests unitaires vérifiant l'intégrité des fonctions du dossier "lib".

4. **srsepc**: ce dossier contient le code source de tous les éléments propres à l'exécutable srsEPC. Ce dossier est lui-même divisé en trois sous dossiers :

- **hdr**: contient l'ensemble des fichiers d'en-tête pour les fonctions de srsEPC.

- **src**: contient le code source des fonctions de srsEPC.

- **test**: contient le code des tests unitaires vérifiant l'intégrité des fonctions de srsEPC.

5. **srsenb**: Ce dossier contient le code source de tous les éléments propres à l'exécutable srsENB. Ce dossier est lui-même divisé en trois sous dossiers :

- **hdr**: contient l'ensemble des fichiers d'en-tête pour les fonctions de srsENB.

- **src**: contient le code source des fonctions de srsENB.
- **test**: contient le code des tests unitaires vérifiant l'intégrité des fonctions de srsENB.

6. **srsue**: ce dossier contient le code source de tous les éléments propres à l'exécutable srsUE. Ce dossier est lui-même divisé en trois sous dossiers :

- **hdr**: contient l'ensemble des fichiers d'en-tête pour les fonctions de srsUE.

- **src**: contient le code source des fonctions de srsUE.

- **test**: contient le code des tests unitaires vérifiant l'intégrité des fonctions de srsUE.

<figure><img src="image_35.png" /><figcaption>FIGURE 6.5 – Structuration du code source srsRAN 19.</figcaption></figure>

Nous rappelons encore une fois que l'ensemble du projet srsRAN est constitué d'environ 6500 fichiers de code source, d'en-têtes et autres. Il est donc impossible de rentrer plus en détail ici dans le contenu des sous dossiers déjà présentés sans y consacrer un nombre de pages trop important pour ce manuscrit. Notons toutefois qu'il s'agit d'un travail difficile que de comprendre le fonctionnement détaillé du projet srsRAN qui a représenté un bon nombre de semaines de travail durant ma thèse. Les principales difficultés de ce travail ont été premièrement de trouver, dans le code source, où sont définis les fonctions ou les ensembles de fonctions qui nous semblaient importantes à modifier. La deuxième difficulté consiste à réussir à modifier le code source de srsRAN et d'obtenir le résultat souhaité. La troisième difficulté, qui intervient au milieu de la seconde, est de trouver toutes les fonctions et fichiers qui utilisent les fonctions modifiées et s'assurer que ces modifications ne perturbent pas le fonctionnement attendu par ces fonctions. Cette troisième tâche est particulièrement difficile dans un projet de la taille de srsRAN qui contient environ 650 000 lignes de code.

## 6.5 Proposition d'une nouvelle sélection de cellules avec srsRAN

### 6.5.1 Sélection de cellule et classement des cellules voisines

Dans srsRAN, par défaut, le classement des cellules voisines est réalisé en suivant l'algorithme 1. Cet algorithme s'exécute à chaque fois qu'une nouvelle mesure de cellule est effectuée. Nous définissons *B* comme la nouvelle cellule pour laquelle
nous venons de réaliser une mesure et B.rsrp la valeur du RSRP mesuré. La liste des cellules déjà mesurées et triées est représentée par la variable *Liste*. Les cellules de cette liste, représentées à tour de rôle par la variable *A*, ont toutes leur valeur de RSRP (*A*.rsrp) comparée les unes après les autres à la valeur du RSRP de *B*.

Ce tri des cellules est simplifié par rapport à celui dicté par les documents de la 3GPP détaillés dans le chapitre 5. En effet il n'est utilisé ici que la valeur du RSRP directement mesurée pour la station. Il n'y a pas de d'offset mis en jeu ici, et ce pour la raison que les SIBs 4 et 5 ne sont pas implémentés. srsUE ne dispose pas de toutes les informations permettant de réaliser le tri tel que décrit par la 3GPP.

**Algorithmme 1** Classement des cellules voisines de srsRAN

**Entrée:** Liste, B

**Sortie:** Liste

1. **pour** A dans Liste **faire**

2. **si** A.rsrp < B.rsrp alors

3. Mettre B avant A dans Liste

4. **stop**

5. **fin si**

6. **fin pour**

Nous proposons donc un nouveau tri des cellules, basé sur le facteur de charge. Nous avons précédemment choisi le MIB comme support de diffusion de notre facteur de charge. Notre facteur de charge ne peut donc prendre que des valeurs allant de 0 à 15, à cause du nombre de bits restreint dans lequel nous pouvons placer notre information. L'objectif de la modification qui va suivre est de réaliser le tri non plus par rapport au RSRP mais par rapport au facteur de charge. Nous prenons la décision qu'une faible valeur de facteur de charge signifie que la cellule est peu chargée. À l'inverse un facteur de charge proche ou égale à 15 signifie que la cellule est saturée. Le tri se réalise donc comme détaillé dans l'algorithme 2, c'est-à-dire en classant en premier les cellules qui ont un facteur de charge plus faible que les autres.

**Algorithmme 2** Classement des cellules voisines en fonction du facteur de charge

**Entrée:** Liste, B

**Sortie:** Liste

1. **pour** A dans Liste **faire**

2. **si** A.facteurdecharge > B.facteurdecharge alors

3. Mettre B avant A dans Liste

4. **stop**

5. **fin si**

6. **fin pour**

Du point de vue du code source maintenant, les principales modifications sont affichées dans la figure 6.6 couleur bleu clair pour les ajouts et en rouge pour les suppressions. Pour plus de détails apportés à la modification de ce fichier et à l'ensemble du code source en général, vous pouvez trouver l'historique de toutes les modifications apportées dans le gitlab Inria du projet [92].

### 6.5.2 Utiliser le nombre de RNTIs comme facteur de charge

Plus tôt dans ce chapitre nous avons discuté de notre choix d'utiliser le nombre de RNTIs utilisateurs alloués par la station de base comme information de charge
<figure><img src="image_36.png" /><figcaption>FIGURE 6.6 – La procédure de tri dans le fichier "rrc_cell.cc" de srsRAN.</figcaption></figure>

à diffuser au travers de notre facteur de charge. Notre valeur de facteur de charge ne peut prendre que des valeurs allant de 0 à 15 dues à l'encodage de ce champ sur 4 bits. Nous ne pourrons ici représenter que la présence de 15 utilisateurs à l'état RRC connecté sur notre cellule avant de considérer que notre cellule est surchargée. Si cela n'est pas du tout un problème durant nos expérimentations puisque nous ne dépassons jamais 5 UEs connectés, c'est un problème dans un contexte réel puisque le nombre d'UEs peut atteindre plusieurs centaines. Il faudra alors envisager dans un cadre réel de définir une échelle de traduction pertinente entre les valeurs du facteur de charge et les valeurs de RNTI alloués, ce qui peut être le cadre de futurs travaux.

L'objectif des modifications suivantes est de faire varier dynamiquement le facteur de charge en fonction du nombre d'utilisateurs à l'état connecté RRC sur la cellule de srsRAN. Le résultat de ces modifications sera la mise en place de l'algorithme 3 dans la station de base. Cet algorithme devra être exécuté à chaque fois qu'un RNTI est ajouté ou enlevé à la liste *ListeRNTI* des RNTI alloués par la BS. La variable *facteurdecharge* défini le facteur de charge. La variable *n* est une variable tampon qui sert à compter le nombre d'UE utilisateurs dans la liste de RNTI alloués.

Du côté de l'implémentation dans srsRAN, les modifications apportées à l'eNB sont affichées dans la figure 6.7. Pour déterminer le nombre d'UEs connectés à la station, il suffit de regarder quel est le nombre de RNTIs actuellement utilisés par la cellule, et d'en extraire ceux qui correspondent réellement à des RNTIs d'utilisateurs, car tous les RNTIs ne servent pas à identifier les utilisateurs déjà RRC connectés. La fonction SRSLTE_RNTI_ISUSER, fourni par srsRAN, permet de déterminer si un RNTI est celui d'un utilisateur. L'algorithme 3 est mis en place dans les deux fonctions qui permettent d'ajouter ou de supprimer un RNTI de la liste. La valeur du facteur de charge varie donc dynamiquement en fonction de l'évolution du nombre d'UE présents.
**Algorithme 3** Calcul du facteur de charge en fonction du nombre d'UEs RRC connectés

**Entrée:** $n = 0$, facteurdecharge, ListeRNTI

**Sortie:** facteurdecharge

1. **pour** A dans ListeRNTI **faire**

2. **si** A == RNTIUtilisateur alors

3. $n = n + 1$

4. **fin si**

5. **fin pour**

6. **si** $n < 16$ alors

7. facteurdecharge = $n$

8. **sinon**

9. facteurdecharge = 15

10. **fin si**

<figure><img src="image_37.png" /><figcaption>FIGURE 6.7 – Modification de srsRAN pour propager l'information du nombre d'UEs à l'état RRC connecté.</figcaption></figure>
## 6.6 Modification du MIB de srsRAN

Cette section a pour but de détailler certaines modifications supplémentaires réalisées dans le code source de srsRAN pour obtenir une solution complète d'association et de sélection de cellule en fonction du facteur de charge.

Pour ajouter le facteur de charge aux messages diffusés par la station, il faut d'abord créer une variable qui va contenir cette information. Il y a au sein de srsRAN une structure qui défini les informations qui composent une cellule. Cette structure se nomme "srslte_cell_t". Elle est déclarée dans le fichier "phy_common.h" dont l'emplacement est affiché dans la figure 6.5. Nous rajoutons dans cette structure un champ qui mémorisera la valeur du facteur de charge.

Il faut ensuite réussir à introduire le facteur de charge dans le MIB qui sera diffusé par la station de base. Le MIB est un message présent dans le canal PBCH. Dans srsRAN, c'est dans le fichier "pbch.c" que se trouve le code responsable d'encoder le MIB du côté de l'eNB. La fonction responsable de la construction du MIB avant encodage est affichée dans la figure 6.8. Sur cette même figure apparaissent en couleur vert pâle les ajouts qui ont été réalisés à ce code source. Cette fonction de construction du MIB est appelée à chaque première sous-trame de chaque trame LTE.

<figure><img src="image_38.png" /><figcaption>FIGURE 6.8 – L'encodage du facteur de charge et du MIB dans le canal PBCH par l'eNB.</figcaption></figure>

Du côté de l'UE maintenant il faut être capable à décodeur le MIB et d'extraire de celui-ci les quatre bits sur lesquels est placée l'information du facteur de charge. Dans srsRAN, c'est dans le fichier "pbch.c" également que se trouve le code responsable de décodeur le MIB et de mettre à jour la structure qui contient les informations de la cellule. La fonction responsable de l'extraction est présentée dans la figure 6.9. Sur cette même figure apparaissent en couleur vert pâle les ajouts qui ont été réalisés à ce code source. Parmi les modifications apportées on remarquera que le résultat extrait du MIB est bien placé dans le champ "spare_value" de la structure d'information de la cellule observée.

Pour la modification de ce fichier et des deux fonctions présentées, la difficulté vient de la manipulation bit à bit du message à encoder ou décodeur. Un décalage d'un seul bit dans l'opération peut rendre le MIB complètement illisible et, au mieux, simplement donner une mauvaise valeur du facteur de charge. Il faut, pour ne pas se tromper, bien comprendre le fonctionnement des différentes fonctions d'encodage et
<figure><img src="image_39.png" /><figcaption>FIGURE 6.9 – Le décodage du facteur de charge et du MIB par l’UE.</figcaption></figure>

de décodage. Il faut également arriver à comprendre le format et l'emplacement des
bits à placer dans l'espace mémoire réservé au futur encodage/décodage du MIB.

6.7 Etude des limites de l'association avec facteur de charge

6.7.1 Les différentes sélections de cellules étudiées

Cette étude se présente ici comme une évaluation des performances de notre
proposition de sélection de cellule basée sur un facteur de charge diffusant le nombre
de RNTI utilisateurs alloués. Nous allons ici réaliser des simulations similaires à
celles effectuées au chapitre 5 que nous comparons avec les résultats de ce même
chapitre. Nous réutilisons les résultats de débits obtenus en fonction de diverses
configurations de station de base et en fonction du nombre d’utilisateurs concurrents
du chapitre 5. Nous rappelons ici les différents types de tri réalisés précédemment et
rajoutons plusieurs règles de tri impliquant maintenant le nombre de RNTI ou une
combinaison du RNTI et d’autres métriques. La liste suivante détaille les différentes
règles de tris utilisées :

RSRP

Les cellules sont classées par ordre de **RSRP** décroissant. On compte combien
de fois la première cellule est celle qui donne le meilleur débit parmi les cellules de
notre tirage.

PRBs -> RSRP

Les cellules sont classées par ordre décroissant de leur nombre de **PRBs**. En cas
d'égalité, elles sont départagées par ordre de **RSRP** décroissant. On compte combien
de fois la première cellule est celle qui donne le meilleur débit parmi les cellules de
notre tirage.
### PRBs (borne sup)

Les cellules sont classées par ordre décroissant de leur nombre de **PRBs**. En cas d'égalité en première position, on regarde si une de ces cellules à égalité fournit le meilleur débit. On obtient alors ainsi une **borne supérieure** du nombre de fois où l'on pourrait choisir la meilleure cellule en triant d'abord par nombre de PRBs décroissants.

### RNTI -> RSRP

Les cellules sont classées par ordre décroissant de **RNTI** utilisateurs présents dans la cellule. En cas d'égalité, elles sont départagées par ordre de **RSRP** décroissant. On compte combien de fois la première cellule est celle qui donne le meilleur débit parmi les cellules de notre tirage.

### RNTI (borne sup)

Les cellules sont classées par ordre décroissant de **RNTI** utilisateurs présents dans la cellule. En cas d'égalité en première position, on regarde si une de ces cellules à égalité fournit le meilleur débit. On obtient alors ainsi une **borne supérieure** du nombre de fois où l'on pourrait choisir la meilleure cellule en triant d'abord par le nombre décroissant de **RNTI** utilisateurs présents dans la cellule.

### PRBs -> RNTI -> RSRP

Les cellules sont classées par ordre décroissant de leur nombre de **PRBs**. En cas d'égalité, elles sont départagées par ordre décroissant de **RNTI** utilisateurs présents dans la cellule. S'il y a toujours une égalité, elles sont cette fois départagées par ordre de **RSRP** décroissant.

### RNTI -> PRBs -> RSRP

Les cellules sont classées par ordre décroissant de **RNTI** utilisateurs présents dans la cellule. En cas d'égalité, elles sont départagées par ordre décroissant de **PRBs**. S'il y a toujours une égalité, elles sont cette fois départagées par ordre de **RSRP** décroissant.

### 6.7.2 Le scénario des simulations et résultats

Nous réalisons dans cette section des simulations des trois types de tris proposés précédemment. Le scénario des simulations est le suivant :

Un UE réalise des mesures de RSRP et récupère l'information de facteur de charge de K cellules candidates voisines. La configuration $C_K$ de chaque cellule candidate est tirée aléatoirement sans remise parmi les N configurations issues de nos expérimentations précédentes. L'UE réalise un tri de ces K cellules en fonction de chacune des règles de tris énoncées plus tôt. Il existe $C_N^K$ combinaisons différentes possibles de cellules voisines. Nous simulons le tri réalisé par l'UE pour l'ensemble de ces $C_N^K$ combinaisons. Puis nous calculons le pourcentage de combinaisons pour lesquels le tri réalisé résulte en un classement en première position de la cellule qui fournit à l'UE le meilleur débit.
<table><caption>TABLE 6.1 – Pourcentage de réussite du tri des cellules par types de tris réalisés.</caption><thead><tr><th>K</th><th>2</th><th>3</th><th>4</th><th>5</th></tr></thead><tbody><tr><td>RSRP</td><td>67,42%</td><td>53,54%</td><td>46,00%</td><td>41,23%</td></tr><tr><td>PRBs -&gt; RSRP</td><td>75,03%</td><td>63,97%</td><td>57,21%</td><td>52,55%</td></tr><tr><td>PRBs (borne sup)</td><td>83,32%</td><td>74,98%</td><td>70,70%</td><td>68,45%</td></tr><tr><td>RNTI -&gt; RSRP</td><td>77,03%</td><td>67,80%</td><td>62,26%</td><td>58,38%</td></tr><tr><td>RNTI (borne sup)</td><td>81,43%</td><td>73,34%</td><td>68,88%</td><td>66,05%</td></tr><tr><td>PRBs -&gt; RNTI -&gt; RSRP</td><td>80,55%</td><td>71,51%</td><td>66,44%</td><td>63,33%</td></tr><tr><td>RNTI -&gt; PRBs -&gt; RSRP</td><td>79,65%</td><td>70,93%</td><td>65,87%</td><td>62,49%</td></tr></tbody></table>

Nous disposons de 28 configurations possibles de paramètres de cellules qui sont listées dans le tableau 5.3. Puisque nous utilisons le jeu de données obtenu au chapitre précédent, nous disposons de résultats d'une cellule qui applique ces 28 combinaisons de paramètres pour un nombre d'UE connectés et actifs allant de 1 jusqu'à 5. Nous disposons donc de résultats pour un ensemble de configurations de cellules N égal à 140.

Les résultats obtenus pour chaque règle de tri utilisée sont affichés dans le tableau 6.1. La toute première observation que l'on peut faire de ces résultats est que la règle de tri basée sur le RSRP mesuré nous apporte les moins bons résultats.

### 6.7.3 Le tri par RNTI

<figure><img src="image_40.png" /><figcaption>FIGURE 6.10 – Taux de meilleure sélection des tris commençant par trier les cellules par RNTIs.</figcaption></figure>

Sur la figure 6.10, nous comparons ici les résultats du tri RSRP avec les différents tris RNTI. On observe ici, au même titre qu'au chapitre précédent, que le tri RNTI -> RSRP conduit à de meilleurs résultats que le tri RSRP. On remarque que le tri RNTI
(borne sup) nous indique qu'il reste une marge de progression à ce qu'il peut être obtenu avec un tri qui commence par le RNTI. C'est pourquoi nous avons également simulé un tri RNTI -> PRBs -> RSRP. Puisque les tris basés sur les PRBs améliorent le taux de meilleure sélection par rapport au tri RSRP, nous vérifions si le tri RNTI -> PRBs -> RSRP améliore le taux de meilleure sélection par rapport au tri RNTI -> RSRP. Et c'est effectivement le cas.

### 6.7.4 Le tri par PRBs

<figure><img src="image_41.png" /><figcaption>FIGURE 6.11 – Taux de meilleure sélection des tris commençant par trier les cellules par PRBs.</figcaption></figure>

Sur la figure 6.11 on compare toutes les règles de tri qui commencent par faire le tri en fonction de la bande passante de la cellule par rapport au tri basé sur le RSRP. Comme indiqué au chapitre précédent, le tri PRBs -> RSRP fournit un taux de sélection de meilleure cellule plus élevé que le tri RSRP. D'un autre côté, le résultat du tri PRBs (borne sup) nous montre que l'on peut encore améliorer le tri PRBs -> RSRP. Étant donné que la figure 6.10 nous montre que le tri RNTI -> RSRP améliore lui aussi le taux de meilleure sélection, le choix a été fait d'essayer une nouvelle règle de tri PRBs -> RNTI -> RSRP pour essayer de se rapprocher de PRBs (borne sup). Et cela est également un résultat concluant.

### 6.7.5 Les tris avec mélange de métriques

Dans la figure 6.12 nous comparons maintenant les tris PRBs -> RNTI -> RSRP et RNTI -> PRBs -> RSRP avec le tri RSRP. Le tri commençant par classer les PRBs puis les RNTIs fonctionne un peu mieux que le tri commençant par classer les RNTIs puis les PRBs. Les deux résultats sont proches mais la fusion des deux métriques PRBs et RNTIs les rapprochent tous deux de leurs bornes supérieures.
<figure><img src="image_42.png" /><figcaption>FIGURE 6.12 – Comparaison du taux de meilleure sélection des tris PRBs -> RNTI -> RSRP et RNTI -> PRBs -> RSRP).</figcaption></figure>

6.7.6 Distribution des débits

Nous avons également quelques résultats préliminaires qui consistent à quantifier quel est le gain réel en débit obtenu suite à la réalisation de nos propositions de tris comparés au tri réalisé par l'association meilleur SINR.

<figure><img src="image_43.png" /><figcaption>FIGURE 6.13 – Résultats préliminaire du gain en débit obtenu par notre proposition de tri comparé au tri RSRP.</figcaption></figure>

La figure 6.13 montre une distribution de la différence de débit obtenu entre notre proposition de tri et le tri actuel meilleur RSRP. Les résultats montrent que dans 75,1% des cas notre sélection de cellule choisit une cellule qui donne au moins le même débit qu'une cellule choisit par la sélection de cellule meilleur RSRP actuelle. Notre sélection de cellule résulte en un débit strictement supérieur à celui de la sélection meilleur RSRP dans 47,6% des cas.
Nous avons proposé des nouvelles solutions de tri des cellules candidates, basées sur la bande passante des cellules et sur le nombre d'UEs déjà associés. Nos simulations montrent que ces stratégies de tri choisissent la meilleure cellule candidate environ 20% plus souvent que la stratégie meilleur SINR actuellement utilisé dans les réseaux cellulaires.

Ces résultats démontrent qu'il existe des métriques bien plus pertinentes pour la sélection de cellule que le RSRP lorsque l'on recherche des performances de débit de la part d'une cellule. Nous constatons que l'information de charge transmise au travers du nombre de RNTI en fait partie et qu'il n'est pas si difficile de rajouter ce mécanisme au fonctionnement actuel des équipements LTE. Nous constatons également qu'une métrique déjà en place, très rapidement accessible et entièrement gratuite, qui est la bande passante de la cellule, permet de réaliser plus souvent une meilleure sélection de cellule lorsque l'utilisateur et ses applications ont des besoins de performances importants.

## 6.8 Conclusion

Dans ce chapitre nous avons proposé plusieurs métriques candidates pour être l'information de charge que nous souhaitons voir être diffusée par la station de base. Parmi ces candidats se trouvent les PRBs et REs utilisés à chaque sous-trame, le nombre de RNTI utilisateur alloués et le décodage de tous les DCIs. Nous avons discuté de pourquoi nous pensons que le nombre de RNTI utilisateurs est le meilleur choix pour une première approche, ainsi que pour être implémenté dans srsRAN.

Nous avons discuté également du meilleur emplacement où mettre notre facteur de charge pour être diffusé. Nous avons discuté du MIB et des SIBs pour conclure que le MIB nous fournit le cadre le plus simple d'utilisation ainsi qu'une facilité d'implémentation dans srsRAN ou même dans le standard LTE actuel.

Suite à cela nous avons proposé une nouvelle façon de trier les cellules candidates voisines des UEs en réalisant un tri basé sur ce nouveau facteur de charge. Nous avons montré qu'il est tout à fait réalisable d'implémenter cette solution dans le standard LTE actuel en montrant l'exemple d'une modification du code source de srsRAN, une suite logicielle émulant un réseau cellulaire LTE complet.

Nous avons montré ensuite par simulation que la sélection de cellule résultant de notre nouveau tri apporte une augmentation du taux de sélection de la meilleure des cellules candidates jusqu'à 22% de plus par rapport à la stratégie meilleur SINR actuellement utilisé dans les réseaux cellulaires. Nous avons également montré que l'on peut réaliser d'autres types de tri lors de la sélection de cellule et qu'ils fournissent tous de meilleures performances que l'association meilleur SINR.
# Chapitre 7

# Conclusion et perspectives

## 7.1 Résumé

Après avoir regardé de plus près les mécanismes liés à l'association, nous constatons que les stations de bases ne diffusent aucune information de capacité restante aux UEs, ni au travers du MIB, ni au travers des SIBs. L'UE réalise son association avec la cellule fournissant le meilleur RSRP, qui constitue une métrique agnostique de la capacité réelle qu'est capable de lui attribuer la BS et agnostique du besoin applicatif de l'abonné. L'évolution des réseaux cellulaires tend vers plus de mobilité du côté des UEs mais également du côté des BSs. Les problématiques ont évolué avec le développement des réseaux cellulaires. Nous pensons que dès l'association l'UE pourrait réaliser un choix de sélection de cellule qui correspondrait au mieux à ses besoins, aussi bien en termes de débit que de mobilité ou de latence. Si l'UE et la BS se partageaient plus d'informations avant la procédure d'association certains de ces problèmes pourrait être évités.

Dans cette thèse, nous mettons en place une plateforme expérimentale basée sur l'utilisation de la suite logicielle srsRAN et de radios logicielles USRP NI-2091. Cette plateforme expérimentale a pour but de réaliser des mesures de performance d'un réseau cellulaire LTE entier. Son déploiement est automatisé et les mesures de débits réalisées sont automatisées.

Dans cette thèse nous nous concentrons sur l'étude du gain de débit sur le lien descendant que peut obtenir l'UE en fonction du type de sélection de cellule qu'il réalise. Nous réalisons des expérimentations grâce à une plateforme srsRAN mise en place dans le cadre de la thèse. Nous montrons qu'en fonction des diverses configurations de stations de base et qu'en fonction du nombre d'UEs utilisant déjà les services de ces stations le débit obtenu par notre propre équipement varie. Nous montrons aussi que l'association meilleur SINR utilisée actuellement dans le standard a atteint ses limites, qu'elle est agnostique des configurations des stations et qu'elle ne permet pas de maîtriser le débit qu'obtiendra l'UE suite à l'association.

Nous proposons dans cette thèse une nouvelle manière de réaliser l'association et plus particulièrement une nouvelle métrique à utiliser lors de la sélection de cellule réalisée par l'UE. Cette métrique dénommée le *facteur de charge* est une information de charge qui sera dans notre cas représentée par le nombre d'UEs présents à l'état RRC connecté dans chacune des cellules. Nous discutons des autres métriques utilisables comme information de charge ainsi que du meilleur emplacement à utiliser parmi les canaux de diffusion pour propager notre information. Nous montrons de manière expérimentale, en modifiant nous-même le code source de la suite logicielle srsRAN, que si la BS était capable de diffuser le *facteur de charge* au travers de son MIB, l'UE pourrait augmenter son taux de sélection de la meilleure station disponible de 22% de plus qu'en réalisant une association meilleur SINR actuellement utilisée dans les réseaux cellulaires.
## 7.2 Perspectives

Suite aux discussions menées dans ce manuscrit et suite à nos propositions, de nombreuses questions restent ouvertes et sont à étudier dans des travaux futurs.

### 7.2.1 Évaluation de performances

Premièrement, une perspective à ces travaux serait d'implémenter les propositions de partage d'information déjà proposées par la littérature mais qui sont resté à l'état de théorie ou à celui de simulation. La littérature manque de travaux expérimentaux et d'implémentation des propositions dans un cadre réel d'utilisation des réseaux cellulaires.

D'une manière plus globale une perspective à ces travaux serait d'étudier les différents types d'associations présentés au chapitre 2 et non développés dans ce manuscrit. L'association orientée mobilité doit être étudiée pour répondre à des problèmes de mobilités des BSs déjà existants dans les réseaux auto-déployables mais également dans certaines propositions de stations de bases 5G dans la littérature ou certaines propositions par exemple de stations de bases satellites déjà pressenties pour le déploiement d'une future 6G.

### 7.2.2 Étude des métriques et du placement du facteur de charge

Deuxièmement, nous avons discuté de la nécessité pour la BS de partager une information de charge avec les UEs. Et nous avons discuté de quelle était une bonne information de charge à diffuser. Nous avons évoqué l'utilisation des blocs de ressources non utilisés par la station de base comme d'une métrique possible pour le *facteur de charge*. Nous pensons cette piste prometteuse à condition de réaliser un traitement sur cette valeur. Une perspective à ces travaux est d'étudier comment rendre cette information de PRBs restants exploitable étant donné que ce nombre varie trop vite et trop fortement pour être utilisé en l'état. Nous pensons qu'il faudrait probablement réaliser une moyenne glissante de cette valeur et probablement la coupler avec le nombre d'utilisateurs à l'état connecté RRC, puisque nous avons déjà prouvé son efficacité dans ce manuscrit. De la même manière nous avons, dans nos expérimentations, utilisé le MIB comme transport pour notre *facteur de charge* en grande partie à cause de sa facilité de modification. Nous pourrions également étudier dans de prochains travaux l'impact du placement du *facteur de charge* dans le MIB, dans un SIB déjà existant ou dans un tout nouveau SIB. Le principal impact à étudier par ce changement est la fréquence de mise à jour de l'information et donc le délai auquel sera soumis l'UE avant l'obtention de cette information [88]. Nous pouvons également étudier l'impact du placement du facteur de charge dans un SIB pour la technologie 5G, puisque certains SIBs ne sont diffusés que si les UEs en font la demande [88].

### 7.2.3 L'association vers une hétérogénéité des réseaux

Troisièmement, nous n'avons dans ce manuscrit traité que d'une infime partie des problématiques induites de ce que nous avons défini comme l'évolution des réseaux. Nous tendons vers une hétérogénéité des réseaux et seules les variations de puissance, de bande passante et du nombre d'utilisateur ont été prises en compte dans nos expérimentations. Une perspective à ces travaux pourrait être d'étudier,
toujours expérimentalement grâce à notre plateforme srsRAN déjà déployée, l'impact du lien backhaul limité entre les stations de bases dans le cadre de réseaux auto-déployables [19] ou hétérogènes [66]. Nous pensons à étudier dans un premier temps l'impact de la capacité du lien backhaul sur les performances obtenus par l'UE pour ensuite définir une information de charge du lien backhaul à faire diffuser par la BS de la même façon que notre facteur de charge. Nous étudierons ensuite l'impact de la réalisation d'une sélection des cellules basée sur cette information de charge sur le débit obtenu par l'UE suite à son association.

Une autre perspective à ces travaux pourrait être de traiter des divers autres types d'hétérogénéité dans les réseaux cellulaires. L'évolution des réseaux mène déjà aujourd'hui à la coexistence de plusieurs types de technologies. Par défaut si un utilisateur a un forfait 5G il sera prioritairement associé à une cellule 5G. Mais une question reste ouverte, l'utilisateur a-t-il forcément besoin d'être associé à une cellule 5G pour la totalité de ces applications ? Une cellule d'une autre technologie ne serait-elle pas capable d'apporter plus de ressource qu'une cellule 5G surchargé ? Nous pensons qu'une approche similaire aux travaux de ce manuscrit pourraient être mené pour étudier l'impact de l'hétérogénéité des technologies.
# Annexe A

## Résultats des mesures du chapitre 5

<figure><img src="image_44.png" /><figcaption>FIGURE A.1 – Débit moyen mesuré pour 1 UE.</figcaption></figure>
<figure><img src="image_45.png" /><figcaption>FIGURE A.2 – RSRP moyen mesuré pour 1 UE.</figcaption></figure>

<figure><img src="image_46.png" /><figcaption>FIGURE A.3 – SNR moyen mesuré pour 1 UE.</figcaption></figure>
<figure><img src="image_47.png" /><figcaption>FIGURE A.4 – MCS moyen mesuré pour 1 UE.</figcaption></figure>

<figure><img src="image_48.png" /><figcaption>FIGURE A.5 – Débit moyen mesuré pour 2 UEs.</figcaption></figure>
<figure><img src="image_49.png" /><figcaption>FIGURE A.6 – RSRP moyen mesuré pour 2 UEs.</figcaption></figure>

<figure><img src="image_50.png" /><figcaption>FIGURE A.7 – SNR moyen mesuré pour 2 UEs.</figcaption></figure>
<figure><img src="image_51.png" /><figcaption>FIGURE A.8 – MCS moyen mesuré pour 2 UEs.</figcaption></figure>

<figure><img src="image_52.png" /><figcaption>FIGURE A.9 – Débit moyen mesuré pour 3 UEs.</figcaption></figure>
<figure><img src="image_53.png" /><figcaption>FIGURE A.10 – RSRP moyen mesuré pour 3 UEs.</figcaption></figure>

<figure><img src="image_54.png" /><figcaption>FIGURE A.11 – SNR moyen mesuré pour 3 UEs.</figcaption></figure>
<figure><img src="image_55.png" /><figcaption>FIGURE A.12 – MCS moyen mesuré pour 3 UEs.</figcaption></figure>

<figure><img src="image_56.png" /><figcaption>FIGURE A.13 – Débit moyen mesuré pour 4 UEs.</figcaption></figure>
<figure><img src="image_57.png" /><figcaption>FIGURE A.14 – RSRP moyen mesuré pour 4 UEs.</figcaption></figure>

<figure><img src="image_58.png" /><figcaption>FIGURE A.15 – SNR moyen mesuré pour 4 UEs.</figcaption></figure>
<figure><img src="image_59.png" /><figcaption>FIGURE A.16 – MCS moyen mesuré pour 4 UEs.</figcaption></figure>

<figure><img src="image_60.png" /><figcaption>FIGURE A.17 – Débit moyen mesuré pour 5 UEs.</figcaption></figure>
<figure><img src="image_61.png" /><figcaption>FIGURE A.18 – RSRP moyen mesuré pour 5 UEs.</figcaption></figure>

<figure><img src="image_62.png" /><figcaption>FIGURE A.19 – SNR moyen mesuré pour 5 UEs.</figcaption></figure>
<figure><img src="image_63.png" /><figcaption>FIGURE A.20 – MCS moyen mesuré pour 5 UEs.</figcaption></figure>
Bibliographie

[1] M. SAUTER. *From GSM to LTE-Advanced: An introduction to Mobile Networks and Mobile Broadband*. John Wiley & Sons, 2014.

[2] ARCEP, *Observatoire des déploiements 5G*. URL: https://www.arcep.fr/cartes-et-donnees/nos-cartes/5g/derniers-chiffres.html (visité le 30/04/2022).

[3] W. JIANG et al. « The Road Towards 6G : A Comprehensive Survey ». In : *IEEE Open Journal of the Communications Society* 2 (2021), p. 334-366. DOI : 10.1109/OJCOMS.2021.3057679.

[4] *Carte de couverture mobile*. URL: https://www.ariase.com/mobile/carte-couverture-mobile (visité le 30/04/2022).

[5] F. MOHAMMADNIA et al. « Mobile Small Cells for Adaptive RAN Densification : Preliminary Throughput Results ». In : *2019 IEEE Wireless Communications and Networking Conference (WCNC)*. 2019, p. 1-7. DOI : 10.1109/WCNC.2019.8885444.

[6] H. SHINBO et al. « Flying Base station for Temporary Mobile Communications in an Area Affected by a Disaster ». In : *2018 5th International Conference on Information and Communication Technologies for Disaster Management (ICT-DM)*. Déc. 2018, p. 1-7. DOI : 10.1109/ICT-DM.2018.8636379.

[7] D. RAUTU, R. DHAOU et E. CHAPUT. « Maintaining a permanent connectivity between nodes of an air-to-ground communication network ». In : *2017 13th International Wireless Communications and Mobile Computing Conference (IWCMC)*. 2017, p. 681-686. DOI : 10.1109/IWCMC.2017.7986367.

[8] M. MORADI et al. « SkyCore : Moving Core to the Edge for Untethered and Reliable UAV-Based LTE Networks ». In : *Proceedings of the 24th Annual International Conference on Mobile Computing and Networking*. MobiCom '18. New Delhi, India : Association for Computing Machinery, 2018, p. 35-49. ISBN : 9781450359030. DOI : 10.1145/3241539.3241549. URL : https://doi.org/10.1145/3241539.3241549.

[9] A. CHAKRABORTY et al. « SkyRAN : A Self-Organizing LTE RAN in the Sky ». In : *Proceedings of the 14th International Conference on Emerging Networking Experiments and Technologies*. CoNEXT '18. Heraklion, Greece : Association for Computing Machinery, 2018, p. 280-292. ISBN : 9781450360807. DOI : 10.1145/3281411.3281437. URL : https://doi.org/10.1145/3281411.3281437.

[10] J. OUEIS, R. STANICA et F. VALOIS. « Virtualized Local Core Network Functions Placement in Mobile Networks ». In : *2019 IEEE Wireless Communications and Networking Conference (WCNC)*. 2019, p. 1-6. DOI : 10.1109/WCNC.2019.8886062.

[11] Y. ÖZCAN et al. « Robust Planning and Operation of Multi-Cell Homogeneous and Heterogeneous Networks ». In : *IEEE Transactions on Network and Service Management* 17.3 (2020), p. 1805-1821. DOI : 10.1109/TNSM.2020.3001691.
[12] L. NAGPAL et K. SAMDANI. « Project Loon : Innovating the connectivity world-wide ». In : 2017 2nd IEEE International Conference on Recent Trends in Electronics, Information Communication Technology (RTEICT). 2017, p. 1778-1784. DOI : 10.1109/RTEICT.2017.8256905.

[13] J. FOUST. « SpaceX's space-Internet woes: Despite technical glitches, the company plans to launch the first of nearly 12,000 satellites in 2019 ». In : *IEEE Spectrum* 56.1 (2019), p. 50-51. DOI : 10.1109/MSPEC.2019.8594798.

[14] 3GPP. *Digital cellular telecommunications system (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); LTE; Network architecture*. Technical Specification (TS) 123.002. 3rd Generation Partnership Project (3GPP), 2020.

[15] 3GPP. *Evolved Universal Terrestrial Radio Access (E-UTRA); Requirements for support of radio resource management*. Technical Specification (TS) 36.133. 3rd Generation Partnership Project (3GPP), 2021.

[16] 3GPP. *Non Access Stratum (NAS) protocol for Evolved Packet System (EPS)*. Technical Specification (TS) 24.301. 3rd Generation Partnership Project (3GPP), 2021.

[17] 3GPP. *Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) procedures in idle mode*. Technical Specification (TS) 36.304. 3rd Generation Partnership Project (3GPP), 2021.

[18] *TMobile Country Codes (MCC) and Mobile Network Codes (MNC)*. URL : https://www.mcc-mnc.com/ (visité le 30/04/2022).

[19] J. OUEIS et al. « Network-Aware User Association in Public Safety Oriented Mobile Networks ». In : *Proceedings of the First CoNEXT Workshop on ICT Tools for Emergency Networks and DisastEr Relief*. I-TENDER '17. Incheon, Korea : Association for Computing Machinery, 2017, p. 31-36. ISBN : 9781450354240. DOI : 10.1145/3152896.3152903. URL : https://doi.org/10.1145/3152896.3152903.

[20] R. PUJOL, R. STANICA et F. VALOIS. « LTE User Association for Self-Deployable Networks in Disaster Management Scenarios ». In : *ICT-DM 2019 - 6th International Conference on Information and Communication Technologies for Disaster Management*. Paris, France, déc. 2019. URL : https://hal.archives-ouvertes.fr/hal-02327011.

[21] J. OUEIS. « Radio Access and Core Functionalities in Self-deployable Mobile Networks ». Theses. Université de Lyon - INSA Lyon, nov. 2018. URL : https://hal.inria.fr/tel-01950198.

[22] J. OUEIS et al. « Overview of LTE Isolated E-UTRAN Operation for Public Safety ». In : *IEEE Communications Standards Magazine* 1.2 (2017), p. 98-105. DOI : 10.1109/MCOMSTD.2017.1600875.

[23] X. CHEN, D. GUO et J. GROSSPIETSCH. « The public safety broadband network : A novel architecture with mobile base stations ». In : *2013 IEEE International Conference on Communications (ICC)*. 2013, p. 3328-3332. DOI : 10.1109/ICC.2013.6655060.

[24] Z. XIAO, P. XIA et X. XIA. « Enabling UAV cellular with millimeter-wave communication : potentials and approaches ». In : *IEEE Communications Magazine* 54.5 (2016), p. 66-73. DOI : 10.1109/MCOM.2016.7470937.
[25] P. RAWAT, M. HADDAD et E. ALTMAN. « Towards efficient disaster management : 5G and Device to Device communication ». In : 2015 2nd International Conference on Information and Communication Technologies for Disaster Management (ICT-DM). Nov. 2015, p. 79-87. DOI : 10.1109/ICT-DM.2015.7402056.

[26] I. GOJMERAC et al. « Public warning and alert system for Austria ». In : 2016 3rd International Conference on Information and Communication Technologies for Disaster Management (ICT-DM). Déc. 2016, p. 1-7. DOI : 10.1109/ICT-DM.2016.7857206.

[27] M. TERZI et al. « SWIFTERS : A Multi-UAV Platform for Disaster Management ». In : 2019 International Conference on Information and Communication Technologies for Disaster Management (ICT-DM). 2019, p. 1-7. DOI : 10.1109/ICT-DM47966.2019.9032923.

[28] Y. BUSNEL, C. CAILLOUET et D. COUDERT. « Self-Organized Disaster Management System by Distributed Deployment of Connected UAVs ». In : 2019 International Conference on Information and Communication Technologies for Disaster Management (ICT-DM). 2019, p. 1-8. DOI : 10.1109/ICT-DM47966.2019.9032964.

[29] M. HERLICH et S. YAMADA. « Motivation for a step-by-step guide to set up wireless disaster recovery networks ». In : 2015 2nd International Conference on Information and Communication Technologies for Disaster Management (ICT-DM). Nov. 2015, p. 64-70. DOI : 10.1109/ICT-DM.2015.7402025.

[30] E. NATALIZIO. « Mobility as a primitive to improve communications in wireless networks ». Habilitation à diriger des recherches ou HDR. UTC Compiegne, 2017.

[31] D. RAUTU, R. DHAOU et E. CHAPUT. « Crowd-based positioning of UAVs as access points ». In : 2018 15th IEEE Annual Consumer Communications Networking Conference (CCNC). 2018, p. 1-6. DOI : 10.1109/CCNC.2018.8319279.

[32] J. QIN et al. « Edge-Prior Placement Algorithm for UAV-Mounted Base Stations ». In : IEEE Wireless Communications and Networking Conference (WCNC). 2019, p. 1-6. DOI : 10.1109/WCNC.2019.8885992.

[33] H. ABEYWICKRAMA et al. « An Adaptive UAV Network for Increased User Coverage and Spectral Efficiency ». In : 2019 IEEE Wireless Communications and Networking Conference (WCNC). 2019, p. 1-6. DOI : 10.1109/WCNC.2019.8885892.

[34] R. LI et al. « Learning Driven Mobility Control of Airborne Base Stations in Emergency Networks ». In : SIGMETRICS Perform. Eval. Rev. 46.3 (jan. 2019), p. 163-166. ISSN : 0163-5999. DOI : 10.1145/3308897.3308964. URL : https://doi.org/10.1145/3308897.3308964.

[35] A. APOSTOLARAS et al. « Evolved user equipment for collaborative wireless backhauling in next generation cellular networks ». In : 2015 12th Annual IEEE International Conference on Sensing, Communication, and Networking (SECON). 2015, p. 408-416. DOI : 10.1109/SAHCN.2015.7338341.

[36] R. FAVRAUD et N. NIKAEIN. « Wireless mesh backhauling for LTE/LTE-A networks ». In : MILCOM 2015 - 2015 IEEE Military Communications Conference. 2015, p. 695-700. DOI : 10.1109/MILCOM.2015.7357525.

[37] OpenAirInterface. URL : https://openairinterface.org/ (visité le 30/04/2022).
[38] E. KALANTARI et al. « Backhaul-aware robust 3D drone placement in 5G+ wi- reless networks ». In : 2017 IEEE International Conference on Communications Workshops (ICC Workshops) . 2017, p. 109-114. DOI : 10 . 1109 / ICCW . 2017 . 7962642.

[39] Z. YANG et al. « Peer discovery for device-to-device (D2D) communication in LTE-A networks ». In : 2013 IEEE Globecom Workshops (GC Wkshps) . 2013, p. 665-670. DOI : 10 . 1109 / GLOCOMW . 2013 . 6825064.

[40] Z. LIN et al. « Analysis of discovery and access procedure for D2D commu- nication in 5G cellular network ». In : 2016 IEEE Wireless Communications and Networking Conference . 2016, p. 1-6. DOI : 10 . 1109 / WCNC . 2016 . 7564761.

[41] D. LIU et al. « User Association in 5G Networks : A Survey and an Outlook ». In : IEEE Communications Surveys Tutorials 18.2 (2016), p. 1018-1044. DOI : 10 . 1109 / COMST . 2016 . 2516538.

[42] T. ZHOU, Y. HUANG et L. YANG. « User association with jointly maximising downlink sum rate and minimising uplink sum power for heterogeneous cel- lular networks ». In : IET Communications 9.2 (2015), p. 300-308. ISSN : 1751- 8628. DOI : 10 . 1049 / iet-com . 2014 . 0476.

[43] J. KWAK, L. B. LE et X. WANG. « Two Time-Scale Content Caching and User As- sociation in 5G Heterogeneous Networks ». In : GLOBECOM 2017 - 2017 IEEE Global Communications Conference . Déc. 2017, p. 1-6. DOI : 10 . 1109 / GLOCOM . 2017 . 8254686.

[44] Y. WANG et al. « Joint Caching Placement and User Association for Minimizing User Download Delay ». In : IEEE Access 4 (2016), p. 8625-8633. ISSN : 2169- 3536. DOI : 10 . 1109 / ACCESS . 2016 . 2633488.

[45] F. PANTISANO et al. « Proactive user association in wireless small cell networks via collaborative filtering ». In : 2013 Asilomar Conference on Signals, Systems and Computers . Nov. 2013, p. 1601-1605. DOI : 10 . 1109 / ACSSC . 2013 . 6810568.

[46] M. FENG, S. MAO et T. JIANG. « Joint Frame Design, Resource Allocation and User Association for Massive MIMO Heterogeneous Networks With Wireless Backhaul ». In : IEEE Transactions on Wireless Communications 17.3 (mar. 2018), p. 1937-1950. ISSN : 1536-1276. DOI : 10 . 1109 / TWC . 2017 . 2787139.

[47] J. WILDMAN et al. « Delay minimizing user association in cellular networks via hierarchically well-separated trees ». In : 2015 IEEE International Conference on Communications (ICC) . Juin 2015, p. 4005-4011. DOI : 10 . 1109 / ICC . 2015 . 7248950.

[48] A. ZAPPONE, L. SANGUINETTI et M. DEBBAH. « User Association and Load Balancing for Massive MIMO through Deep Learning ». In : 2018 52nd Asi- lomar Conference on Signals, Systems, and Computers . 2018, p. 1262-1266. DOI : 10 . 1109 / ACSSC . 2018 . 8645483.

[49] K. DUFKOVÁ et al. « Predicting User-cell Association in Cellular Networks from Tracked Data ». In : Proceedings of the 2Nd International Conference on Mo- bile Entity Localization and Tracking in GPS-less Environments . MELT’09. Orlando, FL, USA : Springer-Verlag, 2009, p. 19-33. URL : http://dl.acm.org/citation. cfm?id=1813141.1813144.

[50] A. ALNOMAN, L. FERDOUSE et A. ANPALAGAN. « Fuzzy-Based Joint User As- sociation and Resource Allocation in HetNets ». In : 2017 IEEE 86th Vehicular Technology Conference (VTC-Fall) . Sept. 2017, p. 1-5. DOI : 10 . 1109 / VTCFall . 2017 . 8288227.
[51] J. YANG et al. « A Machine Learning Approach to User Association in Enterprise Small Cell Networks ». In : 2018 IEEE/CIC International Conference on Communications in China (ICCC). Août 2018, p. 850-854. DOI : 10.1109/ICCChina. 2018.8641148.

[52] M. KAFI, A. MOURADIAN et V. VÈQUE. « On-line Client Association Scheme Based on Reinforcement Learning for WLAN Networks ». In : 2019 IEEE Wireless Communications and Networking Conference (WCNC). 2019, p. 1-7. DOI : 10.1109/WCNC.2019.8886065.

[53] P. TRAKAS et al. « A quality of experience-aware association algorithm for 5G heterogeneous networks ». In : 2017 IEEE International Conference on Communications (ICC). Mai 2017, p. 1-6. DOI : 10.1109/ICC.2017.7996869.

[54] S. CORROY et R. MATHAR. « Semidefinite relaxation and randomization for dynamic cell association in heterogeneous networks ». In : 2012 IEEE Global Communications Conference (GLOBECOM). Déc. 2012, p. 2373-2378. DOI : 10.1109/GLOCOM.2012.6503471.

[55] L. TANG et al. « An Energy-Saving Algorithm With Joint User Association, Clustering, and On/Off Strategies in Dense Heterogeneous Networks ». In : IEEE Access 5 (2017), p. 12988-13000. ISSN : 2169-3536. DOI : 10.1109/ACCESS. 2017.2723680.

[56] N. SAPOUNTZIS et al. « User Association in HetNets : Impact of Traffic Differentiation and Backhaul Limitations ». In : IEEE/ACM Trans. Netw. 25.6 (déc. 2017), p. 3396-3410. ISSN : 1063-6692. DOI : 10.1109/TNET.2017.2746011. URL : https://doi.org/10.1109/TNET.2017.2746011.

[57] S. HE et al. « Distributed Cache Placement and User Association in Multicast-Aided Heterogeneous Networks ». In : IEEE Access 5 (2017), p. 25365-25376. ISSN : 2169-3536. DOI : 10.1109/ACCESS.2017.2769664.

[58] Y. CHEN et al. « User Association With Unequal User Priorities in Heterogeneous Cellular Networks ». In : IEEE Transactions on Vehicular Technology 65.9 (sept. 2016), p. 7374-7388. ISSN : 0018-9545. DOI : 10.1109/TVT.2015.2488039.

[59] Z. YANG et al. « Association and Load Optimization With User Priorities in Load-Coupled Heterogeneous Networks ». In : IEEE Transactions on Wireless Communications 17.1 (jan. 2018), p. 324-338. ISSN : 1536-1276. DOI : 10.1109/TWC.2017.2765322.

[60] M. ZALGHOUT et al. « Context-aware and priority-based user association and resource allocation in heterogeneous wireless networks ». In : Computer Networks 149 (2019), p. 76-92. ISSN : 1389-1286. DOI : https://doi.org/10.1016/j.comnet.2018.11.001. URL : http://www.sciencedirect.com/science/article/pii/S1389128618311812.

[61] S. KUMAR et S. MISRA. « Procurement-Based User Association for LTE-A Het-Nets ». In : IEEE Systems Journal (2019), p. 1-8. ISSN : 2373-7816. DOI : 10.1109/JSYST.2019.2937049.

[62] M. FENG et al. « Cooperative small cell networks : high capacity for hotspots with interference mitigation ». In : IEEE Wireless Communications 21.6 (déc. 2014), p. 108-116. ISSN : 1536-1284. DOI : 10.1109/MWC.2014.7000978.

[63] Y. SUN et al. « Cell Association With User Behavior Awareness in Heterogeneous Cellular Networks ». In : IEEE Transactions on Vehicular Technology 67.5 (mai 2018), p. 4589-4601. ISSN : 0018-9545. DOI : 10.1109/TVT.2018.2796135.
[64] H. KIM et al. « alpha-Optimal User Association and Cell Load Balancing in Wireless Networks ». In : *2010 Proceedings IEEE INFOCOM*. 2010, p. 1-5. DOI : 10.1109/INFCOM.2010.5462272.

[65] H. KIM et al. « Distributed $\alpha$-Optimal User Association and Cell Load Balancing in Wireless Networks ». In : *IEEE/ACM Transactions on Networking* 20.1 (2012), p. 177-190. DOI : 10.1109/TNET.2011.2157937.

[66] N. SAPOUNTZIS et al. « Optimal downlink and uplink user association in backhaul limited HetNets ». In : *IEEE INFOCOM 2016 - The 35th Annual IEEE International Conference on Computer Communications*. Avr. 2016, p. 1-9. DOI : 10.1109/INFOCOM.2016.7524624.

[67] A. SHAVERDIAN, J. GHIMIRE et C. ROSENBERG. « Simple and efficient network-aware user association rules for heterogeneous networks ». In : *Computer Networks* 156 (2019), p. 20-32. ISSN : 1389-1286. DOI : https://doi.org/10.1016/j.comnet.2019.04.001. URL : https://www.sciencedirect.com/science/article/pii/S1389128618304183.

[68] H. DENG et al. « ICellSpeed : Increasing Cellular Data Speed with Device-Assisted Cell Selection ». In : *Proceedings of the 26th Annual International Conference on Mobile Computing and Networking*. MobiCom '20. London, United Kingdom : Association for Computing Machinery, 2020. ISBN : 9781450370851. DOI : 10.1145/3372224.3419201. URL : https://doi.org/10.1145/3372224.3419201.

[69] Y. LIU et al. « Device Association for RAN Slicing Based on Hybrid Federated Deep Reinforcement Learning ». In : *IEEE Transactions on Vehicular Technology* 69.12 (2020), p. 15731-15745. DOI : 10.1109/TVT.2020.3033035.

[70] I. GOMEZ-MIGUELEZ et al. « SrsLTE : An Open-Source Platform for LTE Evolution and Experimentation ». In : *Proceedings of the Tenth ACM International Workshop on Wireless Network Testbeds, Experimental Evaluation, and Characterization*. WiNTECH '16. New York City, New York : Association for Computing Machinery, 2016, p. 25-32. ISBN : 9781450342520. DOI : 10.1145/2980159.2980163. URL : https://doi.org/10.1145/2980159.2980163.

[71] GitHub - *srsran/srsRAN*. URL : https://github.com/srsran/srsRAN (visité le 30/04/2022).

[72] Documentation - *srsran/srsRAN*. URL : https://docs.srslte.com/ (visité le 30/04/2022).

[73] *srsRAN - srsRAN pour la Recherche*. URL : https://www.srslte.com/research (visité le 30/04/2022).

[74] N. BUI et J. WIDMER. « OWL : A Reliable Online Watcher for LTE Control Channel Measurements ». In : *Proceedings of the 5th Workshop on All Things Cellular : Operations, Applications and Challenges*. ATC '16. New York : Association for Computing Machinery, 2016, p. 25-30. ISBN : 9781450342490. DOI : 10.1145/2980055.2980057. URL : https://doi.org/10.1145/2980055.2980057.

[75] R. FALKENBERG et C. WIETFELD. « FALCON : An accurate real-time monitor for client-based mobile network data analytics ». In : *CoRR abs/1907.10110* (2019). arXiv : 1907.10110. URL : http://arxiv.org/abs/1907.10110.
[76] S. KUMAR et al. « LTE Radio Analytics Made Easy and Accessible ». In : *Proceedings of the 2014 ACM Conference on SIGCOMM*. SIGCOMM '14. Chicago, Illinois, USA : Association for Computing Machinery, 2014, p. 211-222. ISBN : 9781450328364. DOI : 10.1145/2619239.2626320. URL : https://doi.org/10.1145/2619239.2626320.

[77] R. FALKENBERG, C. IDE et C. WIETFELD. « Client-Based Control Channel Analysis for Connectivity Estimation in LTE Networks ». In : *2016 IEEE 84th Vehicular Technology Conference (VTC-Fall)*. Sept. 2016, p. 1-6. DOI : 10.1109/VTCFall.2016.7880932.

[78] G. LEE et al. « This is Your President Speaking : Spoofing Alerts in 4G LTE Networks ». In : *Proceedings of the 17th Annual International Conference on Mobile Systems, Applications, and Services*. MobiSys '19. Seoul, Republic of Korea : ACM, 2019, p. 404-416. ISBN : 978-1-4503-6661-8. DOI : 10.1145/3307334.3326082. URL : http://doi.acm.org/10.1145/3307334.3326082.

[79] *Calculateur 4G LTE EARFCN*. URL : https://5g-tools.com/4g-lte-earfcn-calculator/ (visité le 30/04/2022).

[80] NI - USRP-2091. URL : https://www.ni.com/fr-fr/support/model.usrp-2901.html (visité le 30/04/2022).

[81] NI - Antennes VERT2450. URL : https://www.ettus.com/all-products/vert2450/ (visité le 30/04/2022).

[82] Kimovil, Frequency Checker. URL : https://www.kimovil.com/fr/frequency-checker (visité le 30/04/2022).

[83] Open Cell Project. URL : https://open-cells.com/ (visité le 30/04/2022).

[84] Inria Gitlab - Plateforme expérimentale srsRAN, les outils. URL : https://gitlab.inria.fr/rpujol/tools (visité le 30/04/2022).

[85] Twitch. URL : https://www.twitch.tv/ (visité le 30/04/2022).

[86] 3GPP. *Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer; Measurements*. Technical Specification (TS) 36.214. 3rd Generation Partnership Project (3GPP), 2021.

[87] 3GPP. GSM; UMTS; LTE; 5G; Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode. Technical Specification (TS) 23.122. 3rd Generation Partnership Project (3GPP), 2021.

[88] 3GPP. *Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification*. Technical Specification (TS) 36.331. 3rd Generation Partnership Project (3GPP), 2021.

[89] J. SHODAMOLA et al. « A Machine Learning based Framework for KPI Maximization in Emerging Networks using Mobility Parameters ». In : *2020 IEEE International Black Sea Conference on Communications and Networking (BlackSeaCom)*. 2020, p. 1-6. DOI : 10.1109/BlackSeaCom48709.2020.9235020.

[90] G. ALSUHLI et al. « Optimized Power and Cell Individual Offset for Cellular Load Balancing via Reinforcement Learning ». In : *2021 IEEE Wireless Communications and Networking Conference (WCNC)*. 2021, p. 1-7. DOI : 10.1109/WCNC49053.2021.9417360.

[91] 3GPP. 5G; NR; Radio Resource Control (RRC); Protocol specification. Technical Specification (TS) 38.331. 3rd Generation Partnership Project (3GPP), 2021.
[92] Inria Gitlab - Facteur de Charge avec srsRAN. URL : https://gitlab.inria.fr/rpujol/sparelte (visité le 30/04/2022).
FOLIO ADMINISTRATIF

THÈSE DE L'UNIVERSITÉ DE LYON OPÉRÉE AU SEIN DE L'INSA LYON

NOM : PUJOL

DATE de SOUTENANCE : 06/07/2022

Prénoms : Romain

TITRE : Association des Utilisateurs dans les Réseaux Mobiles, Flexibles et Agiles

NATURE : Doctorat

Numéro d'ordre : 2022LYSEI063

Ecole doctorale : InfoMaths

Spécialité : Informatique

RÉSUMÉ :

Le processus d'association des utilisateurs dans les réseaux cellulaires consiste à choisir la station de base avec laquelle l'équipement utilisateur va négocier des ressources radio. L'association actuelle se base sur la mesure de la force du signal reçu par l'équipement utilisateur de la part de chacune des stations de bases. L'association doit aujourd'hui faire face à la diversification des besoins des applications des utilisateurs et à l'hétérogénéité grandissante des réseaux cellulaires.

Dans cette thèse, nous montrons expérimentalement que le processus d'association actuel a atteint ses limites, qu'il est agnostique des configurations des stations et qu'il ne permet pas d'améliorer le débit qu'obtiendra l'équipement utilisateur suite à l'association. Nous mettons en place pour la réalisation de nos mesures une plateforme expérimentale basée sur la suite logicielle d'émulation de réseaux cellulaires srsRAN et de radios logicielles USRP NI-2091.

Nous proposons dans cette thèse une nouvelle métrique à utiliser lors du processus d'association. Cette métrique, diffusée par la station de base, est une information de charge qui sera dans notre cas représentée par le nombre d'équipements utilisateurs connectés à la station de base. Nous discutons également d'autres métriques utilisables comme information de charge. Nous montrons, une nouvelle fois de manière expérimentale, en modifiant nous-même le code source de la suite logicielle srsRAN, que si l'équipement utilisateur tient compte de cette information de charge dans le processus d'association, la décision d'association est améliorée dans 22% des cas.

MOTS-CLÉS : Réseaux mobiles, Réseau d'accès, Association, Sélection de cellules, srsRAN

Laboratoire (s) de recherche : CITI

Directeur de thèse: Fabrice Valois

Président de jury :

Composition du jury :

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