OAI Installation Configuration and Scenarios

Chapitre 4
OpenAirInterface
Introduction
Les réseaux cellulaires LTE 4G se sont vues rapidement adoptés par tous les principaux
opérateurs dans le monde et devraient dominer le paysage cellulaire au moins pour la décennie
en cours. Indubitablement, Ils constitueront également le point de départ de nouveaux progrès
au-delà de la génération actuelle de réseaux cellulaires mobiles pour tracer la voie vers les
réseaux mobiles de cinquième génération. Comme il a été relaté précédemment, plusieurs nou-
velles approches et technologies sont considérées comme des éléments potentiels constituant un
tel ou tel futur réseau mobile, incluant l’utilisation des techniques du cloud au profit du réseau
radio, la possibilité de rendre ce dernier programmable suivant les principes SDN/NFV, le mas-
sif MIMO et le Full Duplex. La recherche sur ces technologies nécessite, donc, des plateformes
d’expérimentation réalistes, flexibles et de faible coût. Dans ce cadre, la plateforme OpenAirIn-
terface constitue un véritable outil d’émulation open source puissant à travers sa configuration
”OpenAirInterface System Emulation” (OAISIM) et un dispositif de test efficaces qui donne des
résultats réalistes à l’aide de son architecture LTE-Softmodem. De ce fait, le présent chapitre
présentera la plateforme OAI ainsi que les options que o↵re par rapport aux autres outils open
source, en mettant l’accent sur sa composition, son architecture et le processus d’installation,
de configuration et de mise en œuvre.
4.1 Environnement de l’OAI

Présentation :
OpenAirInterface [16] est une plateforme d’expérimentation ouverte et un moyen de prototy-
page créé par le département de Communications Mobiles d’EURECOM, étant un établissement
de recherche situé en France, permettant l’innovation dans le domaine des réseaux mobiles en
particulier et des communications sans fil en général. De surcroit, afin de maintenir, promou-
voir, protéger, et faire progresser cette plateforme, EURECOM a créé le fonds de dotation
OpenAirInterface Software Alliance (OSA) visant à fédérer un écosystème open source pour
45
les systèmes cellulaires 3GPP avec la possibilité d’interagir avec des équipements commerciaux
propriétaires à chaque niveau du réseau. L’écosystème est déjà composé d’universités, de grands
acteurs du monde industriel et des développeurs individuels.
OAI est désignée comme étant la première plateforme permettant une implémentation
complète de la pile protocolaire selon la norme 3GPP d’un système LTE aussi bien au niveau
du réseau accès E-UTRAN qu’au niveau du réseau cœur EPC [17]. Ainsi, elle peut être utilisée
pour construire et personnaliser une station de base et un réseau cœur LTE sur un PC et par la
suite faire connecter un UE commercial pour tester d’une part les di↵érentes configurations et
déploiement d’un réseau, d’autre part pour pouvoir surveiller et superviser le fonctionnement
d’un système réseau mobiles en temps réel. Pour ce faire, OpenAirInterface est basée sur une
architecture d’interface radio logicielle hébergée sur PC. Autrement dit, la fonctionnalité de
l’émetteur-récepteur est réalisée via une interface SDR connectée à un ordinateur hôte pour le
traitement des données.
En outre, la plateforme OAI est développée en langage de programmation standard C sous
plusieurs distributions ”real time Linux” optimisées par des processeurs ”x86-64” et publiées
en tant que logiciel libre sous les termes de la version 3 de la GNU ”General Public License”
(GPLv3). Elle fournit un environnement de développement riche avec des outils intégrés tels
que des modes d’émulation très réalistes, des outils de supervision et de débogage, un analyseur
de protocole, un profileur mesurant la performance et un système de logging configurable pour
toutes les couches et tous les canaux [18] et [19].
Grosso modo, deux caractéristiques importantes peuvent décrire l’utilité de la plateforme
OpenAirInterface au profit de la recherche et de l’industrie dans le domaine des réseaux sans
fil à savoir :
• Une implémentation logicielle open-source du système cellulaire LTE (4G), extensible vers
des modules de cinquième génération, qui est entièrement compatible avec les normes
3GPP et pouvant être utilisé dans le cadre des expérimentations et des démonstrations
indoor/outdoor en temps réel ;
• Une capacité d’émulation intégrée pouvant être utilisée afin de tester des scénarios répétitifs
dans un environnement logiciel uniquement, et par la suite basculer de façon transparente
entre l’émulation évolutive et l’expérimentation en temps réel. Pour ce faire, deux modes
d’émulation de couche physique (PHY) sont pris en charge di↵érant par le niveau de
détail auquel la couche PHY est réalisée.
4.2 Composants de l’OAI

En se basant sur l’architecture d’un système LTE, La plateforme OpenAirInterface s’articule
autour de deux composants principaux à savoir : la partie radio représentée par l’E-UTRAN
et la partie cœur nommée l’EPC. La partie émetteur/récepteur tel qu’une station de base, un
point d’accès ou un terminal mobile peut être réalisée à l’aide de la technologie SDR pour créer
46
une interface physique réelle ou bien utiliser la configuration OAISIM afin d’émuler cette partie
du réseau. Quant à la partie cœur EPC, qui est décrite par une suite de logiciels implémentée
dans une machine linux, elle se compose des éléments suivants : le ”Serving Gateway” (S-GW),
le ”Packet Data Network Gateway” (P-GW), le ”Mobility Management Entity” (MME) et
le ”Home Subscriber Server” (HSS). Il est a souligné que la plateforme OAI est la première
implémentation logicielle open source d’un système LTE/LTE-Advanced/LTE-Advanced-Pro
générant une pile protocolaire complète du standard 3GPP à la fois au niveau du réseau accès
et la partie cœur. Enfin, Le reste de cette section décrit les fonctionnalités logicielles, matérielles
et d’émulation d’OAI.
Software :
Rappelons-le, la plateforme OAI dispose d’une implémentation logicielle complète de systèmes
cellulaires mobiles LTE/LTE-A conformes aux normes 3GPP LTE écrite en langage C et py-
thon travaillant sous la distribution Linux version temps réel optimisé par un processeur x86-64.
Les progiciels de l’OSA relatifs au réseau cœur sont rassemblés dans un package appelé ”ope-
nairCN” tandis que ceux correspondant au réseau d’accès E-UTRAN font l’objet du package
”openairinterface5g”. Actuellement, la combinaison de ces deux ensemble de packages forme
une implémentation logicielle ”LTE release 8/9”, ”LTE-Advanced release 10/11/12” et ”LTE-
Advanced-Pro release 13/14” pour les éléments UE, eNB, MME, HSS, S-GW et P-GW sur des
machines Linux. Aussi, Il est à noter que pour permettre l’intégration dans un environnement
OpenStack, ”openairCN” est distribué sous une licence ”Apache V2.0”. De son côté, le pa-
ckage ”openairinterface5g” est distribué gratuitement par l’OSA selon les termes stipulés par
une nouvelle licence open source intitulée la ”OAI Public License” (FRAND), qui couvre les
accords de propriété intellectuelle utilisés dans la norme 3GPP et permettant à ces membres
de détenir des brevets sur les procédures clés utilisées dans les standards [20].
Dans ce contexte, au niveau de la couche physique, OAI o↵re les fonctionnalités suivantes :
• Conforme à la release 8-14 LTE ;

• Configurations FDD et TDD avec des bandes passantes de 5, 10 et 20 MHz ;
• Mode de transmission : 1 (SISO) et 2, 4, 5 et 6 (MIMO 2x2) ;
• Reporting CQI/PMI ;
• Tous les canaux DL sont pris en charge : PSS, SSS, PBCH, PCFICH, PHICH, PDCCH,
PDSCH, PMCH ;
• Tous les canaux UL sont pris en charge : PRACH, PUSCH, PUCCH, SRS, DRS ;
• Support HARQ en UL et en DL ;
• Traitement en bande de base hautement optimisé (y compris le décodeur turbo), dotée du
jeu d’instruction ”AVX2”, une solution logicielle complète o↵rant les types de modulation :
64QAM en liaison descendante et 16QAM en liaison montante pour une bande passante
de 20MHz en mode 1.
47
Concernant la pile protocolaire implémentée au niveau du réseau accès E-UTRAN, elle
fournit les fonctionnalités suivantes :
• Conforme à la release 8-14 LTE ;
• Implémente les couches MAC, RLC, PDCP et RRC ;
• Service de protocole pour eMBMS Rel10 (MCH, MCCH, MTCH) ;
• ”Priority-based MAC scheduler” avec sélection MCS dynamique ;
• Pile protocolaire entièrement reconfigurable ;
• Vérification de l’intégrité et le chi↵rement à l’aide de l’algorithme AES ;
• Prise en charge de la mesure RRC avec écart de mesure ;
• Interfaces standard S1AP et GTP-U vers le réseau cœur ;
• Prise en charge de l’IPv4 et l’IPv6.
Quant au réseau cœur, il se caractérise par :
• Implémentations des MME, S-GW, P-GW et HSS. OAI réutilise les piles de protocoles
d’application GTPv1u et GTPv2c conformément aux normes de l’implémentation logi-
cielle open source d’EPC appelée ”nwEPC” [21] ;
• L’intégrité et le chi↵rement NAS à l’aide de l’algorithme AES ;
• Gestion des procédures UE : attachement, authentification, accès au service, établissement
du support radio ;
• Accès transparent au réseau IP (aucune passerelle S-GW externe ni passerelle P-GW ne
sont nécessaires). Nom du point d’accès configurable, plage IP, DNS et E-RAB QoS ;
• Prise en charge de l’IPv4 et l’IPv6.
Figure 4.1 – OpenAirInterface LTE software stack
Par ailleurs, La plateforme OAI peut fonctionner, selon le type de test, dans plusieurs
configurations distinctes impliquant des équipements commerciaux à di↵érents niveaux à savoir :
• OAI UE <=> OAI eNB + OAI EPC ;
48
• OAI UE <=> OAI eNB + Commercial EPC ;
• OAI UE <=> Commercial eNB + OAI EPC ;
• OAI UE <=> Commercial eNB + Commercial EPC ;
• Commercial UE <=> Commercial eNB + OAI EPC ;
• Commercial UE <=> OAI eNB + Commercial EPC ;
• Commercial UE <=> OAI eNB + OAI EPC.
Hardware :
En de termes d’équipements requis afin de mettre en œuvre la plateforme OpenAirInter-
face, des machines basées sur l’architecture Intel sont nécessaires pour supporter les logiciels
implémentés au niveau de l’eNB, l’UE et l’EPC. Cette exigence est due principalement à des
fonctions DSP optimisées qui utilisent activement les instructions SIMD (SSE, SSE2, SSS3 et
SSE4). Pratiquement, l’OAI a été testée sur les familles de processeurs suivantes :
• Generation 3/4/5/6 Intel Core i5,i7 ;
• Generation 2/3/4 Intel Xeon ;
• Intel Atom Rangeley, E38xx, x5-z8300.
Particulièrement concernant l’UE, il a été testé au moyen de processeurs de type :
• Intel Core™ i5-6600K CPU 3.50GHz × 4 ;
• Intel Core™ i5-6600 CPU 3.30GHz × 4.
En outre, les di↵érentes parties de l’OAI devraient fonctionner sur n’importe quelle machine
Linux 64 bits avec des spécifications à respecter quant au choix du type de noyau en fonction
du composant OAI à installer. Ces contraintes seront détaillées au niveau de la section relative
à l’installation de la plateforme OAI.
Pour l’expérimentation et la validation en mode temps réel, des contraintes spécifiques de
matériel et de système d’exploitation sont requises au niveau des systèmes SDR et accessoires
compatibles avec la plateforme :
• La carte PCI ExpressMIMO2 d’EURECOM, l’interface utilisateur SDR par défaut conçu
pour l’OAI, nécessite un PC avec ”8/16-way PCIe slot” gratuit et un adaptateur appro-
prié. La carte peut fonctionner avec un ”1-way PCIe slot” ou un ”ExpressCard slot” sur
un ordinateur portable ;
• Les cartes NI/Ettus USRP B200/B210/X300/N300 nécessitant un PC avec un port USB3
et un chipset USB compatible. Il convient de souligner que l’OAI prend désormais en
charge le logiciel de pilote de matériel ”UHD Hardware Driver Software” (USRP) à utiliser
avec les versions récentes des plateformes radio logicielles USRP hébergées sur PC étant
largement utilisées par la communauté des chercheurs ;
• BladeRF avec USB3 port ;
49
• LimeSDR avec USB3 port ;
• Le transport Ethernet (échantillons IQ sur Ethernet) nécessite un PC avec un port Fast
Ethernet (10 Gbps ou plus) ;
• Afin de transmettre/recevoir correctement des signaux RF dans di↵érentes bandes, l’équipe
OpenAirInterface a développé une solution passive à base de duplexeur et une solution
active moyennant des duplexeurs/commutateurs et des amplificateurs. Ces solutions sont
compatibles avec les SDR susmentionnés.
Par ailleurs, puisque l’OAI opère souvent dans des bandes de fréquences sous licence, il n’est
pas recommandé d’e↵ectuer des tests Over the air. Car les fréquences allouées aux cellules
commerciales à proximité interfèrent toujours avec l’OAI impactant négativement sur ses per-
formances. Ainsi, afin de ne pas se voir infliger une amende par les autorités compétentes pour
avoir transmis dans une bande sous licence sans autorisation, il est fort recommandé d’utiliser
des chambres anéchoı̈ques ou des cages RF pour e↵ectuer les bancs de teste.
Emulation :
Outre le fonctionnement en mode temps réel de la plateforme OAI en utilisant les équipements
matériels susmentionnés, la pile protocolaire LTE peut être exécutée dans un environnement
en local dans un laboratoire en mode d’émulation afin d’aboutir à une validation réaliste et
une évaluation des performances des systèmes. En e↵et, faisant partie des modules que o↵re
l’OAI, la configuration OAISIM est utilisée afin de mener des simulations et des émulations
expérimentaux d’un réseau LTE ainsi que ses évolutions. OAISIM permet soit la simulation
moyennant la couche physique complète (PHY) impliquant la convolution du vrai signal PHY
avec un canal émulé en temps réel. Soit la simulation en utilisation l’abstraction PHY qui repose
sur une unité d’abstraction PHY simulant les événements d’erreur dans le décodeur de canal.
OpenAirInterface dispose d’un environnement de développement avancé avec de nombreux ou-
tils tels que des modes d’émulation élevés, une surveillance souple, des outils de débogage et
une journalisation configurable pour toutes les couches et tous les canaux [2].
Comme illustré dans la figure 4.2, l’émulation se déroule en trois phases à savoir :
• Configuration du scénario : disposition de l’expérience et séquence d’initialisation du
composant ;
• Exécution : synchronise l’instance du nœud et exécute l’expérience ;
• Analyse des fichiers log et du résultat : superviser l’expérience et traitez les données
brutes (log).
Le scénario est défini en format XML, qui est utilisé pour configurer l’environnement, la
topologie du réseau, le trafic de l’application et les paramètres d’Entrée/Sortie de l’émulation.
Le comportement du support sans fil est modélisé à l’aide d’une unité d’abstraction PHY qui
émule les événements d’erreur dans le décodeur de canal et fournit des mesures émulées à
partir de la couche PHY en temps réel. De ce fait, Le processus d’émulation peut également
50
Figure 4.2 – Emulation process
être utilisé pour tester de manière contrôlée un prototype de système avant son déploiement
dans un environnement RF réel.
4.3 Comparaison de l’OAI avec d’autres plates-formes

