# R404 TP2 - Attach Rest 404

> Matériel :1 PC, 1 Dongle NEMO Measurement, logiciel NEMO
> Un compte rendu sera donné en fin de TP et une note de 0 est automatiquement attribuée en absence de compte rendu.

Objectifs

- Comprendre la séquence d'échanges de messages lors de la procédure d'attachement LTE.
- Identifier les protocoles et les messages impliqués dans l'attachement.
- Analyser les fonctions et les rôles des différents éléments du réseau LTE.

Matériel requis

- Wireshark pour faire une analyse au niveau du cœur de réseau avec un UE simulé
- Handy Nemo pour l’analyse de signaux radio au niveau de l’UE

## I –Introduction
Dans ce TP, nous allons explorer en détail la procédure d'attachement d'un utilisateur à un réseau LTE (Long Term Evolution). L'attachement est une étape cruciale dans l'accès à un réseau mobile, où un terminal utilisateur (UE) établit une connexion avec le réseau de l'opérateur. Pour cela, nous allons étudier les messages échangés entre l'UE, la station de base (eNodeB) et le cœur de réseau (EPC -Evolved Packet Core).
La procédure d’attachement permet au mobile de s’enregistrer auprès du MME en transmettant son identifiant SIM. Le MME n’est pas en mesure d’authentifier le client, la requête est donc transmise au HSS qui identifie la carte SIM à partir de son identifiant IMSI.
L’authentification est réalisée en calculant le résultat d’une fonction cryptographique à partir d’un aléa RAND de 128 bits et de la clé privé K. Le vecteur d’authentification contient le sceau d’authentification
du réseau et le résultat d’authentification attendu de l’UE.
Cette procédure d’authentification permet pour l’opérateur d’authentifier le client, afin que la facturation soit non contestée. La carte UICC de son côté va identifier le réseau pour que le client évite l’attaque de Man In The Middle.
Pour aller plus loin dans la compréhension de la sécurité des mobiles, vous pouvez lire l’article suivant :
https://blogs.univ-poitiers.fr/f-launay/2021/06/27/la-securite-des-reseaux-mobiles-part-4/

## II – La procédure d’attachement [1,2,3]
#### II-1) Initialisation de l'attachement (Se référer au TP1)
- L'UE se connecte physiquement au réseau en recherchant les signaux de synchronisation PSS/SSS de la station de base (eNodeB) à proximité. L’UE sélectionne une station de base
- L'UE lit les informations systèmes diffusé par l’eNodeB. A partir du SIB2, l’UE récupère les paramètres pour la procédure d’accès aléatoire.

#### II-2) Établissement de la connexion RRC (Radio Resource Control) : Procédure d’accès aléatoire
- L'UE et l'eNodeB échangent des messages pour configurer les ressources radio et établir une connexion RRC.
Lors de la procédure d’accès aléatoire, l’UE envoie un identifiant aléatoire ou son identifiant S-TMSI s’il en possède un. L’identifiant S-TMSI est fourni par le MME lors de l’attachement (après chiffrement de la connexion NAS).
L’identifiant S-TMSI est construit à partir de l’identité du MME (MMEC) et de l’identifiant du mobile M-TMSI au niveau du MME.

#### II-3) Authentification et Sécurité
- L'UE envoie une demande d'attachement (Attach Request) au réseau. La requête NAS est transmise de l’UE (couche NAS) vers le MME (couche NAS). Le message n’est pas chiffré, le mobile fait une demande d’attachement avec le réseau 2G/3G si l’option Combined EPS/IMSI est transmis.
- Le réseau (MME - Mobility Management Entity) traite la demande et initie le processus d'authentification et d'autorisation.

#### II-4) Établissement de la connexion S1AP (S1 Application Protocol)
- Une fois l'authentification réussie, le MME envoie un message à l'eNodeB pour établir la connexion S1AP.

#### II-5) Attachement et Attribution de l'adresse IP
- Le PGW alloue une adresse IP à l’UE et transmet cette adresse au MME.
- Le MME envoie un message de confirmation d'attachement (Attach Accept) contenant les informations de contexte.
- L'UE répond avec un message d'accusé de réception.

#### II-6) Finalisation de l'attachement :
- L'UE reçoit le message d'acceptation et passe à l'état attaché.

## III – Préparation au TP

