# ARM - TP2

###### tags : `ARM` `TP`

https://docs.google.com/document/d/17uLFZbazrqioklafdBQI5e4U0-V4CZEn/edit#heading=h.gjdgxs

## Section 1 : appel 3G

### 1.1 - Quel protocole NAS transmet le message CM Service Request ? Quel service est demandé par le mobile dans ce message ?

On utilise le protocole MM (Mobility Management) qui gère l'itinérance (localisation, authentification, et allocation du TMSI).

Le mobile demande le service call establishment afin de passer un appel téléphonique :


### 1.2 - Quel algorithme de chiffrement est connu par le mobile ?

L'algorithme A5/1 est connu par le mobile, c'est le seul pris en charge ici.

### 1.3 - A quoi sert, selon vous, le message RANAP Common ID, transmis par le MSC au RNC ?

CommonID est envoyé depuis le réseau cœur au RNC : il permet de transporter l’identité de l’utilisateur.
1) L’UE a dû mettre en place sa demande de ressource dédiée (UE<>RNC) 🡪 connexion RRC
L’utilisateur a fait sa demande de ressource dédié avec le C-RNTI 🡪 Il est connu comme l’utilisateur RNTI.
2) Le trafic arrive du cœur de réseau, le NAS va dire au RNC qu’il souhaite communiquer avec l’utilisateur IMSI.
Cela permettra au RNC de coller l’identité IMSI sur la connexion RRC et faire le lien RNTI<>IMSI.

### 1.4 - Pourquoi, alors que les messages sont chiffrés, on les voit en clair dans Wireshark ?

On étudie ici les messages échangés dans le coeur de réseau UMTS. Or, seul le réseau d'accès est chiffré dans cette norme. On voit donc en clair les messages.

### 1.5 - Que pouvez-vous dire de l'IMSI ?

Identifiants utilisateurs dans la SIM : IMSI (interne opérateur) & MSISDN (externe opérateur)
L’IMSI permettra :
- La mise en place des procédures de sécurité
- La mobilité
- La vérification des services… etc.

### 1.6 - Pourquoi utilise-t’on l’IMSI dans ces messages du CN et non pas le TMSI ?

- TMSI = identité temporaire et local à une région => connu du VLR.
- IMSI = identité permanente => connu du MSC et HLR (le MSC ne connaît pas le TMSI)

Après attachement (ou on voit l’IMSI pour la première et dernière fois) toutes les communications sur le réseau d’accès sont chiffrées alors il n’y a plus de problème pour transférer l’IMSI de l’UE au réseau cœur. Les communications entre RNC et le réseau cœur ne sont pas chiffrées et sont considérées « peu » sensibles aux attaques.
L’IMSI permettra également de retrouver l’UE s’il y a eu déconnexion ou mobilité.

### 1.7 - Quel protocole NAS génère le DirectTransfer (DTAP) (CC) Setup ?

Il s'agit du Call Control (CC). Cela permet d'initier l'appel vers le destinataire avec des informations importantes comme le codec utilisé pour la communication, et initiera une demande de bearer.