et approches
Dans cette section, il est question de discuter succinctement les approches déjà vues ainsi
que d’autres approches et outils d’évaluation dans le cadre de la mise en œuvre de bancs d’essai
relatifs à l’architecture LTE, en vue de mettre en évidence les points distinctifs caractérisant
la plateforme OAI. En e↵et, il existe une approche consistant à déployer des bancs d’essai
moyennant un équipement LTE commercial (eNB, UE et EPC) mais avec un accès ouvert à
l’expérimentation comme le cas du projet CREW [22]. Toutefois, cette approche présente des
inconvénients en l’occurrence une flexibilité contraignante et un déploiement coûteux.
La simulation via le système ”unified system-level simulation” [23] est une approche alter-
native très répondue dans la communauté scientifique dans laquelle l’ensemble ou une partie
de la pile protocolaire d’un système réseau est modélisée. Dans ce contexte, certains outils se
basant sur cette approche sont de nature analytique et sont dépourvue de la notion de temps.
Généralement, de telles méthodologies sont mises en œuvre au niveau de l’outil MATLAB à
titre d’exemple [24]. En outre, il existe d’autres approches à base de simulateurs de réseaux
orientés paquets se reposant sur la simulation à événements discrets. Ces simulateurs, tel que
LENA [25], LTE-Sim [26] et SimuLTE [27], s’appuient sur une horloge logique et modélisent
une partie ou toute la pile protocolaire. Tandis que de son côté, OpenAirInterface implémente
complètement la pile protocolaire sur un environnement d’exécution à contexte réel respectant
les contraintes de synchronisation des trames. De ce fait, en comparaison aux simulateurs sus-
mentionné, OAI est décrite comme étant une plateforme beaucoup plus réaliste, et ce même en
51
mode d’émulation.
Par ailleurs, une autre approche qui devient de plus en plus populaire et qui épouse le
mode de fonctionnement de l’OAI est l’utilisation de plateformes à base des systèmes SDR afin
d’atteindre un maximum de niveau de flexibilité et de réalisme. En e↵et, Il existe plusieurs
projets axés sur l’implémentation logicielle du LTE moyennant des cartes USRP à savoir :
LTEENB [28], OpenLTE, gr-lte [29] et OLSD [30]. Parmi cette liste d’outils, LTEENB atteint
plus de similitudes par rapport à la plateforme OAI en termes de fonctionnalités en particu-
lier en ce qui concerne l’implémentation et l’émulation. Toutefois, il s’agit d’une plateforme
propriétaire commercialisée sous le nom d’Amarisoft. En e↵et, cette dernière est considérée,
au même titre qu’openEPC, comme étant à accès ouvert mais pas open source. Quant à la
plateforme openLTE, bien qu’elle soit bien organisé et facile à personnaliser, elle est jugée
encore incomplète et de nombreuses fonctionnalités sont toujours instables ou en cours de
développement.
De surcroit, WARP [31] et SORA [32] sont également des plateformes largement utilisées
par la communauté scientifique pour des recherches sur les réseaux sans fil, or elles sont
spécialement axées sur la norme 802.11 la rendant moins évolutive. Il est à noter que, bien
qu’elle soit propriétaire, SORA est jugée aussi proche d’OAI dans la mesure où elle intègre
un système LTE complet et une capacité d’émulation intégrant le module SDK de Colombo
[33]. De son côté, srsLTE demeure qu’une simple bibliothèque LTE open source fournissant des
fonctions conformes aux normes pour créer un système LTE et donc cet outil est jugé incom-
plet malgré l’apparition de solutions autonomes eNodeB, UE et, plus récemment, une simple
implémentation EPC.
A la lumière de ces comparaisons, l’OAI possède deux caractéristiques uniques, telles que
mentionnées au début de ce chapitre. D’une part, l’OAI déploie une implémentation logicielle
complète du LTE basée sur les systèmes SDR, open source et conforme aux normes. D’autre
part, elle dispose d’une capacité d’émulation hautement réaliste permettant de mettre en œuvre
des évaluations de système répétables et évolutives. En fin, à travers sa communauté OSA, l’OAI
connait une expansion vertigineuse avec à son actif plusieurs projets de recherche innovants et
plus de 50 laboratoires de recherche universitaires et industriels partenaires.
4.4 Evolution de l’OAI vers les axes de recherche 5G
Etant donné que la conception des systèmes 5G sont toujours sujet de discussion et de
recherche au sein du monde universitaire et industriel, la figure 4.3 présente un ensemble de
projet de recherche 5G identifié par les membres de l’OSA afin de faire évoluer la pile proto-
colaire 3GPP dans le domaine cellulaire tant au niveau de la partie accès qu’au niveau réseau
cœur. Dans cette section, il s’agit de relater une sélection des principaux travaux de recherches
entrepris dans ce cadre à travers des articles scientifiques qui ont déjà été validé.
52
Figure 4.3 – Axes de recherche stratégiques d’OpenAirInterface
Cloud RAN
Les travaux de recherche sur le C-RAN se concentrent essentiellement sur l’optimisation
des ressources matérielles et logicielles ainsi que l’économie de l’énergie. Dans ce contexte,
disposant d’une implémentation complète de la pile protocolaire LTE, la plateforme OAI permet
de mener des bancs d’essai C-RAN prometteur. En e↵et, [34] décrit la mise en place d’un
prototype de réseau d’accès radio C-RAN en utilisant la plateforme OpenAirInterface et du
matériel de base incluant la carte USRP représentant la partie RF. Ainsi, il a été question
d’illustrer le déploiement du ”Remote Cloud Center” (RCC) e↵ectuant un traitement centralisé
en bande de base rattaché à des ”Remote Radio Units” (RRU) connectées via Ethernet. En
outre, cette démonstration a pu illustrer la flexibilité du déploiement de plusieurs architectures
de séparation de protocole de réseau d’accès radio cellulaire en utilisant OAI. Dans ce même
contexte, le troisième scenario du chapitre 5 a pour objectif d’implémenter un système Cloud
RAN complètement virtualisé à l’aide de l’architecture OAISIM en faisant intervenir de multiple
utilisateurs.
Massive MIMO
Faisant partie des axes de recherche clé entrepris par l’OSA, Massive MIMO est considéré
comme étant l’avenir de la prochaine génération de communications sans fil en termes d’ef-
ficacité spectrale et énergétique ainsi que de nombreux autres avantages. Dans ce cadre, [35]
présente un banc d’essai implémentant la technologie massive MIMO via la plateforme Ope-
nAirInterface. Il s’agit de la première expérience au monde a implémenté une station de base
open source conforme au standard LTE dotée d’un réseau d’antennes de grande taille monté sur
des cartes ExpressMIMO2 et USRP pouvant fournir directement des services aux équipements
d’utilisateur commerciaux. Le banc d’essai e↵ectue un étalonnage de réciprocité du canal en
mode TDD pour acquérir des informations précises sur l’état du canal au niveau de l’émetteur
(CSIT). Il montre la possibilité d’utiliser la technologie massive MIMO déjà présente dans
la génération actuelle de la norme LTE en utilisant le mode de transmission ”TM7-TM10”,
53
démontrant la possibilité de pouvoir évoluer en douceur du réseau sans fil 4G à la cinquième
génération.
NOMA
N’ayant jamais été exploré dans le cadre des systèmes de communication actuels et passés,
”Non-Orthogonal Multiple Access” (NOMA) est considéré comme l’une des techniques d’accès
radio proposées pour améliorer l’efficacité spectrale au niveau des futurs réseaux mobiles 5G
par le biais d’un multiplexage utilisateurs dans le domaine énergétique. Bien que le concept de
NOMA ait été proposé il y a plusieurs années, la performance de NOMA n’a été vérifiée qu’en
théorie, mais pas en pratique. Ainsi, le but de l’article [36] est de mettre en œuvre en liaison
descendante un système NOMA basé sur la plateforme OAI en utilisant la technologie SDR.
Dans ce système, un récepteur de type ”Successive Interference Cancellation” (SIC) a été mis
en œuvre en utilisant une méthode de traitement ”multi-thread” afin d’améliorer l’efficacité
du traitement du signal en bande de base. En raison de la limitation des formats ”DownLink
Control Informatiom” (DCI) standard dans les systèmes LTE actuels, un nouveau format DCI
a été spécialement conçu pour la reconstitution des signaux dans le système NOMA développé.
Sur la base de ce système, une série d’expériences des liaisons radio ont été réalisées et les
résultats de l’expérience montrent que le schéma NOMA présente un gain de débit significatif
par rapport à un schéma à accès multiple orthogonal (OMA).
4.5 Installation et configuration de l’OAI