1) **La procédure d’authentification mutuelle est de type AKA (Authentication and Key Agreement). La procédure est basée sur un challenge ou défi. Quel est le vecteur d’authentification qui est généré par le HSS et quelles sont toutes les clés qui seront calculées au niveau de l’UICC ?**

Les vecteurs d'authentification générés par le HSS sont:

- RAND (Random Number): Un nombre aléatoire généré par le HSS.
- AUTN (Authentication Token): Un jeton d'authentification qui est envoyé à l'UICC (Universal Integrated Circuit Card) pour garantir l'authenticité des données.

Les clés calculées et utilisées par l'UICC sont:

- CK (Cipher Key): Une clé de chiffrement qui sera utilisée pour chiffrer les données entre l'UICC et le réseau.
- IK (Integrity Key): Une clé d'intégrité utilisée pour garantir l'intégrité des données échangées entre l'UICC et le réseau.

2) **A quoi correspond l’IMEI, est ce que l’IMEI est également identifié ?**

L'IMEI (International Mobile Equipment Identity) est un numéro unique attribué à chaque téléphone mobile. Il sert à identifier de manière unique un appareil sur un réseau mobile. L'IMEI est généralement composé de 15 chiffres et est utilisé pour différentes fonctions telles que l'activation de l'appareil sur un réseau, le suivi en cas de vol ou de perte, et la gestion des listes noires d'appareils volés.

3) **La procédure d’attachement pour les smartphones 4G est couplée avec la procédure de connectivité PDN. La connectivité PDN permet l’accès au service Voix Sur IP (si le mobile est compatible au réseau IMS et si l’opérateur a mis en place l’IMS) et Internet. Un bearer est un tunnel IP associé avec une QoS. Que signifie le sigle IMS, à quoi sert l’IMS.**

IMS signifie IP Multimedia Subsystem. Il sert à fournir des services multimédias sur les réseaux IP, notamment la Voix sur IP (VoIP), la messagerie instantanée, la visioconférence, etc.

4) **Auprès de quelle entité le terminal 4G s’enregistre-t’il ?**

Le terminal 4G s'enregistre auprès de l'entité appelée MME (Mobility Management Entity). Le MME est responsable de la gestion de la mobilité des terminaux mobiles LTE (4G) dans le réseau de téléphonie mobile. Lorsque le terminal 4G est allumé ou se déplace dans une nouvelle zone de couverture, il s'authentifie et s'enregistre auprès du MME pour accéder aux services de données et de voix. Le processus d'enregistrement permet au réseau de suivre la localisation du terminal et de maintenir une connectivité transparente lors des déplacements de l'utilisateur.

5) **A quoi correspond le protocole NAS ?**

Le protocole NAS (Non-Access Stratum) est un protocole de signalisation utilisé dans les réseaux mobiles LTE (Long Term Evolution) et 5G. Il fonctionne au-dessus du protocole de liaison radio (RLC, Radio Link Control) et est responsable de la signalisation entre le terminal mobile (comme un smartphone) et le cœur du réseau (le cœur du réseau comprend des éléments tels que le MME, le HSS, etc.).

Le protocole NAS est spécifique au contrôle et à la gestion des sessions de l'utilisateur. Il gère les procédures telles que l'enregistrement de l'utilisateur sur le réseau, l'authentification de l'utilisateur, la gestion de la mobilité, l'établissement et la libération de connexions, la gestion de l'état de la session de données, la gestion de l'identité de l'utilisateur, etc.

6) **A quoi correspond le protocole S1AP ?**

Le protocole S1AP (S1 Application Protocol) est utilisé pour la signalisation entre le cœur du réseau LTE/5G et les stations de base (eNodeB pour LTE, gNB pour 5G) sur l'interface S1.

7) **Comment se nomme le protocole de signalisation entre l’UE et l’eNB**

Le protocole de signalisation entre l'UE (Équipement utilisateur) et l'eNB (Nœud B de station de base) est le protocole RRC (Radio Resource Control).

8) Etudier le call flow suivant : Expliquez chaque ligne. Vous ferez attention à l’état du mobile (RRC_IDLE, RRC_Connected)