Un radio Bearer sert à établir un lien point à point. Il est nécessaire pour spécifier la configuration de la couche 2 et de la couche physique du lien (https://en.wikipedia.org/wiki/Radio_Bearer_in_UMTS).

### 1.8 - Quel est le numéro appelé par le mobile ? (Attention, dans notre cas il ne s’agit pas d’un vrai numéro de mobile car c’est un scénario de test sur une plateforme d’expérimentation)

Le numéro appelé ici est le 5.

### 1.9 - Quels sont les codecs supportés par l'UE ?

Les codecs supportés par l'UE sont le GSM EFR et UMTS AMR-WB.

### 1.10 - Quel est le rôle du message RAB-AssignmentRequest transmis par le MSC ?

Lors de la mise en place de l’appel utilisation un bearer par défaut est attribué. Le bearer par défaut n’aura pas la QoS nécessaire pour la voix.
RAB-AssignmentRequest : Radio Access Bearer va spécifier les paramètres de qualité de service.

### 1.11 - Le MSC répond au message DirectTransfer DTAP (CC) Setup par un message DirectTransfer DTAP (CC) Call Proceeding. Quel est le rôle de ce message ?

Se fera une fois qu’on a atteint l’opérateur.
Servira à signaler à l’UE que la demande d'appel a été reçu par le réseau et qu'il fait ce qu’il faut pour contacter l’autre bout.
Défini avant le RAB pour que le RAB adapte les bearer côté appelé.

### 1.12 - Le message suivant est DirectTransfer DTAP (CC) Alerting. Quel est le rôle de ce message envoyé à l’UE ?

MSC => RNC : permettra de faire le relais et avertir l’appelant que la personne qu’il essaie de joindre est en train d’être avertie (en gros son téléphone sonne, et on entend la tonalité côté appelant).

### 1.13 - Quel message indique que l'appelé a décroché ?

DTAP CC Connect

### 1.14 - Comment est encapsulé l'appel téléphonique, par quel ensemble de protocoles ?

RTP protocol : Real Time Transport Protocol est un traffic temps réel au-dessus de UDP (sur IP).
Sa mise en place commence avant, donc on voit des messages avant le CC Connect 🡪 la réservation de ressources prend du temps et il faut l’effectuer en parallèle afin de ne pas perdre des paquets une fois que l’appelé à décroché.

### 1.15 - A la fin de l’appel, après avoir arrêté la connexion CC (DirectTransfer DTAP (CC) Release Complete), on voit aussi un message Iu Release Command. A quoi sert ce message ?

Libération de la session de communication entre réseau cœur et réseau d’accès. Concerne IuCS car l’appel UMTS se fait dans le domaine circuit (IuPS – paquet n’est pas concerné).

### 1.16 - Après le paging, l’appelé reçoit un message DirectTransfer (DTAP) (CC) Setup ? Est-ce le même message DirectTransfer (DTAP) (CC) Setup transmis par l’appelant ?

Oui, il reçoit un message DTAP CC Setup, mais son contenu est différent de celui transmis par l'appelant (codec, numéro de téléphone...).

### 1.17 - On observe également un message DirectTransfer (DTAP) (CC) Alerting du côté de l’appelé. Quel est le rôle de ce message dans ce cas ? Est-ce qu’il précède ou il succède au message DirectTransfer (DTAP) (CC) Alerting que nous avons vu côté appelant ?

Il informe l’UE appelé qu’il y a communication entrante. Il précède celui côté appelant.

### 1.18 - Lorsque nous avons étudié la trace originating call précédemment, nous avons vu que les codecs supportés par le terminal appelant étaient listés. Dans quel message l’UE appelé annonce-t’il la liste de ses codecs disponibles ?

DTAP CC Call Confirmed

### 1.19 - Quelle est la signification du message DirectTransfer (DTAP) (CC) Release par rapport au message DirectTransfer (DTAP) (CC) Release Complete ?

DTAP Release se fait du RNC au MSC pour annoncer qu’il faut mettre fin à l’appel (en gros le gars à cliqué sur raccrocher).
DTAP Release Complete indique au RNC (depuis le MSC) qu’il a bien mis fin (l'autre pelo a ack le fait qu'il s'est fait raccroché au nez). Suite à ça les bearer radio sont libérés.

## Section 2 : Appel 4G VoIP

### 2.1 - On observe les mêmes messages d’attachement que lors du premier TP. La seule exception sont les messages DownlinkNASTransport, ESM information request et UplinkNASTransport, ESM information response qui apparaissent en plus. Pourquoi le MME envoie-t’il cette demande ?

ESM (Evolved Packet System Session Management / Packet Data Network Connection) est en charge de la connexion IP entre l’UE et le EPS.
- Sélection du EPS approprié pour apporter le service demandé par l’utilisateur
- Attribue une @IP
- Applique les règles QoS
- Créé un default EPS bearer

### 2.2 - On utilise deux protocoles différents au niveau de l’appel : un pour la signalisation, l’autre pour transporter la voix. Quels sont ces protocoles ?

- GTP : General Packet Radio Service Tunnelling Protocol S-GW<>P-GW encapsule la signa + le transport

- SIP : Session Initiation Protocol est un protocole de signalisation encapsulé dans UDP.
The Session Initiation Protocol (SIP) is a signaling protocol used for initiating, maintaining, and terminating real-time sessions that include voice, video and messaging applications. ... The protocol defines the specific format of messages exchanged and the sequence of communications for cooperation of the participants.

- UDP : User Datagram Protocol permettra le transfert des données.
The User Datagram Protocol (UDP) is a lightweight data transport protocol that works on top of IP. UDP provides a mechanism to detect corrupt data in packets, but it does not attempt to solve other problems that arise with packets, such as lost or out of order packets.

## Section 3 : Handover 4G inter-MME

### 3.1 - Quelle est la raison d'exécution de ce handover ?

"radio-reason" : soit mauvaise qualité de réception, ou qualité de service réseau trop mauvaise.

### 3.2 - Combien de temps dure l'exécution du handover ?

- HandoverRequires : 39.567060
- Handover Notify : 39.664173
- UEContexteReleaseCommand [RadioNetwork ..] : 39.664328
Durée 🡪 39.664328 - 39.567060 = 0,097268 s soit 97.3ms

### 3.3 - Quelles sont les adresses IP des eNodeBs et des MMEs impliqués ?

- eNodeB_1 : 10.200.10.37
- eNodeB_2 : 10.200.10.38
- MME_1 : 10.200.10.254
- MME_2 : 10.200.10.253

### 3.4 - Sur quelle interface circule cette demande de handover ?

S1 : handover inter-MME
L’UE va collecter des informations au sujet des eNodeB environants lors de son traffic et ensuite mesurer ce dont il a besoin. Les mesures seront ensuite remontées depuis les équipements utilisateurs jusqu'au eNodeB. À partir de là il y aura un dialogue sur les interfaces X2 (entre eNodeBs) pour la mise en place du handover.
Le dialogue sur l'interface X2 entre les différents eNB afin de préparer le handover se fait de manière transparente. Cela permet une accélération du handover.

### 3.5 - Quelles sont les Id. de la cellule source et de la cellule destination du handover ?

Cellule source : 0x101 & Cellule destination : 0x201
Information disponible dans le paquet "handover required".

### 3.6 - Quelles sont les ressources transférées entre les MMEs ?

Ce à quoi servira le MME :
- Mobility Managment Entity va se charger de l’authentification
- Fais la mise à jour du « tracking area ».
- Permet de gérer le mode « idle » et l’accessibilité de l’UE.
- Va permettre la sélection de S-GW (serving gateway, passerelle entre les enodeb et le pgw, joue le rôle de passerelle régionale) et P-GW (packet gateway, passerelle entre internet et le réseau opérateur mobile).
- Va permettre le management de fonctions bearer – établissement, maintenance et release.

Les bearers seront les ressources transférées entre les MME pour conserver la connectivité.

### 3.7 - L’interface radio étant chiffrée, que se passe-t’il lors du handover : une nouvelle clef de chiffrement/déchiffrement est-elle calculée ou la clef actuelle est-elle transférée ?

La clé de chiffrement est transférée via l'interface X2.