Cette section est consacrée à la description de l’environnement logiciel et matériel de mise en
place de la plateforme OpenAirInterface ainsi que ses étapes d’installation et de configuration.
En e↵et, pour déployer un réseau cellulaire LTE, OAI propose deux modules à savoir : le
réseau d’accès e-UTRAN représenté par un ensemble de packages appelés ”openairinterface5G”
contenant l’eNB et l’UE ainsi que la partie cœur EPC nommée ”openair-cn” qui se compose de
l’entité de gestion de mobilité MME, la base de données HSS et les passerelles S-GW et P-GW
[37].
En outre, diverses configurations de déploiement peuvent être paramétrées à l’aide d’OAI.
A titre d’exemple, il est possible de déployer tous les composants OAI sur la même machine à
savoir : l’UE, l’eNB et tous les éléments EPC. Cependant, cette configuration n’est pas recom-
mandée par EURECOM en raison des conflits potentiels pouvant survenir entre les packages et
le noyau qui di↵ère entre la partie accès et la partie cœur. De plus, cette configuration nécessite
une machine de traitement très puissante (au moins 8 cœurs et 16 Go de RAM). Il existe
une autre configuration plus préconisée qui consiste à exécuter chaque composant sur une ma-
chine distincte. Toutefois, cette configuration est encombrante qui nécessite le déploiement d’un
grand nombre d’équipement [38]. Une option intermédiaire est optée pour ce travail consistant
à déployer l’eNB/UE et l’EPC sur di↵érents hôtes interconnectés par un lien ETHERNET.
54
Architecture réseau et équipement matériel/logiciel utilisé :
L’architecture adoptée pour ce travail afin de déployer le réseau mobile LTE à base de la
plateforme OpenAirInterface, se compose de deux nœuds physiques telle que présentée par la
figure 4.4. Le premier nœud implémente l’eNB et l’UE puisque ce travail se déroule dans un
environnement entièrement simulé à défaut d’avoir les cartes USRP à disposition. Quant au
deuxième nœud, il implémente l’EPC comprenant le MME, le HSS et le SPGW qui sont in-
terconnectés par des interfaces en boucles locales. Le S-GW et le P-GW sont fusionnés pour
ce déploiement, en conséquence les interfaces S5 et S8 sont inexistantes. Le SPGW est relié
à internet via l’interface SGi dont l’adresse est attribuée par un serveur DHCP. Sur le plan
contrôle, le MME est relié à l’eNB par l’interface S1-C pour l’échange de messages de signali-
sation. Alors que sur le plan data, le module SPGW est relié à l’eNB via l’interface S1-U pour
véhiculer le trafic utilisateur. Le plan d’adressage choisi pour chaque interface est explicité sur
la même figure.
Figure 4.4 – Architecture réseau OAI
Les deux nœuds constituant le réseau OAI LTE sont à base de machine linux dotée d’une
distribution de système d’exploitation (OS) Ubuntu 14.04.5 LTS 64-bit, étant la plus stable,
et ayant un processeur 4 CPU Intel Core i5 avec 8 Go en mémoire vive ainsi qu’un disque dur
de 500 Go. La machine destinée à l’installation du module EPC dispose d’un noyau 4.7.7 avec
le module GTP activé afin de supporter le protocole GTP utilisé par les passerelles SPGW.
Tandis que la machine implémentant la partie e-UTRAN est à base d’un OS ayant un noyau
3.19 low-latency pour s’a↵ranchir de problème de temps réel du à l’utilisation de cartes USRP
ou autre matériel RF. Le récapitulatif des équipements mise en œuvre dans le cadre de cette
installation est présenté par le tableau ci-dessous.
55
Equipement Hôte 1 (e-UTRAN) Hôte 2 (EPC)
CPU 4 CPU Intel Core i5, 2.5 GHz 4 CPU Intel Core i5, 2.5 GHz
OS Ubuntu 14.04.5 LTS 64-bit Ubuntu 14.04.5 LTS 64-bit
Noyau 4.7.7 avec module GTP activé 3.19 low-latency
RAM 8 Go 8 Go
Ethernet interface Gigabit Ethernet Gigabit Ethernet
Table 4.1 – Caractéristiques techniques des Machines mises en œuvre
Installation du noyau pour e-UTRAN et EPC

Une fois la distribution Ubuntu 14.04 LTS installée sur les deux machines, le noyau de
chaque hôte est modifié. Pour la machine EPC, la version linux ”kernel 4.7.7 avec module
GTP” est implémentée en utilisant les lignes de commande suivantes :
1 git clone https :// gitlab . eurecom . fr / oai / linux -4.7. x . git
2 cd linux -4.7. x
3 sudo dpkg -i
4 linux - headers -4.7.7 - oaiepc_4 .7.7 - oaiepc -10.00. Custom_amd64 . deb
5 linux - image -4.7.7 - oaiepc_4 .7.7 - oaiepc -10.00. Custom_amd64 . deb
De même, la version linux ”kernel 3.19 low-latency” est configurée sur la machine UE/eNB en
utilisant les lignes de commande ci-après :
1 Sudo apt - get update

2 sudo apt - get install linux - image -3.19.0 -61 - lowlatency
3 linux - headers -3.19.0 -61 - lowlatency
Des configurations supplémentaires sont nécessaires à ajouter dans cette machine. D’abord,
désactiver les ”C-states” à partir du bios afin de réduire la puissance du processeur si la pleine
vitesse n’est pas requise. Ensuite, il faut désactiver le ”CPU frequency scaling” du proces-
seur permettant au système d’exploitation de faire évoluer la fréquence du processeur tout en
économisant de l’énergie. Cette dernière manœuvre est exécutée comme suit :
1 # Install cpufrequtils
2 sudo apt - get install cpufrequtils
3 # Then edit the following file
4 sudo nano / etc / default / cpufrequtils
5 # Add the following line to this file
6 GOVERNOR\="performance
7 # Save and exit
56
8 # Disable ondemand daemon
9 sudo update - rc . d ondemand disable
Téléchargement des codes sources

Les di↵érents packages pour installer l’OAI peuvent être obtenus auprès du serveur ”EU-
RECOM gitLab”. Mais avant de télécharger les codes sources, il faut installer la version récente
de ”subversion/git” en exécutant les commande suivantes :
1 Sudo apt - get update

2 Sudo apt - get install subversion git
Aussi, si une personne désire enregistrer son propre code sur le ”git”, il doit alors configurer ce
dernier avec son nom et son adresse email et ajouter à la machine d’installation Ubuntu 14.04
un certificat d’authentification à partir du site web ”www.gitlab.eurecom.fr”.
Pour obtenir le module ”openairinterface5g” supportant l’eNB et l’UE à partir du serveur
”EURECOM gitLab”, la ligne de commande suivante est exécutée :
1 git clone https :// gitlab . eurecom . fr / oai / op en ai ri nt er fac e5 g . git
Il est procédé de la même manière pour obtenir le module ”openair-cn” qui supporte l’EPC
avec ses trois composantes :
1 git clone https :// gitlab . eurecom . fr / oai / openair - cn . git
En outre, au niveau de la machine EPC, il faut spécifier le ”Fully Qualified Domain Name”
(FQDN) du MME et du HSS qui consiste à donner un nom de domaine complet à un serveur :
1 cat / etc / hosts

2 # edit FQDN
3 127.0.0.1 localhost
4 127.0.1.1 epc . openair4G . eur epc
5 127.0.1.1 hss . openair4G . eur hss
Ici, par exemple, le nom de domaine complètement qualifié est ”epc.openair4G.eur” avec ”epc”
est le ”hostname” et ”openair4G.eur” est le ”realm”.
Par ailleurs, la branche ”Master” est par défaut sélectionnée, étant la branche la plus stable.
Alors que la branche ”develop” qui contient les validations récentes testées sur un banc de test
OAI est activée au besoin suivant la syntaxe suivante :
57
1 cd openair - cn # or open ai ri nt er fa ce 5g
2 git checkout develop
3 git pull
Installation du code
A présent, deux dossiers sont placés dans chaque machine à savoir : ”openair-cn” et ”openai-
rinterface5g”. Un script d’installation automatisé est situé dans le répertoire ”cmake-targets”
pour le cas du module UE/eNB et le répertoire ”scripts” quant au module EPC. L’outil ”cmake”
génère automatiquement des ”Makefiles” afin d’installer le système OAI.
Installation du module EPC :
Tout d’abord, il est nécessaire de basculer à la branche ”develop” pour pouvoir télécharger
les récents packages mis à jour. Ensuite, à partir du répertoire ”scripts”, le MME, le HSS et les
SPGW sont installés à l’aide :
1 ./ build_mme -I # éExcuter une seule fois pour installer les

paquets manquants
2 ./ build_hss -I # éExcuter une seule fois pour installer les
paquets manquants
3 ./ build_spgw -I # éExcuter une seule fois pour installer les
paquets manquants
L’option ”-I” sert à télécharger les packages nécessaires à l’installation ainsi que la mise en
place des dépendances au profit de chaque élément de l’EPC.
Installation du module UE/eNB
De la même façon, à partir du répertoire ”cmake-targets”, le module UE/eNB est installé

sur la machine e-UTRAN comme suit :
1 cd ope na ir in te rf ac e5 G
2 source oaienv # It sets the correct environment variables
3 cd cmake_targets
4 sudo ./ build_oai -I -- install - system - files -- install - optional - packages
Afin de s’enquérir du sens de chaque option, l’entrée ”./build oai–h” est exécutée. Ci-après
une explication de quelques options :
58
• -I : installe les packages requis ;
• -g : ajoute des symboles de débogage aux directives de compilation ;
• - -eNB : installe eNB (cas de la configuration Lte-softmodem) ;
• -x : ajoute la fonction du logiciel ”OAI Scope” aux éléments binaires produits ;
• - -install-system-files : installe les fichiers OAI requis pour le système Linux ;
• -w : ajoute les packages requis à l’installation du matériel RF (USRP, ExpressMIMO2. . . ) ;
• - -install-optional-packages : installe les package optionnels.
Configuration
Afin de pouvoir mettre en œuvre le réseau OAI LTE après l’installation des di↵érents pa-
ckages et modules, des configurations apportées à un nombre de fichiers sont nécessaires aussi
bien au niveau de la machine e-UTRAN qu’au niveau de l’hôte EPC. Les étapes de paramétrage
des trois modules de la partie cœur MME, HSS et SPGW seront explicitées dans cette section.
En revanche, la configuration de la partie e-UTRAN sera traitée tout au long du chapitre 5 en
fonction du scénario mis en place.
Avant de modifier les fichiers de configuration liés à l’EPC, il faut, en premier lieu, procéder
à la copie de ceux-ci dans le dossier ”/usr/local/etc/oai” afin que le système puisse les exploiter
lors de la compilation :
1 sudo mkdir -p / usr / local / etc / oai / freeDiameter

2 sudo cp / home / epc / openair - cn / ETC / mme . conf / usr / local / etc / oai
3 sudo cp / home / epc / openair - cn / ETC / hss . conf / usr / local / etc / oai
4 sudo cp / home / epc / openair - cn / ETC / spgw . conf / usr / local / etc / oai
5 sudo cp / home / epc / openair - cn / ETC / acl . conf / usr / local / etc / oai
6 / freeDiameter
7 sudo cp / home / epc / openair - cn / ETC / mme_fd . conf / usr / local / etc / oai
8 / freeDiameter
9 sudo cp / home / epc / openair - cn / ETC / hss_fd . conf / usr / local / etc / oai
10 / freeDiameter
Ensuite, les paramètres de configuration sont appliqués à chaque fichier en vue de les adapter
à cette application de la manière suivante :
• Au niveau du module MME : il est procédé à la modification du fichier ”mme.conf ”
à l’aide de la commande ”gksu” permettant d’éditer le fichier directement en mode ”root”
comme suit :
1 gksu gedit / usr / local / etc / oai / mme . conf
59
Les modifications e↵ectuées concernent des paramètres réseau tels que le ”Tracking Area Code”
(TAC), ”Mobile Country Code” (MCC), ”Mobile Network Code” (MNC) et les adresses IP
assignées aux interfaces relatives au MME et à l’eNB selon l’architecture réseau de la figure
4.4. Ci-après un extrait de ce fichier :
1 REALM = " openair4G . eur " ;

2 S6A :
3 {
4 S6A_CONF = " / usr / local / etc / oai / freeDiameter / mme_fd . conf " ;
5 HSS_HOSTNAME = " hss " ;
6 };
7 GUMMEI_LIST = (
8 { MCC = " 208 " ; MNC = " 93 " ; MME_GID = " 4 " ; MME_CODE = " 1 " ; }
9 );
10 TAI_LIST = (
11 { MCC = " 208 " ; MNC = " 93 " ; TAC = " 1 " ; }
12 );
13 NE TW OR K_ IN TERFACES :
14 {
15 # MME binded interface for S1 - C or S1 - MME communication ( S1AP )
16 M M E _ I N T E R F A C E _ N A M E _ F O R _ S 1 _ M M E = " eth1 :1 " ;
17 M M E _ I P V 4 _ A D D R E S S _ F O R _ S 1 _ M M E = " 192.168.12.62/24 " ;
18
19 # MME binded interface for S11 communication ( GTPV2 - C )
20 M M E _ I N T E R F A C E _ N A M E _ F O R _ S 1 1 _ M M E = " lo " ;
21 M M E _ I P V 4 _ A D D R E S S _ F O R _ S 1 1 _ M M E = " 127.0.11.1/8 " ;
22 MME_PORT_FOR_S11_MME = 2123;
23 };
24 S - GW :
25 {
26 # S - GW binded interface for S11 communication ( GTPV2 - C ) , if none
selected the
27 ITTI message interface is used
28 S G W_ I P V 4_ A D D R E S S _ F O R _ S 1 1 = " 127.0.11.2/8 " ;
29 };
Un autre fichier doit être modifié dans ce cadre, il s’agit du fichier ”mme fd.conf” qui
implémente le protocole DIAMETER permettant de communiquer avec le HSS via l’interface
S6A.
1 Identity = \epc . openair4G ."eur ;
60
2 Realm = \openair4G ."eur ;
3 ConnectPeer = " hss . openair4G . eur " { ConnectTo = " 127.0.0.1 " ;
4 No_SCTP ; No_IPv6 ; Prefer_TCP ; No_TLS ; port = 3868; realm =
" openair4G . eur " ;};
• Au niveau du module HSS : de la même façon, le fichier ”hss.conf” est édité en