1. L'UE fait une demande d'accès aléatoire en envoyant un message *RRCConnectionRequest*.(A ce stade le mobile est en "RRC-Idle")
2. L'eNB lui répond avec un message *RRCConnectionSetup*
3. Un tunnel est donc crée entre l'UE et l'eNB.(Le mobile passe en mode "RRC-Connected")
4. L'UE envoie un message *ATTACH_REQUEST* au MME contenant l'IMSI/GUTI et les capacités du terminal.
5. Un message *RRCConnectionSetupComplete* est envoyé de l'UE à l'eNB. Il contient le payload nécéssaire à l'établissement du NAS.
6. Un message *InitialUEMessage* est envoyé de l'eNB vers le MME via le NAS avec des informations de l'*ATTACH_REQUEST*.
7. Un bearer S1 est créé entre l'eNB et le MME. Le mobile passe alors en mode "ECM-Connected".

9) **A l’issu de cette première phase, le MME (en tant que serveur d’authentification) démarre la procédure d’authentification AKA. Expliquez la procédure. Vous indiquerez notamment la signification des valeurs RAND, AUTN, XRES, KASME et KSI.**

La procédure d'authentification AKA (Authentication and Key Agreement) dans un réseau LTE (ou 5G) est initiée par le MME (Mobility Management Entity), qui agit en tant que serveur d'authentification. Voici les étapes de la procédure, expliquées étape par étape :

- Demande d'authentification du terminal (UE) : Le MME envoie une demande d'authentification au terminal (UE), demandant à l'UE de s'authentifier auprès du réseau.
- Génération de RAND et d'AUTN par le MME : Le MME génère une valeur aléatoire appelée RAND (Random Challenge) et une valeur AUTN (Authentication Token) associée.
- Envoi de RAND et AUTN à l'UE : Le MME envoie la valeur RAND et la valeur AUTN à l'UE.
- Calcul des paramètres par l'UE :
- L'UE utilise la valeur RAND et la clé secrète partagée (Ki) pour calculer plusieurs paramètres :
- XRES (Expected Response) : La réponse attendue, calculée à partir de RAND et Ki.
- KASME (Key for Access Security Management Entity) : Une clé utilisée pour sécuriser les échanges ultérieurs entre l'UE et le réseau.
- KSI (Key Set Identifier) : Un identifiant indiquant quelle clé KASME utiliser pour les échanges ultérieurs.
- Réponse de l'UE : L'UE envoie la valeur XRES calculée au MME.
- Vérification de la réponse par le MME : Le MME vérifie la valeur XRES reçue de l'UE avec celle qu'il a calculée. Si elles correspondent, cela signifie que l'UE est authentique.
- Échange de clés : Si l'authentification est réussie, le MME envoie la clé KASME à l'UE.
- Finalisation de l'authentification : L'UE envoie un message d'acceptation d'authentification au MME, indiquant que l'authentification a été réussie.


10) **Une fois l’étape d’authentification mutuelle passée, le MME génère un identifiant GUTI au mobile. Que signifie le GUTI et en quoi est il nécessaire ? Que signifie l’identifiant GUMMEI et à quoi correspond-il ? Que signifie l’identifiant MMEC et GUMMEI ? A quoi correspond l’identifiant S-TMSI et M-TMSI ? A quoi sert la requête Update Location Request, quelles sont les informations transmises par le HSS au MME ?**

- GUTI (Globally Unique Temporary Identifier) : L'identifiant GUTI est utilisé pour identifier de manière unique un abonné mobile dans le réseau LTE ou 5G. Il est temporaire et est généré par le MME (Mobility Management Entity) après que l'authentification mutuelle entre l'UE et le réseau ait été réalisée avec succès. Le GUTI est utilisé pour protéger la vie privée de l'utilisateur en remplaçant l'identifiant permanent de l'utilisateur, l'IMSI (International Mobile Subscriber Identity), dans les messages échangés entre le terminal mobile et le réseau.
- GUMMEI (Globally Unique MME Identifier) : L'identifiant GUMMEI est une identité globalement unique associée à un MME spécifique (Mobility Management Entity) dans le réseau LTE ou 5G. Il est composé de l'identifiant PLMN (Public Land Mobile Network) de l'opérateur mobile et de l'identifiant MME.
- MMEC (MME Code) : L'identifiant MMEC est un identifiant unique attribué à chaque MME dans le réseau LTE ou 5G. Il est utilisé pour identifier de manière unique un MME spécifique.
- S-TMSI (S-Temporary Mobile Subscriber Identity) et M-TMSI (M-Temporary Mobile Subscriber Identity) : Ce sont des identifiants temporaires utilisés dans le processus de gestion de la mobilité pour suivre un abonné mobile dans le réseau. S-TMSI est utilisé par le réseau côté station de base (eNodeB en LTE) pour identifier un abonné, tandis que M-TMSI est utilisé par le réseau cœur (comme le MME) pour identifier un abonné.
- Requête Update Location Request (ULR) : C'est une requête envoyée par le MME au HSS (Home Subscriber Server) pour obtenir les informations de localisation de l'abonné mobile, notamment pour mettre à jour les informations de mobilité de l'abonné dans le HSS. Les informations transmises par le HSS au MME dans la réponse à cette requête peuvent inclure des informations telles que l'abonné est en itinérance, l'état de l'abonnement, les clés de sécurité, etc.


