# ARM - TP1 ###### tags : `ARM` `TP` ## Scénario 1 : Attachement au réseau ### *1.1 Quel est l'objectif de la procédure d'attachement ?* L'attachement permet à un terminal mobile (UE) de pouvoir se connecter au réseau mobile (il était alors déconnecté jusqu'à présent de toute cellule). Il doit alors s'enregistrer auprès de la station de base (eNodeB), mais aussi auprès de l'opérateur (EPC). ### *1.2 Le premier échange à observer, très rare dans la vraie vie, a lieu entre le eNodeB et l'EPC. C'est quoi l'interface S1 ? Quand est-ce que ces messages de mise en place d'interface sont échangés dans la vraie vie ?* L'interface S1 est l'interface entre la station de base et le coeur de réseau de l'opérateur. Ces messages sont échangés pour établir la connection entre les deux entités suite à un redémarrage par exemple, mais cela reste rare (car si on a ces message, cela signifie que la station de base n'était pas fonctionnelle). Les deux messages qu'on trouve du côté de l'EPC : - S1SetupRequest - S1SetupResponse ### *1.3 On passe maintenant du côté de l'UE. Les trois premiers messages qui apparaissent sont de type MIB et SIB. Quelles sont les différences entre ces 3 messages ? Sur quels canaux logiques sont-ils transmis ?* - MIB : Master Information Block sur BCH (BCCH_BCH) - SIB : System Information Block sur SCH (DL_SCH) Le 1er message (MIB) indique la bande de fréquence à utiliser (ici la n50). Le 2nd (SIB) indique le MCC et le MNC ainsi que le Location Area Code et l'Id de la station de base + la puissance limite pour le handover, de manière générale des informations sur l'opérateur. Le 3e (SIB) donne des informations sur chaque canal logique pour que le téléphone puisse se synchroniser, de manière générale des informations sur la station de base. ### *1.4 Le premier message MAC visible dans la trace est le message RAR. Ce message fait partie d'une série d'échanges entre l'UE et l'eNodeB. Comment appelle-t-on ces échanges ? Quels sont les autres messages ? Si certains ne sont pas visibles, pourquoi ?* Ces échanges constituent la procédure RACH. Message **RAR** (Random Access Response) : Contient : + TA : Timing Alignment + UL-grant : UpLink grant + RAPID : Random Access Preamble Identifier Messages autre que MAC/RRC non loggés : Préambule (UE -> BS) : Messages de la couche physique non visibles dans Wireshark Message RAR (BS -> UE) Message 3 (UE -> BS): RRC Connection Request Message 4 (BS -> UE): RRC Connection Setup : message de niveau MAC (UE Contention Resolution, fin procédure RACH) et en même temps réponse au niveau RRC. ### *1.5 Dans quelle zone de localisation se trouve l’utilisateur mobile ? Quel est le code de son opérateur ? Quel est son code pays ?* Dans le paquet SIB1: MNC = 001 MCC = 01 Zone de localisation = 0007 ### *1.6 Combien de préambules sont disponibles dans la cellule pour la procédure Random Access ?* Il y a 52 préambules RA disponibles (message SIB2). ### *1.7 Dans le message RAR, il y a deux identifiants RNTI. Quelles sont leurs valeurs ? Quelle est la différence entre les deux ?* RA-RNTI = 2 C-RNTI = 74 La différence entre les deux : 1 sert pour l'établissement du Random Access (cet id peut être commun à plusieurs utilisateurs) l'autre pour la cellule (identifiant du eNodeB), unique pour l'utilisateur sur le eNodeB. ### *1.8 A quoi sert le champ Timing Advance dans le message RAR ?* Ce champ sert à synchroniser en temps la connexion entre l'UE et la station de base (le timing advance spécifie le décallage en temps dans le slot). ### *1.9 Dans le message RRC Connection Request, deux identifiants sont utilisés pour l'utilisateur. Lesquels ? Pourquoi les deux sont nécessaires ?* - C-RNTI : dialoguer avec le eNodeB (id unique dans la cellule) - m-TMSI : dialoguer avec l'opérateur (car cet id est unique dans le réseau de l'opérateur). Le m-MEC est l'identifiant unique du contrôleur du coeur de réseau. Apparemment, le même C-RNTI a pu être reçu par plusieurs UEs (par toutes les UEs qui ont choisi le meme préambule random access). Du coup, cela ne permet pas d'identifier le "gagnant" On a besoin d'un autre identifiant, si possible unique ou avec une faible probabilité de collision Et le TMSI correspond à ça, même si son rôle est à la base d'identifier l'UE auprès du réseau coeur. ### *1.10 Quel est le premier message transmis vers le coeur de réseau ? Comment est-il transmis au niveau RAN ? Comment appelle t-on ce mécanisme dans un réseau ?* RRC Connection Setup Complete dans lequel il reste de la place : on y ajoute alors un attachement request (et le PDN connectivity request). Il est transmis via le canal DCCH. ### *1.11 Quelle est la cause indiquée pour la demande d'attachement ?* Dans InitialUEMessage la cause indiquée est mo-data = traffic de paquets de données ### *1.12 Quelle est la procédure démarrée par le coeur de réseau à la réception d'une demande d'attachement ?* Une procédure d'identification de l'utilisateur est démarrée par le coeur de réseau, puis ensuite une athentification sécurisée. ![](https://i.imgur.com/K1wACwl.png) ### *1.13 Quelle identité de l'utilisateur mobile ?* Son IMSI : 001010123456789 ### *1.14 Dans le message NAS identity response, l'UE indique son IMSI, alors qu'on avait vu dans les messages précédents qu'il possède bien un TMSI. Pourquoi ce comportement ?* Il utilise son IMSI pour la phase d'authentification auprès du réseau, mais ensuite il utilisera un TMSI pour tout les autres échanges, pour éviter une usurpation. En effet, l'UE ne dispose pas d'un TMSI valable (celui utilisé précédemment n'est en réalité qu'un vieux TMSI utilisé uniquement pour dissocier de le C-RNTI, dans le cas où il ne serait pas unique et pouvoir communiquer avec la station de base, mais il n'est jamais vérifié), et ne peut donc l'utiliser. L'UE doit alors utiliser sont véritable IMSI (en clair) pour le premier dialogue, puis ensuite le coeur de réseau attribuera un TMSI à utiliser pour la suite des échanges. ### *1.15 Au niveau du coeur de réseau, pouvons nous savoir où est l'utilisateur dans le réseau ?* Le coeur du réseau dispose de l'identifiant de cellule et du LAC qui sera ensuite enregistré dans le HLR avec le TMSI/IMSI de l'utilisateur. On en a besoin afin de pouvoir rediriger les paquets de données. ### *1.16 En parlant des messages Identity Request et Identity Response, ces messages NAS sont encapsulés par plusieurs autres protocoles sur le réseau d'accès (visibles dans la trace ue.pcap). Quels sont ces protocoles ?* Les différents protocoles utilisés sont : - MAC-LTE - RLC-LTE - PDCP-LTE (permet le chiffrement de l'info, et a un rôle de signalement) Packet Data Convergence Protocol - RRC-LTE ### *1.17 Au niveau de l'UE, après la réception du message Identity request, un message de niveau MAC est envoyé (ligne 9). Des messages similaires sont ensuite envoyés tout le long de la trace. Quel est le rôle de ce message ?* Il s'agit d'un message de type long BSR, qui correspond au volume de données qui vont être transmises par le mobile au eNodeB afin de pouvoir prévoir le traffic et mieux ordonnancer, allouer les ressources au utilisateurs au niveau du eNodeB. Cela permet également de maintenir la connexion entre l'UE et le eNodeB s'il n'y a pas de traffic de prévu.