utilisant la ligne de commande suivante :
1 gksu gedit / usr / local / etc / oai / hss . conf
Ainsi, un nombre de paramètres relatifs à la base de données MySQL sont entrés dans ce
fichier en l’occurrence le nom d’utilisateur et le mot de passe. Ceci a pour objectif de permettre
l’accès à la base de données HSS afin de pouvoir y faire les traitements nécessaires. Quant à
la clé de l’opérateur de la base de données ”oai db”, elle doit être rapportée de telle façon à
correspondre à la clé de l’opérateur de la carte USIM du UE. Il est à noter que la base de
données ”oai db”, a été créée au cours de la phase d’installation.
1 HSS :
2 {
3 # MySQL mandatory options
4 MYSQL_server = " 127.0.0.1 " ;
5 MYSQL_user = " root " ;
6 MYSQL_pass = " linux " ;
7 MYSQL_db = " oai_db " ;
8 # HSS options
9 OPERATOR_key = " 1006020 f 0 a 4 7 8 b f 6 b 6 9 9 f 1 5 c0 6 2 e 4 2 b 3 " ;
10 RANDOM = " true " ;
11 # Freediameter options
12 FD_conf = " / usr / local / etc / oai / freeDiameter / hss_fd . conf " ;
13 };
Ensuite, le fichier ”hss fd.conf” correspondant à l’implémentation du protocole DIAMETER

côté HSS est configuré :
1 Identity = \hss . openair4G ."eur ;

2 Realm = \openair4G ."eur ;
• Au niveau du module SPGW : le fichier ”spgw.conf” implémentant les passerelles

S-GW et P-GW est édité grâce à :
61
1 gksu gedit / usr / local / etc / oai / spgw . conf
Les configurations à apporter à ce fichier concernent essentiellement le plan d’adressage des

di↵érentes interfaces suivant l’architecture choisie, le pool d’adresses qui seront a↵ectées à
chaque utilisateur désirant accéder au réseau et d’autres informations relatives au serveur DNS,
MTU etc.
1 S - GW :
2 {
4 {
5 # S - GW binded interface for S11 communication ( GTPV2 - C )
6 S G W _ I N T E R F A C E _ N A M E _ F O R _ S 1 1 = " lo " ;
7 S G W_ I P V 4_ A D D R E S S _ F O R _ S 1 1 = " 127.0.11.2/8 " ;
8 # S - GW binded interface for S1 - U communication ( GTPV1 - U )
9 S G W _ I N T E R F A C E _ N A M E _ F O R _ S 1 U _ S 1 2 _ S 4 _ U P = " eth1 :1 " ;
10 S G W _ I P V 4 _ A D D R E S S _ F O R _ S 1 U _ S 1 2 _ S 4 _ U P = " 192.168.12.62/24 " ;
11 S G W _ I P V 4 _ P O R T _ F O R _ S 1 U _ S 1 2 _ S 4 _ U P = 2152;
12 # S - GW binded interface for S5 or S8 communication
13 S G W _ I N T E R F A C E _ N A M E _ F O R _ S 5 _ S 8 _ U P = " none " ;
14 S G W _ I P V 4 _ A D D R E S S _ F O R _ S 5 _ S 8 _ U P = " 0.0.0.0/24 " ;
15 };
16 };
17 P - GW =
18 {
20 {
21 # P - GW binded interface for S5 or S8 communication
22 P G W _ I N T E R F A C E _ N A M E _ F O R _ S 5 _ S 8 = " none " ;
23 P G W _ I P V 4 _ A D D R E S S _ F O R _ S 5 _ S 8 = " 0.0.0.0/24 " ;
24 # P - GW binded interface for SGI ( egress / ingress internet traffic )
25 P G W _ I N T E R F A C E _ N A M E _ F O R _ S G I = " eth1 " ;
26 PG W_ MA SQ UE RADE_SGI = " yes " ;
27 UE _T CP_M SS_CLAMPING = " yes " ;
28 };
29 # Pool of UE assigned IP addresses
30 IP_ADDRESS_POOL :
31 {
32 IPV4_LIST = ( " 172.16.0.0/12 " ) ;
33 };
34 # DNS address communicated to UEs
62
35 D E FA U L T _D N S _ I P V 4 _ A D D R E S S = " 8.8.8.8 " ;
36 D E F A U L T _ D N S _ S E C _ I P V 4 _ A D D R E S S = " 8.8.4.4 " ;
37 # Non standard feature , normally should be set to " no " , but you may
need to
38 set to yes for UE that do not explicitly request a PDN address
through NAS signalling
39 F O R C E _ P U S H _ P R O T O C O L _ C O N F I G U R A T I O N _ O P T I O N S = " no " ;
40 UE_MTU = 1500;
41 };
4.6 Compilation et exécution :

Dans cette partie, il est question de relater particulièrement les étapes de la compilation et
l’exécution de chaque élément du module EPC en utilisant le dossier ”openair-cn”, la partie
accès étant discutée au cours du chapitre 5, suivant chaque cas de figure.
Avant d’exécuter les composants EPC, il est impératif d’installer les certificats HSS et MME
dans un répertoire situé au ”/usr/local/etc/oai/freeDiameter” comme suit :
1 cd / home / epc / openair - cn / scripts

2 ./ c h e c k _ h s s _ s 6 a_ c e r t i f i c a t e / usr / local / etc / oai / freeDiameter /
hss . openair4G . eur
3 ./ c h e c k _ m m e _ s 6 a_ c e r t i f i c a t e / usr / local / etc / oai / freeDiameter /
epc . openair4G . eur
Pour mettre en œuvre le module EPC, il est, toujours, procédé à la compilation et l’exécution
(figure 4.5 et figure 4.6) du HSS en premier lieu. Ceci est réalisé à l’aide des lignes de commande
suivantes :
1 cd / home / epc / openair - cn / scripts

2 ./ build_hss -c
3 ./ run_hss -i / home / epc / openair - cn / src / oai_hss / db / oai_db . sql
4 ./ run_hss
A présent, il est possible d’accéder à la base de données ”oai db”, présentée par la figure
4.7, en utilisant les paramètres de sécurité configurées préalablement.
Il est procédé de même pour le MME qui est démarré en deuxième lieu à l’aide des lignes
de commande ci-après :
63
Figure 4.5 – HSS est compilé avec succès
Figure 4.6 – HSS est exécuté avec succès
1 cd scripts
2 ./ build_mme -c
3 ./ run_mme -i
Le résultat de la compilation et l’exécution du MME est illustré par la figure 4.8 et la figure
4.9.
Pour le SPGW, les lignes de commande ci-dessous sont utilisées afin d’e↵ectuer la compila-
tion et l’exécution des deux passerelles :
64
Figure 4.7 – la base de données ”oai db”
Figure 4.8 – MME est compilé avec succès
Figure 4.9 – MME est exécuté avec succès
1 cd scripts
2 ./ build_spgw -c
3 ./ run_spgw
Le résultat obtenu est présenté par les captures de la figure 4.10 et la figure 4.11.
65
Figure 4.10 – SPGW est compilé avec succès
Figure 4.11 – SPGW est exécuté avec succès
Conclusion
Ce chapitre avait pour objectif de présenter OpenAirInterface comme étant une plateforme
suffisamment flexible et évolutive capable de promouvoir la recherche 5G. En e↵et, elle o↵re
une implémentation logicielle open source pour les systèmes LTE/LTE-A compatibles avec la
norme 3GPP et permettant de mettre en place des expériences et des démonstrations en temps
réel grâce à la technologie SDR et aussi mener des bancs d’essai complétement virtuels grâce à
sa capacité d’émulation. En outre, il a été mis en exergue, à travers les bancs d’essai réalisés par
les scientifiques de l’OSA, que l’OAI pourrait devenir une plateforme d’évaluation de référence
pour le développement de la technologie 5G en fournissant aux chercheurs un environnement
de prototypage et de test rapide permettant d’expérimenter de nouvelles innovations. Enfin, le
mode d’emploi relatif à la configuration et à l’installation de l’OAI a été présenté servant de
base afin de réaliser les di↵érents scénario du chapitre 5.
66
Chapitre 5
Simulations, Résultats et Discussion
Introduction
Le présent chapitre consiste à déployer quelques scénarios simulant la mise en place de
réseaux 4G/5G moyennant la plateforme OpenAirInterface au sein du laboratoire de l’Insti-
tut. Cette entreprise a pour but de montrer que l’OAI se présente comme une plateforme de
recherche suffisamment flexible pour implémenter un écosystème cellulaire ouvert, tant pour
l’expérimentation 4G que pour la recherche 5G. En e↵et, afin de mettre en œuvre les bancs
de test permettant d’implémenter les scénarios retenus, il a été procédé à l’installation, la
compilation et l’exécution de la plateforme OAI au niveau de deux machines linux, dont les
caractéristiques techniques sont répertoriées dans le tableau 4.1, suivant les étapes et les confi-
gurations relatées dans la section précédentes et en respectant l’architecture réseau présentée
par la figure 4.4. Ainsi, au niveau du premier scénario, il a été question d’interconnecter la
machine OAISIM, implémentant la partie accès et comprenant l’UE et l’eNB, avec la partie
cœur représentée par la machine linux abritant le module EPC via un lien ETHERNET afin
de simuler la procédure d’attachement d’un seul UE. Ensuite, au niveau du deuxième scénario,
le banc de test a été réalisé de manière à connecter plusieurs utilisateurs simultanément au
réseau en apportant les modifications nécessaires tant au niveau de la partie accès qu’au ni-
veau du réseau cœur. Enfin, le troisième scenario consiste à implémenter un module 5G à base
d’un système Cloud RAN complètement virtualisé à l’aide de l’architecture OAISIM en vue
de permettre d’une part l’évaluation des performances de tel système dans di↵érents scénarios
réalistes, d’autre part le déploiement flexible de toute configuration future évoluant dans une
infrastructure de cloud computing.
5.1 Déploiement du 1er scénario et discussion

5.1.1 Déploiement du banc d’essai :
Dans ce scénario, le réseau LTE a été mis en place suivant le schéma illustrée par la fi-
gure 4.4 et faisant appel à deux machines linux dont les caractéristiques techniques figurent
67
dans le tableau 4.1 et qui seront mis à contribution pour réaliser les autres scénarios. Cette
expérimentation consiste à installer, en premier temps, l’architecture EPC ainsi que ses mo-
dules au sein de la première machine linux qui sera interconnectée par la suite à la deuxième
machines implémentant la composante OAISIM qui comprend l’eNB et l’UE. Pour ce faire, les
modules HSS, MME et SPGW ont été configurés, installés et compilés suivant les étapes et
la configuration décrites précédemment. Aussi, les informations relatives à la carte USIM ont
été renseignées dans la base de données HSS pour permettre l’authentification du UE. A l’aide
des lignes de commande explicitées dans la section ”installation de l’OAI”, il a été procédé à
la mise en œuvre du module EPC en commençant par l’exécution de la base de données HSS,
puis le gestionnaire de mobilité MME et enfin les passerelles SPGW.
De même, les modules nécessaires pour exécuter l’OAISIM, eNodeB et UE ont été installés
et compilés. Aussi, tous les fichiers permettant de se connecter à l’EPC ont été configurés en
respectant le tutoriel présenté par le chapitre 4. En e↵et, en respectant l’architecture réseau
retenue pour tous les scénarios, les parties MME et le SPGW sont reliées à l’eNB via l’inter-
face virtuelle eth0 : 1 (192.168.12.82). En revanche, le MME, HSS et SPGW sont connectés
entre eux via l’interface ”loopback” puisqu’ils sont installés dans la même machine. En outre,
le fichier ”ue eurecom test sf r.conf ” a été modifié afin de permettre au UE de s’authentifier
auprès de la base de données HSS. Les informations utilisées dans ce banc d’essai et permettant
d’identifier l’UE sont présentées comme suit :
• Ki Value : fec86ba6eb707ed08905757b1bb44b8f ;
• Operator key : dbc4e25644591a59aa700857a2bf095b ;
• IMSI : 208930100001111 ;
• MSISDN : 33611123456 ;
• IMEI : 356113022094149.
Ainsi, lorsqu’un UE tente de se connecter au MME, le HSS vérifie les informations de
sécurité en calculant automatiquement la clé de l’opérateur à l’aide de la valeur ”Ki” du UE.
Si la clé calculée est identique à celle fournie par l’UE, alors il est autorisé à être attaché à la
MME, sinon il est rejeté.
Afin de mettre en marche le réseau LTE de ce scénario en connectant la partie e-UTRAN
à la partie cœur, la ligne de commande ci-dessous est utilisée afin de procéder à la compilation
du programme :
1 root@oaisim # cd ~/ OPENAIR_DIR / cmake_targets