11) Etudier le call flow suivant


Procédure d'accès aléatoire:
1. L'UE fait une demande d'accès aléatoire en envoyant un préambule.
2. Un eNB lui renvoie une réponse.
3. L'UE envoie un message RRC Connection Request à l'eNB

Connection RRC:
4. L'eNB renvoie un message RRC Connection Setup
5. L'UE envoie un message RRC Connection Setup Complete et fait une demande d'attachement NAS

Authentification:
6. l'eNB envoie un message S1AP Initial Ue Message contenant l'Attach Request de l'UE/
7. Une procédure d'identification est effectuée entre le nouveau MME et l'ancien MME.
8. UN procédure d'authentification est effectuée entre le nouveau MME et l'HSS
9. Une demande d'option est envoyée à l'UE.
10. La réponse est utilisée et une demande de changement de localisation est demandée par le nouveau MME vers l'HSS.
11. L'HSS annule la localisation dans l'ancien MME.
12. L'HHS envoie une réponse de localisation au nouveau MME.

12) **Dessiner les couches protocolaires de l’UE, de l’eNB et du MME**


13) **La 5G NSA permet au mobile d’être connecté au MME via l’eNB et d’activer simultanément une double connexion DC sur le réseau 5G (DC NR).**
*Pour avoir accès à la 5G actuellement (5G NSA option 3), le terminal doit supporter la 5G, la station de base doit supporter la double connexion et le client doit avoir un forfait 5G.*
**Faites un schéma de l’architecture réseau 5G NSA.**


## IV - Travaux Pratiques : Call Flow via NEMO

### 4-a) Prise en main rapide de NEMO

Vous allez utiliser l’outil de trace NEMO pour étudier le réseau 4G. L’analyse porte sur une trace pré-
enregistrée.
- Vérifier la présence du Dongle pour déverrouiller le logiciel
- Lancer l’utilitaire : NEMO
- Récupérer le fichier TP1_Avion_Off_On.nmfs
- Clliquez sur l’image de la station de base, Sélectionner « Open Measurement » ,sélectionnez le fichier précédent.
- Choisir le workspace LTE Full Detail


La fenêtre de travail qui s’ouvre est composée de plusieurs sous-fenêtres et plusieurs onglets.
L’onglet par défaut est « Serving Cell Measurements », et la fenêtre principale « Line Graph » présente les niveaux de puissance mesurés par le mobile en fonction du temps.
Appuyez sur le bouton Play pour faire défiler les mesures. Nous allons maintenant noter les valeurs.
Modifier le zoom de la fenêtre d’analyse graphique (Line Graph) et déplacer le curseur rouge pour récupérer les mesures


### 4-b) Travail à réaliser

Nous allons nous intéresser à la procédure d’attachement. Le mobile a sélectionné la station de base et doit s’enregistrer sur le cœur de réseau pour pouvoir profiter des services d’appels ou de session IP.
Dans le call flow, la couche NAS du mobile envoie des informations à la couche AS qui sont transmises sur la couche radio. La demande d’attachement ( NAS Attach request) provoque une demande de connexion radio avant de transmettre la requête NAS sur la couche RRC.

#### HANDY NEMO

14) **Repérez les requêtes finalisant la demande d’accès aléatoire (procédure RACH). A quelle heure ont-elles lieu ? Quel est le numéro SRB créée par l’eNB. La signalisation est-elle en mode acquittée ou non acquittée ? La valeur du S-TMSI est transmise lors de la 1ère requête, que vaut elle ?**

`Open > Event Grid > Layer 3 / RRC Messages`

Dans le call flow, la demande RACH a eu lieu à 14h13.
La valeur du S-TMSI est transmise dès le RRCConnexionRequest et sa valeur est 88.

