# ARM - CM7

###### tags: `ARM`, `CM`

**Sujets du jour : le protocole RRC et laprocédure de Random Access**

C'est toujours le smartphone qui contacte le réseau, mais il n'a pas le droit de parler car c'est le réseau d'accès qui dit qui parle quand.


Donc on utilise la procédure de Random Access pour accéder au canal. Cette procédure est identique ou équivalente qu'on soit en 2G, 3G, 4G (la forme d'onde n'est pas la même d'une techno à l'autre par exemple, mais ça n'a pas d'importance).

On utilise des formes d'onde orthogonales (64) grâce aux propriété de CDMA, appelées **préambules**. Celà permet aux utilisateurs de pouvoir transférer en même temps sans interférences.

1. L'UE envoie un préambule
64 préambules disponibles, que l'on va utiliser :
-> si on sait a beaucoup de data à envoyer
-> de manière ponctuelle (pour du contrôle en mobilité par ex)

On a des préambules qui sont :
-> Avec contention
-> Sans contention

Les préambules sont choisis de manière aléatoire mais si 2 utilisateurs choisisse me même préambule cela va entrainer des collisions.

2. Le RAN renvoie un random access response (RAR)
RAR : dest : random access RNTI = RA-RNTI = f(preamble, Slot RA)
On utilise un slot de random access.
Utilité du RAR : en tant que BS je veux répondre au préambule mais il n'y a pas d'identité dans l'onde donc pour savoir qui c'est j'utilise le RA-RNTI.

On donne un RNTI aux utilisateurs actifs : allocation de cell RNTI - C-RNTI. Le C-RNTI est propre à la cellule, c'est un identifiant, une adresse.

3. MSG 3 : RRC connection de l'UE au RAN
Plusieurs messages RRC :
- REQUEST
- REESTABLISHMENT

Signe que l'on est connecté
Peu être un Handover Command
Pour l'IoT c'est déjà des Data

On ne peut toujours pas envoyer des data importantes car on n'a pas encore réglé les collisions (on ne sait pas si le message va arriver)

L'UE attend un certain temps après l'envoi de ce message, s'il n'a pas de réponse il doit reprendre toute la procédure au début.

Dans le cas où plusieurs UE envoient le MSG3 en même temps avec la même forme d'onde, on peu décoder un des messages si son signal a 6dBm de plus que les autres signaux. Ces autres signaux ne seront pas décodés et doivent retourner au début.

Dedans, on met le C-RNTI et la seconde identité : TMSI (car plusieurs UE peuvent avoir le même C-RNTI, le but est de se distinguer)

Le TMSI a une durée de vie limité, et si on reste en mode avion pendant un certain temps par exemple, au rallumage on a plus de TMSI.

En 2G/3G : IMSI/IMEI
Ce n'est pas pour vérifier notre identité, pas de clé (le controleur de l'antenne ne connaît pas mon TMSI, c'est le controleur du réseau qui le connaît);
Problème : on les envoie en clair (pb de tracking)
En 4G/5G, on utilise un random si on a pas de TMSI par sécurité

Timer pour revenir à 1. après un certain délai si ça n'a pas aboutie

Truc important :
Aucun moyen de vérifier l'identité, elle sert à se distinguer des autres

4. Contention Resolution du RAN à l'UE

On termine la procédure avec le message de contention resolution à destinatio du C-RNTI + du 2nd ID.

RRC Connection Request
* 2nd id (TMSI, random)
* establishment cause

RRC Connection Setup
* Allocation DCCH
* PHY/MAC config

RRC Connection Setup complete
* PHY/MAC choices
* Piggybacking CN MSG

Remarque : RRC Connection Setup : allocation BCCH
No Uplink

### Les états des équipements dans le protocole RRC

**Etat RRC idle :**
* écoute le canal de paging (PCH) et le canal de broadcast (BCH)
- pas d'UL
- mobilité dans les LAC gérée par le CN

**Etat RRC connected :**
* DTCH (si traffic)
* DCCH (infos sur l'état de mes buffers)
* CQI (qualité du canal)
* CQI des voisins ; la BS décide du handover ou non
* timing advance
* power control

On passe de l'état RRC idle à RRC connected en utilisant RRC connection. On repasse en l'état RRC idle après plusieurs dizaines de seconde d'inaction de l'UE.
En RRC idle on envoie rien au réseau sur le lien UpLink !