2 root@oaisim :~/ OPENAIR_DIR / cmake_targets # ./ build_oai -x -c -- oaisim
-t ETHERNET -- UE
68
Figure 5.1 – la compilation est e↵ectué avec succès
Une fois la compilation est correctement e↵ectuée (figure 5.1), la phase du ”Run” est
exécutée en faisant appel au fichier exécutable crée lors de la compilation :
1 root@oaisim # cd ~/ OPENAIR_DIR / cmake_targets / tools /

2 root@oaisim :~/ OPENAIR_DIR / cmake_targets / tools # sudo -E
./ r un _e nb _u e_ vi rt _s 1
Le module EPC étant correctement exécuté à travers ces trois composantes, le module
OAISIM comprenant l’eNB et l’UE se connecte avec succès au réseau cœur (figure 5.2). Ceci
est clairement observé via le tableau inclus dans le fichier log MME illustré par la figure 5.3.
5.1.2 Résultat et discussion :

Dans cette section, il est question de décrire le résultat de l’ouverture et la configuration
de la session LTE engendrée par la réalisation du banc d’essai simulant le premier scenario.
En e↵et, chaque phase de la procédure d’attachement du UE au réseau est vérifiée à travers
les messages marqués dans les fichiers log des di↵érents composants du réseau OAI LTE. Les
étapes du processus d’attachement du UE au réseau enregistrées au cours de la simulation sont
exposées comme suit :
• Random Access Procedure : Lorsque l’émulation démarre, le système initialise tout
d’abord tous les types de paramètres, fonctions, canaux, équipements d’utilisateur, etc.
69
Figure 5.2 – UE et eNB connectés avec succès
Figure 5.3 – Attachement avec succès du UE0 au MME
Ensuite, il génère des messages ”System Information Block” (SIB). Il s’agit de la phase
initialisation. Ensuite, l’eNB envoie un message SIB1, SIB2 et SIB3 via le canal BCCH
vers l’UE qui procède au décodage de ces messages une fois reçus.
70
1 [ RRC ][ I ][ UE 0] Received SIB1 / SIB2 / SIB3 Switching to RRC \ _SI \ _RECEIVED
UE configure les couches PHY/MAC en fonction de ces message et les identifiants RA-RNTI
et C-RNTI temporaire sont attribués. La procédure ”Random Access” s’e↵ectue avec succès.
1 [ PHY ][ I ][ UE 0][ RAPROC ] Random - access procedure succeeded .

2 Set C - RNTI = Temporary C - RNTI
• RRC Connection Establishment : L’UE identifié par le C-RNTI utilise une alloca-
tion UL-SCH pour envoyer le message de demande de connexion RRC. Ce message
contient une identité UE (généralement S-TMSI : MMEC + M-TMSI). Le message inclut
également la cause d’établissement de la connexion RRC.
1 [ RRC ][ I ][ UE 0] : Frame 9 , Logical Channel UL - CCCH ( SRB0 ) ,

2 Generating RRCConnectionReques t ( bytes 6 , eNB 0)
L’eNodeB répond par un message RRC Connection Setup sur le DL-SCH. Le message
crée le ”Signaling Radio Bearer” (SRB) en mode acquittement. Le message contient également
des paramètres de configuration pour la liaison montante RLC, UL-SCH, ”Power Head Room”
(PHR) et le contrôle de puissance en liaison montante.
1 [ RRC ][ I ][ FRAME 00011][ eNB ][ MOD 00][ RNTI 521 d ][ RAPROC ] Logical Channel
DL - CCCH , Generating RRCConnectionSetup ( bytes 25)
• Attach and Authentication : lors de cette phase, L’UE signale la configuration de la

connexion RRC en envoyant un message ”RRC Connection Setup Complete” sur le
canal logique DCCH.
1 [ RRC ][ I ][ UE 0][ RAPROC ] Frame 12 : Logical Channel UL - DCCH ( SRB1 )

2 , Generating R R C C o n n e c t i o n S e t u p C o m p l e t e ( bytes53 , eNB 0)
71
Ce message est également utilisé pour lancer la procédure d’attachement en envoyant la
demande d’attachement en tant que charge utile NAS au MME via l’interface S1AP.
1 [ NAS ][ I ]/ home / salaheddine / openair5G / op en ai ri nt er fa ce 5g / openair3 / NAS / UE

2 / EMM / SAP / emm_send . c :166 EMMAS - SAP - Send Attach Request message with
IMSI
Le message ”Attach Request” inclut également le message ”Connectivity Request

message”

2 / ESM / SAP / esm_send . c :208 ESM - SAP - Send PDN Connectivity Request
message ( pti = 1 , ebi = 0)
A travers l’interface S6a, Le MME contacte le HSS via le protocole DIAMETER en envoyant
le message ”Authentication Info Request” pour récupérer le vecteur d’authentification.
1 ALERT S6A 5 G / openair - cn / src / s6a / s6a_task . c :0080 SENT

to ’ hss . openair4G . eur ’:
2 ’ Authentication - Information - Request ’ 16777251/318
3 f : RP - - src : ’( nil ) ’ len :268 { C :263 / l :45 , C :277 / l :12 , C :264 / l :25 , C :296
/ l :21 , C :293/ l :25 , C :283/ l :21 , C :1/ l :23 , V :10415/ C :1407/ l :15 , V :10415/
4 C :1408/ l :44}
Le HSS transmet le vecteur d’authentification dans le message ”Authentication Infor-

mation Answer au MME.
1 DEBUG S6A openair - cn / src / s6a / s6a_auth_info . c :0217 Received S6A

Authentication
2 Information Answer ( AIA )
Le MME transmet les informations nécessaire à l’UE dans le message ”Authentication

Request” (RAND, AUTN, KSI ASME).
1 INFO NAS \ - EM ir \ - cn / src / nas / emm / sap / emm_send . c :0908 EMMAS \ - SAP \ -
Send
2 Authentication Request message
72
A partir du message ”Authentication Request”, L’UE calcule ensuite les clés de chif-
frement et d’intégrité ainsi que son sceau d’authentification nommée ”RES”. Cette valeur est
transmise au MME à travers le message ”Authentication Response”.

2 / EMM / SAP / emm_send . c :772 EMMAS - SAP
3 - Send Authentication Response message
Apres la procédure EPS-AKA et à partir de l’authentification mutuelle, l’UE et le MME

pourront échanger des données de signalisation dans un tunnel crypté. De ce fait, Le MME
informe l’UE du choix de l’algorithme dans le message ”Security Mode Command”.
1 INFO NAS - EM ir - cn / src / nas / emm / sap / emm_send . c :796 MMAS - SAP - Send
Security Mode Command message
L’UE informe le MME de la génération des clés de sécurités NAS en fonction de l’algorithme
choisi par le MME via le message ”Security Mode Complete”.

2 / EMM / SAP / emm_send . c :853 EMMAS - SAP - Send Security Mode Complete message
Le MME envoie la requête ”Update Location Request” vers le HSS afin de lui notifier
la prise en charge du UE (authentifié) et pour réclamer la récupération du profil d’abonnement
du client.
1 ALERT S6A 5 G / openair - cn / src / s6a / s6a_task . c :0080 SENT to

’ hss . openair4G . eur ’:
2 ’ Update - Location - Request ’ 16777251/316 f : RP - - src : ’( nil ) ’ len :256
3 { C :263 / l :45 , C :277 / l :12 , C :264 / l :25 , C :296 / l :21 , C :293
/ l :25 , C :283/ l :21 , C :1/ l :23 , V :10415/ C :1407/ l :15 , V :10415/ C :1032/ l :16
4 ,V :10415/ C :1405/ l :16}
Le HSS envoie le profil de souscription du client au MME encapsulé dans le message ”Up-
date Location Answer”. A partir de cette confirmation, le MME peut créer une session EPS
et un ”bearer EPS” par défaut.
1 DBG SENT to ’ epc . openair4G . eur ’: ’ Update - Location - Answer ’ 16777251/316

2 f : -P - -
src : ’( nil ) ’ len :736{ C :263/ l :45 , V :10415/ C :1406/ l :16 , V :10415/ C :1400/
73
3 l :576 , C :277/ l :12 , C :264/ l :25 , C :296/ l :21 , C :268/ l :12}
• Default Radio Bearer Setup : Le MME demande la création de session de données

auprès du SGW via le message ”Create Session Request” sur l’interface S11. Le S-GW
transfère ensuite la requête vers le PGW sur l’interface S5 via le protocole GTP afin que
ce dernier valide l’établissement du contexte EPS.
1 TRACE MME - AP - cn / src / mme_app / mme_app_bearer . c :0099 Entering

mme_app_send_s11
2 _c re ate_ session_req ()
Dans la réponse ”Create Session Response” destinée au SGW, le PGW indique l’iden-
tifiant ”Tunnel Endpoint IDentifier” (TEID) pour établir le tunnel GTP sur l’interface S5 avec
le SGW. Le SGW transfère ensuite le message ”Create Session Response” au MME en
allouant un identifiant S1 TEID pour créer le tunnel S1 GTP associé au bearer S1 entre l’eNb
et le SGW.
1 DEBUG SPGW - A penair - cn / src / sgw / sgw_handlers . c :0320 Tx

CREATE - SESSION - RESPONSE
2 SPGW - > TASK_S11 , S11 MME teid 4227862640 S11 S - GW teid 2 S1U teid 2
S1U addr
3 0 x3e0ca8c0EPS bearer id 5 status 16
A la réception de la réponse du PGW ”Create Session Response”, le MME est informé

des ressources à mettre en œuvre pour l’UE. Ensuite, l’adresse IP du UE, l’identification du
bearer EPS et autres informations reçus dans le message ”Attach Accept” de la part du SGW
sont transférés jusqu’au UE permettant ainsi d’aboutir à la réponse de l’UE sur sa demande
”Attach Request”.
1 INFO NAS - EM ir - cn / src / nas / emm / sap / emm_send . c :0180 EMMAS - SAP - Send
Attach
2 Accept message
Le message ”Attach Request” est encapsulé dans le message ”Initial Context Setup
Request” du protocole S1-AP.
1 DEBUG MME - AP - cn / src / mme_app / mme_app_bearer . c :0435 MME APP : Sent

Initial
2 context Setup Request and Started guard timer for UE id 1
74
Et ensuite sur le lien radio via le protocole ”RRC Connection Reconfiguration” en vue
d’être envoyé au UE afin d’activer le ”default radio bearer”.
1 [ RRC ][ I ][ eNB 0] Frame 26 , Logical Channel DL - DCCH , Generate

2 R R C C o n n e c t i o n R e c o n f i g u r a t i o n ( bytes 132 , UE id 521 d )
UE répond à l’eNB par un message ”RRC Connection Reconfiguration complete”.
1 [ RRC ][ I ][ FRAME 00027][ UE ][ MOD 00][ RNTI 521 d ] Logical Channel UL - DCCH
( SRB1 )
2 , Generating R R C C o n n e c t i o n R e c o n f i g u r a t i o n C o m p l e t e ( bytes 2 , eNB_index
0)
L’eNB envoie à son tour le message ”Initial Context Setup Response” au MME incluant
l’identifiant S1 TEID. Le MME de sa part transfère ce message vers le S-GW pour que ce dernier
puisse connaitre le S1-TEID et procéder à la construction du lien avec l’eNB.
1 001129 00014:975490 7 EFE417FA700 TRACE S1AP