La capture de la dernière requête:


Le numéro SRB est 1.


La connexion est acquittée car le message porte le mot AM. Le mot UM permet de dire que la connexion est en mode non connectée.


15) **Quelle est la requête RRC qui porte (encapsule) le message *NAS ATTACH_REQUEST* ? Connaît-on la valeur de l’IMSI ? Si oui quelle est elle ? Si non pourquoi et quel identifiant est transmis ? A quoi correspond cet identifiant et que vaut il ? Le message est il chiffré ? Si non que contient le message *dedicatedInfoNas* ?**

La requête qui porte le message *NAS_ATTACH_REQUEST* est *RRCConnexionSetupComplete*.


La valeur de l'IMSI n'est pas connu dans cette capture de trame, nous utilisons donc l'identifiant GUTI. Il correspond à la concaténation du MMC/MNC/MME Group ID/MME Code/M-TMSI


Le message n'est pas chiffré, il est indiqué *not security protected*.

Le message *dedicatedInfoNas* contient un payload qui est transmis à l'UE dès l'*ATTACH_REQUEST*. L'UE ne fait que renvoyer le message NAS encapsulé dans un message RRC.

16) **Le message NAS ATTACH_REQUEST est transmis au niveau de la couche NAS vers la couche RRC.**
*A partir de ce message, répondez aux questions suivantes (certaines réponses peuvent être redondante avec la question 14)
Le message NAS est il protégé ?*

Non il n'est pas chiffré tout est directement encapsulé et stocké dans le champ *dedicatedInfoNas*.

**L’attachement est il combiné avec un attachement du MSC ?**


Le MSC est supporté. Le MME attache l'UE au MSC en cas de perte de connexion avec celui-ci

**Que vaut l’identifiant IMSI ou GUTI ? Sur quel opérateur le mobile était-il attaché ?**

M Old GUTI or IMSI (hex data: 0bf602f8 0180e988 d12381e9)
	Type of identity: GUTI
	Odd/even indication: even number of identity digits and also when the GUTI is used
	MCC: 208
	MNC: 10
	MME Group ID: 0x80e9
	MME Code: 0x88
	M-TMSI: 0xd12381e9
M UE network capability (hex data: 07f070c0 40190090)

La valeutr du GUTI est la concatenation des éléments sous GUTI. L'opérateur est SFR d'après https://fr.wikipedia.org/wiki/Mobile_Network_Code

**Le mode DCNR (Dual Connectivity New Radio) est il supporté ?**

Oui il l'est


**Quels sont les algorithmes de sécurité supportés pour l’intégrité et pour le chiffrement sur le coeur de réseau 4G ?**

Les protocoles ayant la charge de l'intégrité et du chiffrement (EPS/UMTS/EEA/EIA/UEA/UIA).
Pour la 4G (EPS - Evolved Packet System), les algorithmes supportés sont EEA0, 128-EIA1, 128-EIA2 et 128-EIA3

M UE network capability (hex data: 07f070c0 40190090)
	EPS encryption algorithms supported
		EEA0: supported
		128-EEA1: supported
		128-EEA2: supported
		128-EEA3: supported
		EEA4: not supported
		EEA5: not supported
		EEA6: not supported
		EEA7: not supported
	EPS integrity algorithms supported
		EIA0: not supported
		128-EIA1: supported
		128-EIA2: supported
		128-EIA3: supported
		EIA4: not supported
		EIA5: not supported
		EIA6: not supported
		EIA7: not supported
	UMTS encryption algorithms supported
		UEA0: supported
		UEA1: supported
		UEA2: not supported
		UEA3: not supported
		UEA4: not supported
		UEA5: not supported
		UEA6: not supported
		UEA7: not supported
	UCS2 support: The UE has a preference for the default alphabet over UCS2
	UMTS integrity algorithms supported
		UIA1: supported
		UIA2: not supported
		UIA3: not supported
		UIA4: not supported
		UIA5: not supported
		UIA6: not supported
		UIA7: not supported

17) **Que contient le message *AUTHENTICATION_REQUEST* : Donner les noms et les valeurs des deux paramètres du vecteur d’authentification.**

Le message contient le type de sécurité utilisé et les paramètres RAND & AUTN. Il est envoyé par le MME.

- RAND: 9072 5016 dd87 8ab6 de96 ed6d c086 30e1
- AUTN: 6dc6 6a47 873d 8000 6d6f e2ae 101c d93a