- cn / src / s1ap / s1 ap_mme _handl ers . c
2 :0578 Entering s 1 a p _ m m e _ h a n d l e _ i n i t i a l _ c o n t e x t _ s e t u p _ r e s p o n s e ()
Le ”S1 bearer” est ainsi établi via le protocole S1 GTP-U. Le S-GW attend la confirmation
de la connexion du UE. Ce dernier envoi le message ”Attach Complete” au MME, en réponse
au message ”Attach Accept” pour confirmer son attachement auprès du MME.

2 / EMM / SAP / emm_send . c :329 EMMAS - SAP
3 - Send Attach Complete message
Une fois la procédure ”UE Attach” est achevée, une interface virtuelle nommée ”oip1” est
créée et dotée d’une adresse IP (172.16.0.112) assignée par le P-GW indiquant l’établissement
d’un ”S1 bearer”. A travers cette interface, il est possible d’étudier le comportement du UE sur
le plan data. La figure 5.4 illustre les caractéristiques de l’interface générée.
75
Figure 5.4 – l’interfaces virtuelle ”oip1” côté e-UTRAN
Côté EPC, l’interface gtp0 a été créée en guise d’établissement du tunnel GTP lors de
l’opération d’attachement afin d’atteindre le P-GW. La figure 5.5 donne un aperçu de cette
interface virtuelle.
Figure 5.5 – l’interfaces virtuelles ”gtp0” côté EPC
Pour évaluer la connectivité du UE avec le réseau extérieur, un ping a été e↵ectué entre l’UE
et internet à partir de l’interface ”oip1”. Le résultat obtenu est concluant comme le montre la
figure 5.6.
Figure 5.6 – ping concluant vers internet via l’interfaces oip1
76
De même, afin de vérifier la connexion entre le P-GW et l’UE, un ping est lancé au UE à
travers son interface ”oip1”, à partir de la passerelle P-GW via son interface gtp0. L’opération
ICMP est illustrée par la figure 5.7.
Figure 5.7 – ping concluant vers oip1 via l’interfaces gtp0
Au vu des résultats obtenus, il a été démontré que l’UE a pu s’attacher au réseau et que
le plan data a bien été établi entre le terminal virtuel et internet. Ce dernier constat peut être
compris d’avantage par les captures Wireshark affichées par la figure 5.8 et la figure 5.9.
Figure 5.8 – Capture Wireshark d’une requête ICMP entre oip1 et gtp0
77
Figure 5.9 – Capture Wireshark d’une requête ICMP entre oip1 et internet
En résumé, au cours de ce banc d’essai, il a été question d’émuler le processus d’attachement

d’un UE à un réseau LTE à base d’un eNB/UE simulé et un EPC OAI. Par la suite, en
exploitant les fichiers log des di↵érents composants de l’architecture LTE de bout en bout, le
plan de contrôle a été observé à chaque étape. De même, l’établissement des di↵érents bearers
et tunnels du plan data a été vérifié en lançant plusieurs requêtes ICMP.
5.2 Déploiement du 2ème scénario et discussion :

Le deuxième banc de test consiste à attacher plusieurs UEs simultanément au réseau OAI
LTE émulé précédemment. En adoptant la même architecture réseau de la figure 4.4 et avant
de procéder à l’exécution du système, le fichier ”ue eurecom test sfr.conf” a été modifié côté
e-UTRAN et la base de données HSS réalimentée côté EPC. Cette manœuvre vise à permettre
à de multiple UEs de s’authentifier auprès du module HSS. L’annexe A présente un extrait de
ce fichier de configuration. Les informations USIM utilisées dans cette expérimentation permet
d’identifier trois UEs dans le réseau. En plus du UE intervenu dans le premier scénario, deux
autres utilisateurs sont mis à contribution en supposant que tous les utilisateurs appartiennent
au même réseau PLMN dans un but de simplification. Les données d’authentification USIM
utilisées au profit des UEs sont listées dans le tableau 5.1.
78
Utilisateurs Paramètres de la carte USIM
UE 0
• IMSI : 208930100001111 ;
• MSISDN : 33611123456 ;
• IMEI : 356113022094149.
UE 1
• IMSI : 20893 0100001112 ;
• MSISDN : 33638030012 ;
• IMEI : 35609304079212.
UE 2
• IMSI : 20893 0100001113 ;
• MSISDN : 33638030013 ;
• IMEI : 35609304079213.
Table 5.1 – Les données d’authentification USIM de UE0, UE1 et UE2
Une fois le fichier OAISIM paramétré, la compilation de la machine OAISIM est relancée
pour tenir compte des nouvelles configurations. Par la suite, afin de pouvoir émuler les trois
utilisateurs en même temps, les fichiers ”.nvramX” sont générés à l’aide de la commande :
1 sudo -E ./ conf2uedata -c
~/ OPENAIR_DIR / openair3 / NAS / TOOLS / ue_eurecom_test_sfr . conf -o
~/ OPENAIR_DIR / cmake_targets / oaisim_build_oai / build
L’exécutable ”conf 2uedata” est généré au cours de la compilation dans le dossier ”s

/OP EN AIR DIR/target/bin”. Au niveau du même dossier, on fait appelle au fichier exécutable
”oaisim.Rel14” afin de lancer l’exécution de la simulation en utilisant la ligne de commande
suivante :
1 sudo -E ./ oaisim . Rel14 -O