AUTHENTICATION REQUEST		3GPP TS 24.301 ver 15.4.0 Rel 15    (8.2.7)

M Protocol Discriminator (hex data: 7)
	(0x7) EPS mobility management messages
M Security header type (hex data: 0)
	Security header type value: Plain NAS message, not security protected
M Message Type (hex data: 52)
	Message number: 82
M NAS key set identifier_ASME (hex data: 1)
	TSC: native security context
	NAS key set identifier: 1
M Spare Half Octet (hex data: 0)
M Authentication parameter RAND (EPS challenge) (hex data: 90725016 dd878ab6 de96ed6d c08630e1)
	Authentication parameter RAND (hex):  9072 5016 dd87 8ab6 de96 ed6d c086 30e1
M Authentication parameter AUTN (EPS challenge) (hex data: 106dc66a 47873d80 006d6fe2 ae101cd9 3a)
	Authentication parameter AUTN (hex):  6dc6 6a47 873d 8000 6d6f e2ae 101c d93a

Layer 3 data:
	07 52 01 90 72 50 16 dd 87 8a 
	b6 de 96 ed 6d c0 86 30 e1 10 
	6d c6 6a 47 87 3d 80 00 6d 6f 
	e2 ae 10 1c d9 3a 

18) **Que contient le message *AUTHENTICATION_RESPONSE* : Donner le nom et sa valeur**

Le message *AUTHENTICATION_RESPONSE* contient le hash de la réponse envoyé par l'UE.
- RES: 0x084c6985d6ad1337

AUTHENTICATION RESPONSE		3GPP TS 24.301 ver 15.4.0 Rel 15    (8.2.8)

M Protocol Discriminator (hex data: 7)
	(0x7) EPS mobility management messages
M Security header type (hex data: 0)
	Security header type value: Plain NAS message, not security protected
M Message Type (hex data: 53)
	Message number: 83
M Authentication response parameter (hex data: 08084c69 85d6ad13 37)
	RES: 0x084c6985d6ad1337

Layer 3 data:
	07 53 08 08 4c 69 85 d6 ad 13 
	37 

19) **Que contient le message *SECURITY_MODE_COMMAND*, quel est son utilité ?**

Le message *SECURITY_MODE_COMMAND* contient la liste de tous les protocoles/algortimes de chiffrement supportés.

Le SMC est utilisé pour déclencher les procédures d'authentification et d'échange de clés entre l'UE et le réseau. Ces procédures garantissent que l'UE se connecte à un réseau légitime et établissent des clés de chiffrement partagées qui seront utilisées pour sécuriser le trafic de données.

LAYER 3 SIGNALING MESSAGE 
Time: 14:12:49.887 

SECURITY MODE COMMAND		3GPP TS 24.301 ver 15.4.0 Rel 15    (8.2.20)

M Protocol Discriminator (hex data: 7)
	(0x7) EPS mobility management messages
M Security header type (hex data: 0)
	Security header type value: Plain NAS message, not security protected
M Message Type (hex data: 5d)
	Message number: 93
M Selected NAS security algorithms (hex data: 22)
	Type of integrity protection algorithm: EPS integrity algorithm 128-EIA2
	Type of ciphering algorithm: EPS encryption algorithm 128-EEA2
M NAS key set identifier (hex data: 1)
	TSC: native security context
	NAS key set identifier: 1
M Spare Half Octet (hex data: 0)
M Replayed UE security capabilities (hex data: 05f070c0 4010)
	EPS encryption algorithms supported
		EEA0: supported
		128-EEA1: supported
		128-EEA2: supported
		128-EEA3: supported
		EEA4: not supported
		EEA5: not supported
		EEA6: not supported
		EEA7: not supported
	EPS integrity algorithms supported
		EIA0: not supported
		128-EIA1: supported
		128-EIA2: supported
		128-EIA3: supported
		EIA4: not supported
		EIA5: not supported
		EIA6: not supported
		EIA7: not supported
	UMTS encryption algorithms supported
		UEA0: supported
		UEA1: supported
		UEA2: not supported
		UEA3: not supported
		UEA4: not supported
		UEA5: not supported
		UEA6: not supported
		UEA7: not supported
	UMTS integrity algorithms supported
		UIA1: supported
		UIA2: not supported
		UIA3: not supported
		UIA4: not supported
		UIA5: not supported
		UIA6: not supported
		UIA7: not supported
	GPRS encryption algorithms supported
		GEA1: not supported
		GEA2: not supported
		GEA3: supported
		GEA4: not supported
		GEA5: not supported
		GEA6: not supported
		GEA7: not supported
O IMEISV Request (hex data: c1)
	IMEISV request value: IMEISV requested
O Replayed UE additional security capability (hex data: 6f04f000 7000)
	5GS encryption algorithms supported:
		5G-EA0
		128-5G-EA1
		128-5G-EA2
		128-5G-EA3
	5GS integrity algorithms supported:
		128-5G-IA1
		128-5G-IA2
		128-5G-IA3

Layer 3 data:
	07 5d 22 01 05 f0 70 c0 40 10 
	c1 6f 04 f0 00 70 00 

20) **Quel est l’algorithme de chiffrement et d’intégrité NAS choisi ?**

L'algorithme de chiffrement et d’intégrité NAS choisi se trouve dans le message *SEURITY_MODE_COMMAND*.
- Chiffrement: 128-EEA2
- Intégrité: 128-EIA2

Selected NAS security algorithms (hex data: 22)
	Type of integrity protection algorithm: EPS integrity algorithm 128-EIA2
	Type of ciphering algorithm: EPS encryption algorithm 128-EEA2

21) **Quelles sont les capacités du terminal ? Sur quelles bandes de fréquences fonctionne t’il ? Sur combien de bandes en DL et en UP peut il réaliser de l’agrégation de porteuses ?**

Les capacités du terminal sont indiqués dans le message *UECapabilityEnquiry*.

Les capacités du terminal sont eutra, utra, geran-cs (4G/3G/2G).
Il fonctionne sur les bandes de fréquence 1, 3, 7, 20, 28.
Le nombre de bandes d'aggrégation de porteuses est réalisé en:
- UL: 2
- DL: 5

RRC SIGNALING MESSAGE 
Time: 14:12:50.087 

UECapabilityEnquiry	(3GPP TS 36.331 ver 16.6.0 Rel 16)

DL-DCCH-Message	
  message	
    c1	
      ueCapabilityEnquiry	
        rrc-TransactionIdentifier	: 2
        criticalExtensions	
          c1	
            ueCapabilityEnquiry-r8	
              ue-CapabilityRequest	
                ue-CapabilityRequest value	: eutra, utra, geran-cs
              nonCriticalExtension	
                nonCriticalExtension	
                  requestedFrequencyBands-r11	
                    requestedFrequencyBands-r11 value	: 1, 3, 7, 20, 28
                  nonCriticalExtension	
                    requestedMaxCCsDL-r13	: 5
                    requestedMaxCCsUL-r13	: 2
                    nonCriticalExtension	
                      nonCriticalExtension	
                        requestedFreqBandsNR-MRDC-r15	
                          FreqBandList	
                            FreqBandList value 1	
                              bandInformationEUTRA	
                                bandEUTRA	: 1
                            FreqBandList value 2	
                              bandInformationEUTRA	
                                bandEUTRA	: 3
                            FreqBandList value 3	
                              bandInformationEUTRA	
                                bandEUTRA	: 7
                            FreqBandList value 4	
                              bandInformationEUTRA	
                                bandEUTRA	: 20
                            FreqBandList value 5	
                              bandInformationEUTRA	
                                bandEUTRA	: 28
                            FreqBandList value 6	
                              bandInformationNR	
                                bandNR	: 78

Data (hex):
        3C 28 04 9D 00 00 81 84 C6 CD
        18 18 2C 02 80 00 04 01 80 98
        1B 80 9A 00

22) **La demande d’attachement aboutit elle ? Sur quel TAC est le mobile ? A quoi correspond le timer T3412, quelle est sa valeur ? Quel est le nom de point de domaine APN ?**

Le message *ATTACH_ACCEPT* permet de dire que la demande d'attachement a aboutit. Le Tracking Area Code (TAC) est disponible dans le message SIB1.

- TAC: 46506

Ou également dans un ATTACH_ACCEPT:

ATTACH ACCEPT		3GPP TS 24.301 ver 15.4.0 Rel 15    (8.2.1)

M Protocol Discriminator (hex data: 7)
	(0x7) EPS mobility management messages
M Security header type (hex data: 0)
	Security header type value: Plain NAS message, not security protected