/ home / salaheddine / openair5G / op en ai ri nt er fa ce 5g / targets / PROJECTS
2 / GENERIC - LTE - EPC / CONF / enb . band7 . generic . oaisim . local
3 _mme . conf {u3 - s15 - AAWGN - y1 - b1 - Q0 -- xforms

Une fois que les trois UEs sont connectés avec succès à la machine EPC, le résultat de la
figure 5.10 est observé du côté du module MME indiquant que les di↵érents Bearers de chaque
utilisateur ont été créés et que les UEs ont bien accompli le processus d’attachement au réseau
LTE.
79
Figure 5.10 – Attachement avec succès de UE0, UE1 et UE2 au MME
Du côté HSS, le résultat est confirmé à travers l’enregistrement aves succès des trois UEs
auprès de la base de données lors de l’opération d’authentification comme ceci est reflété par
la capture de la figure 5.11 et les messages, ci-dessous, extraits du fichier log :
1 [ NAS ][ I ]/ home / salaheddine / openair5G / op en ai ri nt er fa ce 5g / openair3 / NAS

2 / UE / EMM / emm_main . c :203 EMM - MAIN - USIM application data successfully
read
3 [ NAS ][ I ]/ home / salaheddine / openair5G / op en ai ri nt er fa ce 5g / openair3 / NAS
4 / UE / EMM / emm_main . c :403 EMM - MAIN - EMM data successfully read
Figure 5.11 – Authentification acceptée par le HSS
80
Chaque UE écoute sur un port UDP pour recevoir des commandes ”Hayes”. Le port par
défaut est 10000 pour le premier UE, 10001 pour le second et 10002 pour le troisième. Ceci
peut être démontré à travers les messages log suivants :

2 / API / USER / user_api . c :145 USR - API - User ’s UDP socket 52 is BOUND to
epc /10000
epc /10001
epc /10002
Par ailleurs, Afin d’examiner le bon fonctionnement du plan data, des requêtes ICMP ont
été lancées à partir de chaque UE via l’interface ”oipX” en vue de vérifier la connectivité avec
le réseau extérieur. En e↵et, les interfaces virtuelles ”oipX” ont été créées avec succès après
l’opération d’attachement comme illustrée par la figure 5.12.
Figure 5.12 – les interfaces virtuelles ”oipX”
Et le ping entre chaque UE et Internet est e↵ectué correctement comme cela est affiché sur
la figure 5.13.
81
Figure 5.13 – ping concluant vers internet via les interfaces UE0, UE1 et UE2
En outre, dans le but d’étudier le comportement de la couche physique du UE et de l’eNB

au cours des échanges radios, l’OSA a prévu un outil de surveillance appelé ”OAI Soft Scope”.
Cet outil fourni des plots à propos de la puissance du signal reçu, la réponse impulsionnelle
du canal, la réponse en fréquence du canal, ”Log-Likelihood Ratios” (LLR), le débit et les
composants I/Q (à titre d’exemple dans ce test, les constellations 4-QAM et 16-QAM ont été
utilisées). La figure 5.14 donne un aperçu sur quelques transactions entre l’eNB et le premier
utilisateur UE0 à travers les di↵érents canaux physiques. En e↵et, cet outil graphique permet
l’étude statistique des trois principaux canaux en liaison descendante à savoir : PBCH, PDCCH
et PDSCH et deux canaux physiques en liaison montante qui sont : PUSCH et PUCCH.
Figure 5.14 – DL et UL Scope entre l’eNB et l’UE0
Un autre outil est implémenté dans l’OAI appelé ”OAI Performance Profiler” destiné à
mesurer et analyser le temps d’exécution des di↵érents opérations intervenant dans les échanges
82
entre l’UE et l’eNB. La figure 5.15 présente une capture du résultat obtenu après le lancement
de cet outil au profit du deuxième scénario.
Figure 5.15 – Résultat obtenu par ”OAI Performance Profiler” entre l’UE0 et l’eNB
En récapitulatif, lors de cette expérience, l’objectif était de parvenir à émuler cette fois
l’opération d’attachement de trois UEs simultanément au réseau OAI LTE. A cet e↵et, en
faisant appel aux fichiers log, aux requêtes ICMP ainsi que les outils o↵erts par la plateforme,
le plan de contrôle a été examiné au même titre que le plan data.
5.3 Déploiement du 3ème scénario et discussion :

Comme il a été relaté précédemment, afin de rendre les réseaux plus efficaces, simplifier leur
maintenance et leur évolution, les unités de calculs ont été séparées des éléments de transmission
RRH (antennes et convertisseurs analogique-numérique). Dans une seconde étape, ces unités
de calcul dédiées aux traitements de signal en bande de base (BBU) ont été rassemblées dans
un même emplacement, puis les traitements de signal ont été attribués à un même serveur
composé de plusieurs éléments de calcul dédié à des fonctions spécifiques. De surcroit, dans
une architecture Cloud RAN l’évolution des Hardwares permettrait de réaliser ces calculs avec
des logiciels en environnement virtualisé, exécutés sur une plateforme générique, donc moins
coûteuse et moins énergivore. De ce fait, Les avantages de Cloud RAN consistent non seulement
à faire des économies dans l’installation et l’opération, mais aussi augmenter la performance
des transmissions sans fil grâce au traitement conjoint des signaux de plusieurs cellules radio.
Vu l’importance de ce type d’architecture quant au déploiement des futurs réseaux 5G,
les systèmes C-RAN sont considérés parmi les axes de recherche stratégiques de cinquième
83
génération définis par l’OSA. S’inscrivant dans cette optique, le troisième scénario a pour ob-
jectif de mettre en place un module 5G Cloud RAN en utilisant l’émulateur OAI afin d’évaluer
les performances de telle architecture ainsi que de permettre l’étude et le test en laboratoire de
toute architecture évoluant dans une infrastructure de cloud computing avant son déploiement
futur. Pour ce faire, ce banc d’essai a été basé sur les deux machines utilisées précédemment
pour implémenter le réseau d’accès et la partie cœur suivant l’architecture explicité par la figure
5.16. L’environnement et les conditions d’exécution des trois modules constituant la machine
EPC sont maintenus à l’instar des deux autres scénarios. En revanche, la machine e-UTRAN a
été reconfigurée tout en gardant le même environnement.
Figure 5.16 – Architecture réseau du module C-RAN adoptée pour ce scenario
En e↵et, afin d’implémenter la partie accès dans cette démonstration, il a été sujet d’utiliser
la branche ”develop” qui supporte la version ”oaisim-rru” permettant d’extraire les modules
nécessaires pour déployer le RRH/UE et le BBU. Ainsi, malgré quelques bugs dus à l’instabilité
de la branche ”develop”, Les modules contenus dans cette version permettent de mener des
simulations sans carte RF ou UE réelle. Comme illustré sur la figure 5.16, la version oaisim-
rru fournit un module intégré qui englobe l’UE et le RRH. Etant déployés sur le même hôte,
le RRH et le BBU sont connectés via l’interface ”loopback”, tandis que le BBU est connecté
via l’interface virtuelle eth0 :1 (192.168.12.82) à l’EPC. En utilisant la bande 7 de l’Evolved
Universal Mobile Télécommunications System (UMTS) Terrestrial Radio Access (E-UTRA) et
à l’image des autres scenarios, la fréquence utilisée en liaison descendante est de l’ordre de 2680
MHz alors qu’en liaison montante, elle est égale à 2560 MHz. Le mode de duplexage utilisé est
le ”Frequency Division Duplex” (FDD) avec une bande passante d’environ 5 MHz.
Deux fichiers sont à traiter pour mettre en œuvre l’eNB dans l’architecture C-RAN selon le
schéma de réseau de la figure 5.16.
Ainsi, le premier fichier nommée ”rru.band7.tm1.if4p5.25PRB.oaisim.conf” est paramétré
afin de démarrer le RRH, tandis que le fichier ”rcc.band7.tm1.if4p5.25PRB.lo.conf” est configuré
en vue de lancer le BBU. Les extraits de ces deux fichiers de configuration sont présentés par
l’annexe B. Au niveau de cette démonstration, deux utilisateurs sont mis à contribution afin de
s’attacher au réseau. Pour cela, les données de configuration USIM utilisées sont celles des UE0
84
et UE1 mentionnées dans le tableau et qui sont déjà enregistrées dans la base de données HSS
permettant de vérifier l’identité de ses deux UEs. Ses données d’authentification sont reportées
sur le fichier ”ue eurecom test sfr.conf”.
Après le paramétrage des fichiers ”oaisim-rru”, la compilation de la machine RRH +
U E/BBU est relancée pour tenir compte des nouvelles configurations. Par la suite, afin de
pouvoir émuler les deux utilisateurs en même temps, les fichiers ”.nvramX” sont générés à
l’aide de l’exécutable ”conf 2uedata” à l’instar du deuxième scénario.
Dans le but de démarrer le module OAI RRU (RRH)/UE, la ligne de commande suivante
est utilisée :
1 sudo -E gdb -- args ./ oaisim -O

/ home / salaheddine / openair5G / op en ai ri nt er fa ce 5g / targets / PROJECTS
2 / GENERIC - LTE - EPC / CONF rru . band7 . tm1 . if4p5 .25 PRB . oaisim . conf - u2
3 -- xforms
Une fois, ce module est correctement exécuté, le résultat affiché sur l’écran est donné par la
figure 5.17.
Figure 5.17 – OAI RRU est exécutés correctement et reste en attente de la connexion OAI RCC
De même, afin d’exécuter le module BBU, la ligne de commande ci-dessous est entrée au
niveau du shell :
85
1 sudo -E gdb -- args ./ lte - softmodem -O
2 / home / salaheddine / openair5G / op en ai ri nt er fa ce 5g / targets / PROJECTS
3 / GENERIC - LTE - EPC / CONFrcc . band7 . tm1 . if4p5 .25 PRB . lo . conf
Après que l’OAI RCC (BBU) est connecté avec succès à l’OAI RRU (RRH), la sortie affichée
sur le terminal est illustrée par la figure 5.18.
Figure 5.18 – OAI RCC connecté avec succès

Au cours du processus d’attachement, le RRH envoie au UE un message ”Security Mode
Command” sur le canal DCCH comme il a été expliqué au niveau du premier scénario. Ensuite,
l’UE décode le message reçu, configure le mode ”Security” pour le protocole PDCP et renvoie un
message ”Security Mode Complete” au RRH sur le même canal DCCH afin d’accuser réception
du premier message. Le RRH configure à son tour le protocole PDCP une fois le message reçu,
achevant ainsi la procédure d’activation de la sécurité initiale comme le montre la figure 5.19.
Figure 5.19 – Security mode command complete
86
Après l’accomplissement de la phase d’authentification, les deux UEs sont attachés au MME
suivant le tableau des connexions extrait du fichier log MME présenté par la figure 5.20.
Figure 5.20 – Attachement avec succès de UE0 et UE1 au MME
Par conséquent, le BBU est associé au MME avec succès suivant le message inclut dans le
fichier log OAI RCC comme suit :
1 [ ENB_APP ][ I ][ eNB_app_task ] [ eNB 0]

2 Received S 1A P_RE GISTE R_EN B_CN F : associated MME 1
Par ailleurs, à titre d’exemple, la figure 5.21 donne un aperçu sur le comportement de l’UE0
au niveau du plan contrôle en liaison descendante via l’outil ”OAI Soft Scope”. En e↵et, elle
présente les données transmises sur la trame en cours ainsi que les informations relatives aux
ressources à allouer au UE en liaison montante. Ces données de contrôle appelées Downlink
Control Information (DCI) sont transmises sur le canal PDCCH. Aussi, cette figure présente
les transactions qui s’opèrent au niveau du canal PDSCH qui supporte les canaux de transport
DL-SCH et le PCH permettant de transmettre le trafic utilisateur ainsi que des informations
sur le ”paging”.
Par ailleurs, afin d’étudier et surveiller les réseaux OAI à tester, l’OSA a prévu le Frame-
work ”T-tracer”. Il s’agit d’un outil puissant qui permet d’examiner la pile protocolaire (PHY,
MAC, RLC, PDCP et RRC) entre l’UE sélectionné et l’eNB ainsi que d’autres informations.
Ces informations concernent le type de modulation et de codage adoptés, les canaux physiques
(PUSCH, PUCCH), la puissance du signal reçu, l’énergie du UE sélectionné, les messages HAR-
Q/ACK/NACK, le débit mesuré en UL et en DL et des messages log pour le ”troubleshooting”.
Cet outil a été conçu spécialement au profit de la configuration ”LTE-Softmodem” à base de
matériel RF, mais en téléchargeant des packages mis à jour pour les versions récentes du module
”openairinterface5G”, ”T-tracer” a pu fonctionner dans un environnement OAISIM en utilisant
l’option ”–T-tracer” à ajouter avant la compilation. La figure 5.22 donne le résultat obtenu avec
l’outil ”T-tracer” lors des échanges entre l’UE0 et le BBU pris à titre d’exemple.
Sur le plan data, la figure 5.23 montre la capacité des deux utilisateurs à accéder à internet
87
Figure 5.21 – DL Scope de l’eNB (RRH/BBU) au UE0
Figure 5.22 – Résultat obtenu par T-tracer entre l’UE0 et l’eNB (RRH/BBU)
via le réseau OAI C-RAN mise en œuvre dans le cadre de ce banc d’essai. En e↵et, en lançant
une requête ICMP à l’adresse ”google.com” à travers les interfaces virtuelles ”oipX”, le ping
s’exécute avec succès. Les adresses des interfaces ”oip1” (172.16.0.116) et ”oip2” (172.16.0.118)
représentant respectivement l’UE0 et l’UE1 sont assignées par le P-GW lors du processus
d’attachement au réseau.
88
Figure 5.23 – Ping concluant vers internet via les interfaces UE0 et UE1
De surcroit, l’outil ”traceroute” a été utilisé afin de voir plus en détail le comportement des
paquets envoyés par les deux UEs à destination du lien ”google.com”. Le tableau 5.2 montre
la réponse temporelle du passage du paquet, sortant du UE en utilisant l’interface virtuelle
”oipX” , par tous les hôtes avant d’arriver à l’adresse cible.
User Host Avg(ms) First(ms) Second(ms) Last(ms)

172.16.0.1 87,541 86,638 86,627 89,359
192.168.1.1 89,351 89,356 89,351 89,345
196.75.72.1 131,085 126,407 129,151 137,698
81.192.65.138 146,025 143,261 146,037 148,778
81.192.65.137 160,342 157,576 157,570 165,88
UE 0
81.192.12.14 133,227 174,324 105,419 119,938
72.14.204.186 177,638 159,461 185,348 188,105
108.170.252.241 199,690 196,906 196,905 205,26
66.249.95.55 210,963 205,257 213,817 213,815
172.217.19.46 223,168 219,303 222,188 228,014
172.16.0.1 116,927 116,937 116,925 116,920
192.168.1.1 116,911 116,915 116,911 116,907
196.75.72.1 135,114 116,902 144,22 144,219
81.192.65.130 169,589 169,592 169,590 169,585
81.192.65.137 169,582 169,582 * *
UE 1
81.192.12.18 112,135 172,26 80,399 83,745
72.14.204.186 167,408 167,412 167,409 167,402
108.170.252.225 173,653 167,396 167,39 186,172
72.14.233.67 186,160 186,167 186,159 186,154
172.217.19.46 195,239 195,242 195,239 195,235
Table 5.2 – Informations obtenues par traceroute via les interfaces UE0 et UE1
89
Conclusion
Au cours de ce chapitre, il a été sujet de présenter trois scénarios relatifs au déploiement
d’un réseau 4G/5G via la plateforme OpenAirInterface dans le but de fournir une configuration
expérimentale proche de la réalité au profit de ce type de réseau mobile ainsi que pour les
architectures futures en utilisant un outil open source au lieu de modules commerciaux. En e↵et,
le premier et le deuxième banc d’essai avaient pour objectif d’étudier le processus d’attachement,
respectivement, d’un seul UE et de plusieurs UEs au réseau OAI LTE. Quant à la troisième
expérience, il a été question de décrire le déploiement et la configuration d’un module 5G à base
de l’architecture C-RAN en utilisant l’OAI afin de desservir deux UEs. Les di↵érents résultats
obtenus au niveau des trois scenarios ont été expliqués à l’aide de captures d’écran, outils de
surveillance OAI dédiés et de fichiers log.
90
Annexe A
Fichier de configuration des UEs
1 # List of known PLMNS

2 PLMN : {
3 PLMN0 : {
4 FULLNAME = " Test network " ;
5 SHORTNAME = " OAI4G " ;
6 MNC = " 01 " ;
7 MCC = " 001 " ;
8 };
9 PLMN4 : {
10 FULLNAME = " OAI LTEBOX " ;
11 SHORTNAME = " OAIALU " ;
12 MNC = " 93 " ;
13 MCC = " 208 " ;
14 };
15 UE0 :
16 {
17 USER : {
18 IMEI = " 356113022094149 " ;
19 MANUFACTURER = " EURECOM " ;
20 MODEL = " LTE Android PC " ;
21 PIN = " 0000 " ;
22 };
23 SIM : {
24 MSIN = " 0100001111 " ;
25 USIM_API_K = " 8 b a f 4 7 3 f 2 f 8 f d 0 9 4 8 7 c c c b d 7 0 9 7 c 6 8 6 2 " ;
26 OPC = " e 7 3 4 f 8 7 3 4 0 0 7 d 6 c 5 c e 7 a 0 5 0 8 8 0 9 e 7 e 9 c " ;
27 MSISDN = " 33611123456 " ;
28 };
29 # Home PLMN Selector with Access Technology
30 HPLMN = " 20893 " ;
31
32 # User controlled PLMN Selector with Access Technology
33 UCPLMN_LIST = () ;
34
35 # Operator PLMN List
36 OPLMN_LIST = ( " 00101 " , " 20893 " ) ;
37
38 # Operator controlled PLMN Selector with Access Technology
39 OCPLMN_LIST = ( " 22210 " , " 21401 " , " 21406 " , " 26202 " , " 26204 " ) ;
40
41 # Forbidden plmns
42 FPLMN_LIST = () ;
43
44 # List of Equivalent HPLMNs
45 # TODO : UE does not connect if set , to be fixed in the UE
46 # EHPLMN_LIST = ("20811" , "20813") ;
47 EHPLMN_LIST = () ;
93
48 };
49 UE1 :
50 {
51 USER : {
52 IMEI = " 35609304079212 " ;
55 PIN = " 0000 " ;
56 };
57 SIM : {
58 MSIN = " 0100001112 " ;
60 OPC = " e 7 3 4 f 8 7 3 4 0 0 7 d 6 c 5 c e 7 a 0 5 0 8 8 0 9 e 7 e 9 c " ;
61 MSISDN = " 33638030012 " ;
62 };
64 HPLMN = " 20893 " ;
65
68
70 OPLMN_LIST = ( " 20811 " , " 20813 " ) ;
71
73 OCPLMN_LIST = ( " 22210 " , " 21401 " , " 21406 " , " 26202 " , " 26204 " ) ;
74
77
80 # EHPLMN_LIST = ("20811" , "20813") ;
82 };
83 UE2 :
84 {
85 USER : {
86 IMEI = " 35609304079213 " ;
89 PIN = " 0000 " ;
90 };
91 SIM : {
92 MSIN = " 0100001113 " ;
94 OPC = " e 7 3 4 f 8 7 3 4 0 0 7 d 6 c 5 c e 7 a 0 5 0 8 8 0 9 e 7 e 9 c " ;
95 MSISDN = " 33638030013 " ;
96 };
98 HPLMN = " 20893 " ;
99
102
104 OPLMN_LIST = ( " 00101 " , " 20810 " , " 20811 " , " 20813 " , " 20893 " , " 310280 " ,
" 310028 " ) ;
105
107 OCPLMN_LIST = ( " 22210 " , " 21401 " , " 21406 " , " 26202 " , " 26204 " ) ;
108
111
114 # EHPLMN_LIST = ("20811" , "20813") ;
116 };
94
Annexe B
Fichier de configuration des entités

RRH et BBU
1 Active_eNBs = ( " e NB _E ur ec om_ LT EBox " ) ;

2 # Asn1_verbosity , choice in : none , info , annoying
3 Asn1_verbosity = " none " ;
4 eNBs =
5 (
6 {
7 ////////// Identification parameters :
8 eNB_ID = 0 xe00 ;
9 cell_type = " CELL_MACRO_ENB " ;
10 eNB_name = " eNB_Eurecom_LT EB ox " ;
11 // Tracking area code , 0 x0000 and 0 xfffe are reserved values
12 tracking_area_code = " 1 " ;
13 mobile_c o un t r y_ c o d e = " 208 " ;
14 mobile_n e tw o r k_ c o d e = " 93 " ;
15
16 ////////// Physical parameters :
17 component_carriers = (
18 {
19 node_function = " NGFI_RRU_IF4p5 " ;
20 node_timing = " s y n c h_to_ext_device " ;
21 node_synch_ref = 0;
22 frame_type = " FDD " ;
23 tdd_config = 3;
24 tdd_config_s = 0;
25 prefix_type = " NORMAL " ;
26 eutra_band = 7;
27 downli nk_frequency = 2685000000 L ;
28 uplink_frequency_offset = -120000000;
29 Nid_cell = 0;
30 N_RB_DL = 25;
31 Nid_cell_mbsfn = 0;
32 nb_antenna_ports = 1;
33 nb_antennas_tx = 1;
34 nb_antennas_rx = 1;
35 tx_gain = 90;
36 rx_gain = 120;
37 prach_root = 0;
38 prach_ config_index = 0;
39 prach_high_speed = " DISABLE " ;
40 pr ac h_ z e r o _ c o r r e l a t i o n = 1;
41 prach_freq_offset = 2;
42 pucch_delta_shift = 1;
43 pucch_nRB_CQI = 1;
44 pucch_nCS_AN = 0;
95
45 pucch_n1_AN = 32;
46 pdsch_referenceSignalPower = -29;
47 pdsch_p_b = 0;
48 pusch_n_SB = 1;
49 pusch_enable64QAM = " DISABLE " ;
50 pusch_hoppingMode = " interSubFrame " ;
51 pusch_ ho p p in g O ff s e t = 0;
52 pusch_groupHoppingEnabled = " ENABLE " ;
53 pus ch_ g r o u p A s s i g n m e n t = 0;
54 pusch_sequenceHoppingEnabled = " DISABLE " ;
55 pusch_nDMRS1 = 1;
56 phich_duration = " NORMAL " ;
57 phich_resource = " ONESIXTH " ;
58 srs_enable = " DISABLE " ;
59 pusch_p0_Nominal = -95;
60 pusch_alpha = " AL1 " ;
61 pucch_p0_Nominal = -104;
62 msg3_d el t a _P r e am b l e = 6;
63 pucch_ d e l t a F _ F o r m a t 1 = " deltaF2 " ;
64 puc ch_ d e l t a F _ F o r m a t 1 b = " deltaF3 " ;
65 pucch_ d e l t a F _ F o r m a t 2 = " deltaF0 " ;
66 puc ch_ d e l t a F _ F o r m a t 2 a = " deltaF0 " ;
67 puc ch_ d e l t a F _ F o r m a t 2 b = " deltaF0 " ;
68 rach_numberOfRA_Preambles = 64;
69 rach_preamblesGroupAConfig = " DISABLE " ;
70 rac h_p o w e r R a m p i n g S t e p = 4;
71 rach_preambleInitialReceivedTargetPower = -104;
72 rac h_p r e a m b l e T r a n s M a x = 10;
73 rach_raResponseWindowSize = 10;
74 rach_macContentionResolutionTimer = 48;
75 rach_m ax H A RQ _ M sg 3 T x = 4;
76 pcch_default_PagingCycle = 128;
77 pcch_nB = " oneT " ;
78 bcch_modificationPeriodCoeff = 2;
79 ue_TimersAndConstants_t300 = 1000;
83 ue_TimersAndConstants_n310 = 20;
84 ue_TimersAndConstants_n311 = 1;
85 ue_Tra ns m i ss i o nM o d e = 1;
86 }
87 );
88 srb1_parameters :
89 {
90 # ti m e r _ p o l l _ r e t r a n s m i t = ( ms ) [5 , 10 , 15 , 20 ,... 250 , 300 , 350 ,
... 500]
91 tim e r _ p o l l _ r e t r a n s m i t = 80;
92 # timer_reordering = ( ms ) [0 ,5 , ... 100 , 110 , 120 , ... ,200]
93 timer_reordering = 35;
94 # timer_reordering = ( ms ) [0 ,5 , ... 250 , 300 , 350 , ... ,500]
95 tim e r _ s t a t u s _ p r o h i b i t = 0;
96 # poll_pdu = [4 , 8 , 16 , 32 , 64 , 128 , 256 , infinity ( >10000) ]
97 poll_pdu = 4;
98 # poll_byte = ( kB )
[25 ,50 ,75 ,100 ,125 ,250 ,375 ,500 ,750 ,1000 ,1250 ,1500 ,2000
99 ,3000 , infinity
100 ( >10000) ]
101 poll_byte = 99999;
102 # max_retx_threshold = [1 , 2 , 3 , 4 , 6 , 8 , 16 , 32]
103 max_ re tx _t hr es ho ld = 4;
104 }
105 # ------- SCTP definitions
106 SCTP :
107 {
108 # Number of streams to use in input / output
109 SCTP_INSTREAMS = 2;
110 SCTP_OUTSTREAMS = 2;
111 };
112 ////////// MME parameters :
113 mme_ip_address = ( { ipv4 = " 192.168.12.62 " ;
114 ipv6 = " 192:168:30::17 " ;
96
115 active = " yes " ;
116 preference = " ipv4 " ;
117 }
118 );
119 NETWORK_INTERFACES :
120 {
121 ENB_INTERFACE_NAME_FOR_S1_MME = " eth0 :1 " ;
122 ENB_IPV4_ADDRESS_FOR_S1_MME = " 192.168.12.82/24 " ;
123 ENB_INTERFACE_NAME_FOR_S1U = " eth0 :1 " ;
124 ENB_IPV4_ADDRESS_FOR_S1U = " 192.168.12.82/24 " ;
125 ENB_PORT_FOR_S1U = 2152; # Spec 2152
126 };
127 rrh_gw_config = (
128 {
129 local_if_name = " lo " ;
130 remote_address = " 127.0.0.2 " ; # local address for
" rcc . band7 . tm1 . if4p5 .25 PRB . lo . conf " file
131 local_address = " 127.0.0.1 " ; # remote address for
" rcc . band7 . tm1 . if4p5 .25 PRB . lo . conf " file
132 local_port = 50000; # for raw option local port must be the same to
remote
133 remote_port = 50000;
134 rrh_gw_active = " yes " ;
135 tr_preference = " udp_if4p5 " ;
136 rf_preference = " usrp_b200 " ;
137 iq_txshift = 4;
138 tx_sample_advance = 80;
139 tx_ sch e d u l i n g _ a d v a n c e = 9;
140 if_compression = " alaw " ;
141 }
142 );
143 log_config :
144 {
145 global_log_level = " info " ;
146 global _ l o g _ v e r b o s i t y = " medium " ;
147 hw_log_level = " info " ;
148 hw_log_verbosity = " medium " ;
149 phy_log_level = " info " ;
150 phy_log_verbosity = " medium " ;
151 mac_log_level = " info " ;
152 mac_log_verbosity = " high " ;
153 rlc_log_level = " info " ;
154 rlc_log_verbosity = " medium " ;
155 pdcp_log_level = " info " ;
156 pdcp_l og_verbosity = " medium " ;
157 rrc_log_level = " info " ;
158 rrc_log_verbosity = " medium " ;
159 };
160 }
161 );
97

OAI Installation Configuration and Scenarios

Transféré par

Informations du document

Description :

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Description :

Droits d'auteur :

Formats disponibles

OAI Installation Configuration and Scenarios

Transféré par

Description :

Droits d'auteur :

Formats disponibles

Chapitre 4

4.1 Environnement de l’OAI

4.2 Composants de l’OAI

• Conforme à la release 8-14 LTE ;

Figure 4.1 – OpenAirInterface LTE software stack

4.3 Comparaison de l’OAI avec d’autres plates-formes

4.4 Evolution de l’OAI vers les axes de recherche 5G

4.5 Installation et configuration de l’OAI

Figure 4.4 – Architecture réseau OAI

Table 4.1 – Caractéristiques techniques des Machines mises en œuvre

Installation du noyau pour e-UTRAN et EPC

1 Sudo apt - get update

Téléchargement des codes sources

1 Sudo apt - get update

1 git clone https :// gitlab . eurecom . fr / oai / op en ai ri nt er fac e5 g . git

1 git clone https :// gitlab . eurecom . fr / oai / openair - cn . git

1 cat / etc / hosts

Installation du module EPC :

1 ./ build_mme -I # éExcuter une seule fois pour installer les

Installation du module UE/eNB

De la même façon, à partir du répertoire ”cmake-targets”, le module UE/eNB est installé

1 sudo mkdir -p / usr / local / etc / oai / freeDiameter

1 gksu gedit / usr / local / etc / oai / mme . conf

1 REALM = " openair4G . eur " ;

1 Identity = \epc . openair4G ."eur ;

• Au niveau du module HSS : de la même façon, le fichier ”hss.conf” est édité en

1 gksu gedit / usr / local / etc / oai / hss . conf

Ensuite, le fichier ”hss fd.conf” correspondant à l’implémentation du protocole DIAMETER

1 Identity = \hss . openair4G ."eur ;

• Au niveau du module SPGW : le fichier ”spgw.conf” implémentant les passerelles

Les configurations à apporter à ce fichier concernent essentiellement le plan d’adressage des

4.6 Compilation et exécution :

1 cd / home / epc / openair - cn / scripts

1 cd / home / epc / openair - cn / scripts

Figure 4.6 – HSS est exécuté avec succès

Figure 4.8 – MME est compilé avec succès

Figure 4.9 – MME est exécuté avec succès

Figure 4.11 – SPGW est exécuté avec succès

Simulations, Résultats et Discussion

5.1 Déploiement du 1er scénario et discussion

1 root@oaisim # cd ~/ OPENAIR_DIR / cmake_targets

1 root@oaisim # cd ~/ OPENAIR_DIR / cmake_targets / tools /

5.1.2 Résultat et discussion :

Figure 5.3 – Attachement avec succès du UE0 au MME

1 [ PHY ][ I ][ UE 0][ RAPROC ] Random - access procedure succeeded .

1 [ RRC ][ I ][ UE 0] : Frame 9 , Logical Channel UL - CCCH ( SRB0 ) ,

• Attach and Authentication : lors de cette phase, L’UE signale la configuration de la

1 [ RRC ][ I ][ UE 0][ RAPROC ] Frame 12 : Logical Channel UL - DCCH ( SRB1 )

1 [ NAS ][ I ]/ home / salaheddine / openair5G / op en ai ri nt er fa ce 5g / openair3 / NAS / UE

Le message ”Attach Request” inclut également le message ”Connectivity Request

1 [ NAS ][ I ]/ home / salaheddine / openair5G / op en ai ri nt er fa ce 5g / openair3 / NAS / UE

1 ALERT S6A 5 G / openair - cn / src / s6a / s6a_task . c :0080 SENT

Le HSS transmet le vecteur d’authentification dans le message ”Authentication Infor-

1 DEBUG S6A openair - cn / src / s6a / s6a_auth_info . c :0217 Received S6A

Le MME transmet les informations nécessaire à l’UE dans le message ”Authentication

1 [ NAS ][ I ]/ home / salaheddine / openair5G / op en ai ri nt er fa ce 5g / openair3 / NAS / UE

Apres la procédure EPS-AKA et à partir de l’authentification mutuelle, l’UE et le MME

1 [ NAS ][ I ]/ home / salaheddine / openair5G / op en ai ri nt er fa ce 5g / openair3 / NAS / UE

1 ALERT S6A 5 G / openair - cn / src / s6a / s6a_task . c :0080 SENT to

1 DBG SENT to ’ epc . openair4G . eur ’: ’ Update - Location - Answer ’ 16777251/316

• Default Radio Bearer Setup : Le MME demande la création de session de données