M Message Type (hex data: 42)
	Message number: 66
M EPS attach result (hex data: 2)
	EPS attach result value: combined EPS/IMSI attach
M Spare Half Octet (hex data: 0)
M T3412 value (hex data: 5e)
	Unit: value is incremented in multiples of decihours
	Timer value: 30
M TAI list (hex data: 062002f8 01b5aa)
	Partial tracking area identity list 1:
		Type of list: list of TACs belonging to one PLMN, with consecutive TAC values
		Number of elements: 1
		MCC: 208
		MNC: 10
		TAC 1: 46506 (0xb5aa)

Le nom du point d'accès (APN), est disponible dans le message *PDN_CONNECTIVITY_REQUEST*.
> Access point name

PDN CONNECTIVITY REQUEST		3GPP TS 24.301 ver 15.4.0 Rel 15    (8.3.20)

M Protocol Discriminator (hex data: 2)
	(0x2) EPS session management message
M EPS bearer identity (hex data: 0)
	EPS bearer identity value: No EPS bearer identity assigned
M Procedure transaction identity (hex data: 06)
	Procedure transaction identity: 6
M Message Type (hex data: d0)
	Message number: 208
M Request type (hex data: 1)
	Request type value: initial request
M PDN type (hex data: 3)
	PDN type value:IPv4v6
O Access point name (hex data: 28040369 6d73)
	Access point name: ims

23) Le mobile fait-il une demande de désenregistrement ?

Le mobile fait un demande de désenregistrement via le message *DETACH_REQUEST*.

DETACH REQUEST		3GPP TS 24.301 ver 15.4.0 Rel 15    (8.2.11.1)

M Protocol Discriminator (hex data: 7)
	(0x7) EPS mobility management messages
M Security header type (hex data: 0)
	Security header type value: Plain NAS message, not security protected
M Message Type (hex data: 45)
	Message number: 69
M Detach type (hex data: b)
	Switch off: switch off
	Type of detach: combined EPS/IMSI detach
M NAS key set identifier (hex data: 1)
	TSC: native security context
	NAS key set identifier: 1
M EPS mobile identity (hex data: 0bf602f8 0180e988 d12381e9)
	Type of identity: GUTI
	Odd/even indication: even number of identity digits and also when the GUTI is used
	MCC: 208
	MNC: 10
	MME Group ID: 0x80e9
	MME Code: 0x88
	M-TMSI: 0xd12381e9

Layer 3 data:
	07 45 1b 0b f6 02 f8 01 80 e9 
	88 d1 23 81 e9 

## WIRESHARK - A Faire chez vous.

Nous allons maintenant étudier une capture wireshark dans le cœur de réseau.
Lancez Wireshark et récupérer la fichier TP2_Xav_Lag.ncap
Dessinez un call-flow allant de la requête 1 jusqu’à la requête 35.

Pour faire le call flow, je vous recommande de lire la page web suivante :
https://blogs.univ-poitiers.fr/f-launay/2023/03/21/les-supports-de-signalisation-srb-signaling-radio-bearer/

Dans cet article du blog, vous trouverez ainsi les messages RRC qui portent ou non une requête NAS.
Les questions

24) Quel est l’identité GUTI du mobile ?

25) Quelle est la valeur du nouveau TAI ?

26) Quelle est la valeur de l’ancien LAI ?

27) A quoi correspond le paramètre DRX ? Est il activé ?

28) Quel est la liste des Codecs Supportés en mode CS ?

29) Le mobile préfère t’il établir un appel en mode CS ou PS ?

30) QUel est le numéro IMEISV ? A quoi cela correspond-il ?

31) Quel est le numéro M-TMSI/P-TMSI :

32) Quelles valeurs AMBR est autorisées en UL et DL

33) Donner le nom de l’APN

34) Quelle est la valeur du QCI

35) Quelle est le debit montant et descendant maximal total

36) Quelle est l’adresse IPv4 du serveur DNS
Références
[1] TS 24.301
https://www.etsi.org/deliver/etsi_ts/124300_124399/124301/13.11.00_60/ts_124301v131100p.pdf
[2] https://blogs.univ-poitiers.fr/f-launay/2015/05/19/emm-procedure-initial-attach-part-1/
[3] https://blogs.univ-poitiers.fr/f-launay/2015/05/19/emm-procedure-initial-attach-part-2/
[4] https://nutaq.com/testing-cellular-performance/