Attachement au réseau 4G : Différents scénarios

Dans deux articles écrits en mai 2015, j’avais décris la procédure d’attachement au réseau 4G : http://blogs.univ-poitiers.fr/f-launay/2015/05/05/emm-procedure-initial-attach/ et http://blogs.univ-poitiers.fr/f-launay/2015/05/19/emm-procedure-initial-attach-part-2/

Je vais revenir sur ces deux articles afin de mieux expliquer les différents scénarios s’appliquant au mobile lorsque ce dernier fait une demande d’attachement.

La procédure d’attachement nécessite 2 étapes clés:

  • L’identification de l’UE auprès du MME.
  • Authentification de l’UE

L’identification consiste, de la part du mobile, à fournir un identifiant lequel est transmis en clair sur l’interface air jusqu’au MME. Il s’agit donc d’un message NAS. Cet identifiant est transmis en clair, c’est à dire non crypté. (Imaginez en effet que l’UE crypte son identifiant par une clé Kc connu par le MME. Le MME n’ayant pas connaissance de l’UE qui lui a transmis le message devrait tester toutes ses clés Kc pour récupérer l’identifiant).

L’identifiant permettant de connaitre l’UE peut être :

  • L’identifiant IMSI
  • L’identifiant GUTI.

Ces deux identifiants ont été décrits dans l’article suivant : http://blogs.univ-poitiers.fr/f-launay/2015/05/06/imsi-tmsi-gummei-guti/

Le GUTI, Global Unique Temporary Identifier permet d’identifier de manière unique l’UE. Cet identifiant est constitué d’un code unique fourni par le MME, nommé M-TMSI. Le M-TMSI permet donc de connaître l’UE au niveau du MME. En rajoutant le code d’identifiant du MME, du code identifiant le pool MME, l’identifiant du réseau opérateur (MNC) et le code pays (MCC), le GUTI permet donc de connaître le MME sur lequel était enregistré l’UE auparavant.

Ce dernier point est important, lorsque l’UE se détache du réseau 4G (lorsqu’il envoie un message DETACH request), les contextes de commutation de bearer sont supprimés au niveau du PGW et du SGW mais :

  • l’UE conserve son contexte de sécurité NAS, le GUTI et le tracking area
  • le MME conserve le contexte de sécurité NAS associé au GUTI.

L’authentification consiste à vérifier l’identité de l’UE, soit à partir du message d’intégrité NAS soit à partir d’une procédure d’authentification mutuelle nommée AKA. Cette procédure permet au réseau de vérifier l’UE et pour l’UE de valider le réseau. Le choix de la procédure d’authentification est dictée par la manière dont l’UE s’identifie au réseau.

Si l’UE transmet son identifiant IMSI, dans ce cas le réseau applique la procédure d’authentification AKA mais si l’UE transmet son identifiant GUTI, le réseau est alors en mesure de récupérer son contexte de sécurité NAS.

Le contexte de sécurité NAS permet de garantir un échange authentifié entre l’UE et le MME (NAS Message) en chiffrant les données via une clé de chiffrement Knasenc et de valider l’intégrité du message via une clé d’intégrité Knasinc. Ces deux clés ont été générées au cours d’un précédent attachement avec l’identité IMSI.

Détachement

Nous allons maintenant nous intéresser à la spécification 23.401. (version 8 ira très bien).

Nous avons vu précédemment que l’UE pouvait s’identifier selon son IMSI ou son GUTI. Or, pour s’identifier avec le GUTI, le téléphone doit avoir été enregistré. Ainsi, aussi étrange que celà puisse paraître, pour comprendre cette procédure d’attachement, je vais commencer par expliquer la procédure de détachement, c’est à dire lorsque l’UE se désenregistre du réseau.

La procédure de détachement (Detach procedure – section 5.3.8 p70) peut être déclenchée par l’UE ou par le réseau.

L’UE peut faire une demande de détachement lorsque l’utilisateur éteint son téléphone ou bascule en mode avion. Dans ce cas, l’UE émet une requête NAS avec un indicateur « Switch Off » et le MME répond par un Detach Accept. Les contextes de commutation sont supprimés au niveau du SGW et PGW, le MME conserve quant à lui le contexte de l’UE (GUTI et clé de chiffrement/clé d’intégrité lié avec le GUTI).

Le MME peut aussi faire une demande de détachement pour un UE,

  • soit une demande implicite (UE est implicitement détaché) qui a lieu lorsque l’UE n’a pas transmis ou reçu de données depuis un certains temps (implicit Detach Timer = T3423 + 4 mn si l’ISR – Idle Mode Signaling Reduction est activé  )
  • soit une demande explicite par exemple pour réaliser de l’équilibrage de charge sur un autre UE

Jusqu’à présent, le MME a conservé le contexte NAS et le GUTI de l’UE. Au bout d’un certain temps

La fonction Purge (Purge Function cf section 5.3.9.3 p74) permet au MME d’informer le HSS qu’il a supprimé le contexte NAS et le GUTI. Ce dialogue est réalisé par le protocole Diameter via le message PUR/PUA (Purge Request/Answer). Dans le cas de cette procédure, le MME n’a plus de contexte concernant l’UE.

Attachement

Il nous reste plus qu’à étudier les différents scénarios pour la procédure d’attachement. Il y a 5 cas en tout :

1 – L’UE se connecte pour la première fois : Il transmet son identifiant IMSI

2 – L’UE se connecte avec son identifiant GUTI

  1. Sa demande est transférée au MME sur lequel il était précédemment connecté
    1. Le MME a conservé son contexte
    2. Le MME n’a plus son contexte
  2. Sa demande est transférée à un MME différent de son précédent MME
    1. Le MME a conservé son contexte
    2. Le MME n’a plus son contexte

Attachement

Il faut bien se rappeler que quelque soit le scénario, la première étape consiste à s’identifier, donc à transmettre en clair son identifiant. Ensuite, si le mobile transmet son IMSI, la requête NAS de demande d’attachement n’est pas chiffrée.

Par contre, si le mobile transmet son GUTI, la suite du message NAS est chiffrée et une clé d’intégrité est rajoutée.

Voyons les différents cas.

CAS 1 – L’UE se connecte pour la première fois : Il transmet son identifiant IMSI. Dans ce cas, le réseau effectue une authentification AKA. J’invite le lecteur à se référer à l’article http://blogs.univ-poitiers.fr/f-launay/2015/05/05/emm-procedure-initial-attach/

2 – L’UE se connecte avec son GUTI.

CAS 2 : L’eNb analyse le GUTI, ce dernier est connecté au MME via un lien S1-MME, il peut donc relayer la requête NAS de demande d’attachement au MME. Le GUTI est envoyé en clair, la requête NAS est chiffré et une clé d’intégrité est rajouté.

CAS 3 : L’eNb analyse le GUTI, ce dernier n’est pas connecté au précédemment MME. La requête est donc transmise à un nouveau MME, et ce dernier vient interroger l’ancien MME. Le GUTI est envoyé en clair, la requête NAS est chiffré et une clé d’intégrité est rajoutée correspondant à l’ancien MME. Le nouveau MME transférant le tout à l’ancien MME. On suppose que ce MME n’a pas conservé le contexte ou la clé d’intégrité n’est pas correcte, dans ce cas le MME informe le nouveau MME qu’une procédure d’authentification doit être réalisée. Le nouveau MME demande à l’UE de s’identifier à nouveau via son identifiant IMSI

CAS 4 : L’eNb analyse le GUTI, ce dernier est connecté au MME via un lien S1-MME, il peut donc relayer la requête NAS de demande d’attachement au MME. Le GUTI est envoyé en clair, la requête NAS est chiffré et une clé d’intégrité est rajouté. Le MME est capable de déchiffrer le message et la clé d’intégrité est correcte. Dans ce cas, le MME accepte la demande d’attachement.

CAS 5 : L’eNb analyse le GUTI, ce dernier n’est pas connecté au précédemment MME. La requête est donc transmise à un nouveau MME, et ce dernier vient interroger l’ancien MME. Le GUTI est envoyé en clair, la requête NAS est chiffré et une clé d’intégrité est rajouté. L’ancien MME est capable de déchiffrer le message et la clé d’intégrité est correcte. Dans ce cas, l’ancien MME informe le nouveau MME que la demande peut être acceptée.

Attachement1Attachement2Selon les différents cas, la procédure d’authentification AKA n’est pas nécessaire. Voici une dernière figure résumant les 5 cas possibles et le dialogue entre l’UE et le MME

Attachement3

 

Que doit on attendre d’ici la fin de l’année? Plus de Débit et la VoLTE.

De la 4G à la 4G++

De manière évidente, la première réponse est : Plus de débit!

En effet, après l’annonce de la 4G permettant d’atteindre des débits inégalés par rapport au réseau 3G/3G+ et H+, après l’annonce de la 4G+ permettant de doubler voir tripler le débit par rapport à la 4G, les opérateurs vont maintenant dégainer leur 4G++.

Mais quelle réalité derrière ces noms commerciaux?

Revenons un moment sur la norme, les évolutions proposées et normalisées sont l’évolution du LTE au LTE-Advanced. Cette dernière norme, une fois déployée, permettra d’atteindre un débit allant jusqu’à 3 Gbps par l’agrégation de 5 porteuses de 20 MHz avec un terminal de catégorie 8.

Pour les opérateurs, la dénomination du réseau est différente :

  • La 4G exploite une seule bande de fréquence
  • La 4G+ permet l’agrégation de deux bandes de fréquences
  • La 4G++ permet l’agrégation de trois bande de fréquences.

A ce stade, le LTE-Advanced sur 5 bandes devrait se nommer 4G++++ ou 4G puissance 5?

Mais en terme de débit?

La subtilité arrive quand on compare maintenant les offres des opérateurs. En effet, pour simplifier on considère à cette date que 5 MHz de bande permet d’obtenir un débit de 37,5 Mbps sur le lien descendant (attention, cela ne sera plus le cas pour les terminaux de catégories 11).

En terme de débit, voici la liste des terminaux de catégorie 1 à 14.

LTEUECategoriesMay2015

L’agrégation de porteuses permet d’atteindre des débits plus élevé. Mais de par la faible disponibilité de bande passante dans la bande de 2600 MHz et 800 MHz, les opérateurs doivent agréger jusqu’à 3 ou 4 porteuses dans des bandes différentes. Ainsi, Bouygues proposent 300 Mbit/s en proposant 40 MHz de bandes répartis en :

  • 10 MHz dans la bande de 800 MHz
  • 15 MHz dans la bande de 1800 MHz (refarming)
  • 15 MHz dans la bande de 2600 MHz

La conception de Modem permettant l’agrégation de porteuses est plus complexe que prévue. En effet, initialement la norme prévoyait 8 catégorie de terminaux (cat 1 à cat 8) mais de nouvelles catégories de terminaux ont été rajoutées (cat 9, 10 et 11) proposant des agrégations sur 3 et 4 porteuses sur des bandes différentes.

Selon le tableau ,les catégories 9 et 10 attendus pour cette fin d’année et l’année prochaine atteindront pour leur part 450 / 50 et 450 / 100 Mbps. Mais, ce débit n’est possible que si l’opérateur dispose de 3 bandes de 20 MHz (rappelez vous de la règle :  5 MHz de  bande permet d’atteindre un débit de 37.5 MHz). La catégorie 11 n’est donc pas attendue avant 2016.

Capture

Donc pour résumer, en fin d’année, Bouygues proposera 300 Mbit/s, Orange et SFR devront attendre le 25 mai 2016 pour pouvoir exploiter eux-aussi la bande de 1800 MHz (refarming). A partir de cette date, Orange proposera donc un débit de 337,5 Mbps.

 

07894217-photo-bouygues-telecom-5-fevrier-2015

VoLTE

En parallèle les opérateurs mettent en place la VoLTE. A titre expérimental encore à ce jour pour la plupart des opérateurs, Orange vient d’ouvrir dans la nuit du 14 au 15 septembre le réseau VoLTE sur le Grand Ouest.

La VoLTE va permettre à l’opérateur d’offrir une communication téléphonique avec une meilleure qualité de la voix notamment grâce au codec AMR WB. La Voix est donc transportée par l’IP sur un flux RTP, quand à la SIG Téléphonique (pris en charge par le réseau IMS), celle-ci est transportée par le protocole SIP sur l’UDP.

L’offre commerciale pourra aussi proposer sur des services complémentaires apportés par un serveur d’application téléphonique (TAS). Le TAS permettra de faire profiter aux utilisateurs de tous les services offerts sur les postes des entreprises (TAS = Serveur téléphonique, comme un IPBX), à savoir les renvois d’appel, le parçage, …

 

 

Quand le eNb sature t’il?

Les équipementiers qui vendent l’infrastructure 4G limitent les capacités des entités en soumettant leur solution à des licences. D’un autre coté, les licences garantissent aussi le traitement d’un nombre de sessions maximum en temps réel. A titre d’exemple, les eNB ont une capacité (en terme de licence) de 512 bearers, c’est à dire que l’eNb peut ouvrir 512 connexions (bearer) garantissant le maintien de 512 sessions avec les utilisateurs en mode actif.

A ce jour le nombre de bearers que l’eNB met en oeuvre sur certains site de Nantes et aux heures de pointe atteint ce chiffre. On parle alors de saturation de l’eNb, mais nous verrons dans cet article que le déploiement de la VoLTE peut aggraver cette limitation.

Nous allons calculer le nombre d’UE pouvant avoir des accès au cours d’un TTI (Transmission Time Interval correspond à une unité de temps de 1ms pour le LTE, c’est la plus petite unité de temps pendant laquelle un user peut recevoir ou émettre des données). Sous des hypothèses simplificatrices, nous allons calculer le nombre maximum d’utilisateur pouvant, au cours d’un TTI, transmettre ou recevoir des données. Mais, le nombre d’utilisateurs actifs peut être plus élevé puisque un user peut nécessiter des ressources à un TTI mais pas au(x) TTI(s) suivant(s).

Combien d’utilisateurs maximum sont actifs par TTI sur l’eNB ?

Nous allons nous intéresser dans cet article au nombre maximum d’UE pour lesquelles l’eNb alloue des données sur un TTI. Nous aborderons dans un premier la méthode de répartition des canaux de contrôles sur la bande LTE afin de calculer le nombre d’allocation possible.

1 – Structure de la trame.

1-a) PDCCH

Les données transmises entre l’eNb et l’UE sont séquencées de manière dynamique. L’UE est informé de l’allocation de PRB en réception et de l’attribution de PRB en émission via les informations portées par le canal PDCCH. Outre l’allocation de ressource, le PDCCH informe l’UE du type de modulation et du codage utilisés (MSC) et en cas de réception multiples (MIMO), le PDCCH transporte le type de précodage (PMI).

Ainsi, le PDCCH transporte des informations de contrôle :

  • sur la voie descendante permettant d’informer l’UE de l’existence de données à recevoir dans la trame courante et des caractéristiques de modulation
  • des informations sur les ressources que l’UE utilisera sur la voie montante pour la sous-trame émise par l’UE 4 TTI plus tard.

Il est à noter que plusieurs PDCCH peuvent être transmis dans une sous-trame, soit pour transmettre des données respectivement à plusieurs UE, soit pour un seul UE. En effet, plusieurs PDCCH peuvent être transmis à un seul UE dans le cas ou le nombre d’information est conséquent, comme par exemple pour informer l’UE de l’allocation dynamique et du schéma de codage sur la voie descendante et montante, ainsi que la commande de contrôle de puissance.

Afin de spécifier le type d’information transporté par le PDCCH, l’UE décode l’information portée par le DCI (Downlink Control Information) qui stipule le type d’information transmise par le PDCCH parmi  10 formats possibles. Les 10 formats sont récapitulés dans le tableau ci-dessous :

DCI

Les formats DCI 0, DCI 3 et DCI 3A portent des informations destinées à l’UE pour la transmission sur la voie montante. En effet le format DCI 0 alloue des PRB pour l’émission du mobile vers l’eNB, et les formats DCI3/DCI 3A portent de contrôle de puissance pour la voie montante.

Le PDCCH est transmis sur un CCE (control channel elements) ou sur plusieurs CCE (on parle d’aggrégation de CCE dont les valeurs sont 2, 4 ou 8 CCE). Un CCE est composé de 9 REG – Ressource Element Group, un REG étant constitué de 4 RE. Le PDCCH est modulé en QPSK.

PDCCH_format

1-b) PCFICH

De plus, le PDCCH est obligatoirement transmis sur les premiers symboles OFDM de chaque sous-trame (De 1 à 3 symboles voir 4 symboles au maximum si le nombre de RB est faible, ce qui correspond au cas où la bande est de 1.4 MHZ). Pour savoir sur combien de symboles est transmis le PDCCH, l’eNb transmet une information complémentaire nommée CFI (Control Format Indicator) dans le canal de control PCFICH. Le PCFICH est transmis quant à lui sur le premier symbole OFDM de chaque sous trame, réparti sur toute la bande pour profiter de la diversité en fréquence. Les 4 valeurs possibles de CFI sont encodées dans un mot de 32 bits avec une forte redondance pour assurer la détection/correction au niveau de l’UE.

PCFICH_Mot

De surcroît, le canal PCFICH est modulé en QPSK pour assurer une meilleure immunité au bruit. Le CFI étant codé sur 32 bits, 16 RE sont donc nécessaires, soit 4 REG. La position des REGs est définie en fonction de l’identité de la cellule (Cell Id), laquelle est une valeur comprise entre 1 et 504.

PCFICH_REG

1-c) PHICH

Outre le PCFICH, l’eNb transmet des informations d’acquittement (ACK/NACK) sur les trames émises par l’UE. Il s’agit du canal PHICH (HARQ), dans lequel 1 bit d’information (ACK/NACK) est répété 3 fois et étalé par un code de Walsh Hadamard (code orthogonal) et modulé en BPSK.

Ainsi, un ACK a pour valeur 111 et un NACK a pour valeur 000. Le PHICH est modulé en BPSK (signal complexe situé sur le cercle trigonométrique à +pi/4 ou 5*pi/4), il faut donc 3 symboles. Le signal modulé est ensuite étalé par un code d’étalement de facteur SF=4, permettant d’obtenir 32 combinaisons complexes et d’extraire 8 codes orthogonaux (4 codes et l’équivalent déphasé de pi/2). Grace aux 8 codes orthogonaux, il est possible de transmettre 8 PHICH simultanément.

Il est donc nécessaire de réserver 12 RE pour transmettre jusqu’à au plus 8 PHICH. On parle de groupe de PHICH, codé par des codes orthogonaux.

PHICH_Code_Orthogonaux

2 – Calcul du nombre de PDCCH.

Nous allons maintenant calculer le nombre de ressources PDCCH, permettant ainsi d’obtenir le nombre d’utilisateurs simultanés sur la bande totale de l’eNB.

Il s’agit donc de calculer le nombre de ressource disponible (RE) sur les premiers symboles (1 à 3) pouvant porter le canal PDCCH. L’objectif est donc de calculer le nombre de RE disponible sur tout la bande et retrancher les canaux PFCICH, PHICH et les signaux de références (RS).

Les signaux de références (RS) sont transmis par l’eNB à chaque RB et tous les 6 RE du premier symbole si l’eNb n’a qu’une seule antenne. Si l’eNb possède au moins deux antennes, les RS sont également transmis sur 6 RE du premier symbole pour la 2ème antenne. Le RS est nécessaire afin de mesurer la distorsion apportée par le canal de propagation et de ce fait, dans le cas ou l’eNb possède deux antennes, l’eNb ne transmet aucun signal sur le RE correspondant à la position du RS de l’autre antenne.

RS_antennes

On va donc considérer qu’il y a 2 ou 4 RS par PRB.

Nous pouvons maintenant calculer le nombre de ressources PDCCH.

Rappelons que selon la bande allouée au LTE qui s’étend de 1.4 MHz  minimum à 20 MHz, le nombre de PRB noté N_PRB est le suivant :

1,4 MHz =>  6 PRBs

3  MHz   =>  15 PRBs

5  MHz   =>  25 PRBs

10  MHz  => 50 PRBs

15  MHz  => 75 PRBs

20  MHz  => 100 PRBs

Chaque PRB est composé de 12 sous porteuses, le PDCCH est transporté sur N_pcfich symboles (canal PCFICH). Le nombre total de RE sur N_pcfich symbole est donc de :

12*N_PRB*N_pcfic

Nous allons maintenant calculer le nombre de RE à soustraire :

  • Info_PCFICH=16
  • Info HARQ. On sait qu’il est possible de transmettre un groupe de 8 ACK/NACK dans un seul PCICH. Par conséquent, sur N_PRB, le nombre de groupe de PCFICH sera de E[N_PRB/8], avec E la partie entière supérieure. Enfin, le groupe de PCICH nécessite 12 RE, donc le nombre de RE sera de 12* E[N_PRB/8].
  • RS pour une antenne : 2*N_PRB
  • RS pour deux antennes ou plus : 4*N_PRB

2 – Application et cas de la VoLTE.

2-a) Calcul sur 5 MHz, 10 MHz et 20 MHz

Nous allons faire une application pratique sur 10 MHz, puis à partir des tableaux, je fournirai les résultats sur 5 MHz et 20 MHz

10 MHz =>50  PRB soit 50 *12 RE =600 dans le premier symbole. Si le nombre de symbole utilisé par le PDCCH monte à 3, alors il y a aura 1800 RE pouvant transporter les PDCCH

On retire :

  • 16 RE pour le PCFICH
  • 12* E[50/8] = 12*7=84 RE pour le PCICH
  • 100 RE pour les RS si une antenne et 200 RE pour deux antennes

Soit un total de 200 RE ou 300 RE pour deux antennes.

Pour rappel,  le PDCCH nécessite au moins un CCE (mais peut nécessiter 2 CCE, 4CCE ou 8CCE). Un CCE est composé de 36 RE et le PDCCH est positionné sur N_pcfich symboles (canal PCFICH). Pour finir, étudions les 3 cas possibles

  1. N_pcfich=1 => 600 RE, moins 100 RE pour une antenne et 200 pour 2 antennes. Il reste donc 400 ou 300 RE. Dans le cas ou il y a 2 antennes, 300/36=8.33 soit 8 PDCCH donc 8 utilisateurs simultanés
  2. N_pcfich=2 => 1200 RE, moins 100 RE pour une antenne et 200 pour 2 antennes. Il reste donc 1000 ou 900 RE. Dans le cas ou il y a 2 antennes, 900/36=25 soit 25 utilisateurs simultanés
  3. N_pcfich=3 => 1800 RE, moins 100 RE pour une antenne et 200 pour 2 antennes. Il reste donc 1600 ou 1500 RE. Dans le cas ou il y a 2 antennes, 1500/36=41.66 soit 41 utilisateurs simultanés

Voilà une synthèse pour 3 bandes LTE différentes et deux antennes :

Nbre_PDCCH_5MHZ

Nbre_PDCCH_10MHZ

Nbre_PDCCH_20MHZ

NB : L’UE détecte le PDCCH en fonction de son identifiant RNTI – Radio Network Temporary Identifier :

  • P-RNTI si le mobile est en veille. Il écoute le canal PDCCH pour être informé d’un Paging
  • C-RNTI en mode connecté ou SPS-C-RNTI quand il reçoit des informations périodiquement (par exemple de la VoIP reçue toutes les 20 ms)

Le RNTI est codé sur 16 bits et réalise un ET logique avec le code CRC du canal PDCCH.

2-b) Impact de la VoLTE

Les eNb sont limités à 512 bearers actifs, quel sera l’impact de la VoLTE?

Nous supposons une bande de 10 MHz, si le PDCCH est codé sur 3 symboles (hypothèse de 2 antennes), le nombre maximum d’utilisateur sur une bande de 10 MHz est donc de 41 utilisateurs par TTI.

Or, la VoLTE nécessite la transmission d’information que tous les 20 TTI, donc en supposant que des utilisateurs en VoLTE, le nombre de sessions actives est de :

41 * 20 = 820 utilisateurs.

Par contre dans le cas ou la bande n’est que de 5 MHz, le nombre d’utilisateurs actifs sera limité à 400, en dessous du seuil des 512 licences.

La Bande des 700 MHz

Je vous avais soumis l’an dernier des prévisions de consommation de volumes de données jusqu’en 2018, nous allons maintenant nous appuyer sur les chiffres de volumes consommés par les clients sur leur téléphone mobile entre le 2ème trimestre 2011 et le 2ème trimestre 2014. Au regard de la courbe, le volume est en croissance exponentielle (environ 70% d’augmentation chaque année) et on note une multiplication par 5 par rapport à 2011.

Consommation_data

Cette augmentation de données se justifie aussi par une augmentation de débits sur l’interface radio, mais la problématique se pose sur le partage d’accès et l’évolution à terme de la 4G+ vers la 4G++.

Les prochains smartphones pourront se connecter sur 3 bandes du réseau LTE permettant ainsi de profiter d’une bande de 10 MHz autour de 1800 MHz, 20 MHz autour de 2600 MHz et 10 MHz autour de 800 MHz. Cependant, le LTE-Advanced suggère l’agrégation de 5 canaux de 20 MHz. Or, le partage actuel du spectre ne rend pas cette solution envisageable à ce jour, comme le montre les tableaux de répartition de fréquence ci-dessous :

Spectre_900

*Le spectre 900 MHz est utilisé pour la 3G (re-farming) mais pas pour la 4G

1800_erreur

 

Modification du 26/10/2015 (afin de comprendre les remarques de cet article, j’ai laissé la figure précédente même fausse, la correction étant néanmoins apportée. Merci au lecteur d’avoir notifié cette erreur).

1800

*Le spectre 1800 MHz a été ré-attribué pour permettre à Free d’avoir une bande pour réaliser du re-farming 4G. Voici en effet l’évolution des bandes 1800 MHz (Chaque opérateur fournit 5 MHz de bande à Free à 1800 MHz lorsqu’il active le Re-farming sur cette bande). La figure ci-dessous était une projection de l’évolution de l’attribution des fréquences. Je rappelle que

*Orange et SFR conservent la possibilité de demander à tout moment une levée anticipée des restrictions technologiques dans la bande 1800 MHz, s’ils souhaitent utiliser la 4G dans cette bande avant la date du 25 mai 2016.

Spectre_1800

Pour répondre au lecteur (cf. remarques en fin de l’article), effectivement seul Bouygues a fait une demande anticipée de re-farming. Cette demande a été acceptée par l’ARCEP le 14 mars 2013. Par conséquent, en 2012, Free ne disposait pas encore de 5 MHz de Bande, et la libération des bandes par Bouygues pour SFR sur le territoire en France était planifiée entre Octobre 2013 et Juillet 2015).

Spectre_2100

*Le spectre 2100 MHz n’est réservé à ce jour que pour la 3G

Spectre_2600

Le spectre 2600 MHz a été vendu en septembre 2014 pour la 4G en complément du spectre 800 MHz vendu en décembre 2014 pour la 4G (Free n’a pas acquis de licence dans la bande de 800 MHz – leur enchère n’était pas assez élevée pour avoir un lot).

Spectre_800

Bande des 700 MHZ

A ce jour non, mais une 4ème bande sera bientôt exploitée pour la 4G permettant ainsi aux opérateurs d’envisager l’agrégation de 4 bandes et atteindre 70 MHz de bande.

La bande envisagée est le 700 MHz car elle déjà exploitée par des opérateurs sur d’autres continents. Les UE (smartphone) sont donc déjà équipés de modules à 700 MHz.

Cependant, la bande de 700 MHz (694 MHz à 790 MHz)  est actuellement attribuée à la TNT en France. A la date du 10 décembre 2014, par communiqué de presse, le Premier ministre a précisé les modalités de mise en oeuvre des modalités de réallocation des fréquences de la bande 700 MHz aux opérateurs mobiles.

En terme de date, le gouvernement souhaite attribuer des autorisations d’utilisation de bloc de 5 MHz dans la bande 700 MHz aux opérateurs mobiles en décembre 2015. Au total 30 MHz de bande. Les bandes 703-733 MHz et 758-788 MHz sont utilisées en mode de duplexage fréquentiel (mode FDD), la transmission de la station terminale (liaison montante) étant située sur les fréquences 703-733 MHz, et la transmission de la station de base (liaison descendante) étant située sur les fréquences 758-788 MHz.

Toutefois, ces bandes ne seront libérées qu’entre le 1er octobre 2017 et le 30 juin 2019, à l’exception de quelques zones où ces derniers pourraient les utiliser dès avril 2016.

Le jeudi 18 juin, L’ARCEP a transmis pour avis aux membres de la commission consultative des communications électroniques (CCCE) les projets de décisions qu’elle a élaborés en vue de l’attribution de la bande 700 MHz.

Que deviendra la TNT?

La TNT est donc affectée par cette réallocation de fréquence. Or, avec le nombre de chaînes qui diffusent sur la TNT (en prenant en compte les chaînes HD), il est nécessaire d’optimiser le type de codage utilisé actuellement pour les chaînes non HD. Ainsi, la technique Mpeg2 va disparaître et les transmissions se feront en Mpeg4. Cela va nécessiter le remplacement de certains décodeurs et de télévision, pour savoir s’il faut remplacer votre télévision, il suffit de regarder si votre télévision peut décoder les chaînes HD. Si oui, vous avez un décodeur Mp4.

SRVCC – Single Radio Voice Call Continuity – Suite

Nous allons maintenant étudier le mécanisme SRVCC et ses évolutions eSRVCC et rSRVCC en illustrant le concept par une approche pratique.

On suppose que l’UE1 souhaite contacter l’UE2. L’UE1 est sur un réseau 4G, vis à vis du réseau IMS, qui est le réseau home, l’UE1 est dans un réseau visité.

L’UE1 souhaite appeler l’UE2. L’UE1 est compatible avec le mécanisme SRVCC et l’appel est évidemment contrôlé par le réseau IMS. Ainsi, après un échange de signalisation SIP, après avoir construit les bearers, l’appel s’effectue. L’UE1 se déplace dans le réseau visité et s’éloigne du eNB, la puissance reçue s’affaiblit.

  1. L’eNb décide alors de mettre en oeuvre le mécanisme SRVCC en envoyant une requête au MME
  2. A partir de cette requete, le MME transmet la demande au MSC afin que ce dernier alloue les ressources au niveau du domaine CS autrement dit avec le RNC puis le Nb.
  3. Le MSC demande la création d’une connexion avec le SCC AS dans l’objectif de transférer la voix (paquet IP) du réseau LTE vers le réseau 3G donc pour transférer la session du PGW vers le MSC.

SRVCC

A ce stade, pour le mécanisme SRVCC définit dans la R8, la procédure est la suivante :

  • Le SCC demande à l’UE de changer la destination de ses messages SIP de l’UE1 vers le MSC.

En parallèle,

  • Le MSC informe le MME de la réservation de ressource dans le domaine CS.

A partir de ce moment, le MME peut demander à l’UE1 de basculer vers le réseau 3G (Handover). Après le Handover, la signalisation SIP est transmise du SCC vers le MSC, le SCC est le point d’ancrage pour la signalisation, et le média pour la voix est envoyé de l’UE2 vers le MSC. L’UE2 est donc le point d’ancrage pour le média.

Or, la modification de l’adresse IP de destination (UE1 vers MSC) pour le média de la voix provoque de nombreuses pertes de paquets et une latence puisque toutes les entités du réseau IMS de l’UE2 et l’UE2 doivent modifier leur chemin de requêtes SIP

En simplifiant la figure avec les entités concernés, le chemin de signalisation et d’appel est représenté par la figure ci-dessous.

SRVCC_fig4

eSRVCC

Le principal défaut  du SRVCC est le suivant : Lorsqu’un HandOver affecte l’UE1 dans son réseau visité (ou en roaming), cela impacte les messages SIP et RTP de l’UE2. Le mécanisme eSRVCC consiste à rajouter des points d’ancrage au niveau du réseau visité de l’UE1 afin que tout handover de l’UE1 soit transparent pour l’UE2.

Ainsi, au niveau du eSRVCC, 2 nouvelles entités ont été rajoutées pour avoir un point d’ancrage dans le réseau visité à savoir :

  • ATCF : Point d’ancrage pour la signalisation
  • ATGW : Point d’ancrage pour le média

SRVCC_fig5

 

 

 

 

 

 

SRVCC – Single Radio Voice Call Continuity

Lorsque le réseau VoLTE sera déployé (2ème semestre 2015), l’opérateur devra garantir la continuité d’appel en réalisant

  • un HandOver entre le réseau 4G et le réseau 2G/3G (nommé IRAT Handover) tant pour l’appel téléphonique (passage de la voix du domaine PS vers le domaine CS) que pour les sessions Data
  • un Transfert de session au niveau du cœur réseau entre le MME et le MSC. L’appel est géré par le réseau IMS, et plus précisément pour les mobiles compatibles SRVCC  (Single Radio Voice Call Continuity), le point d’ancrage de l’appel est réalisé par un serveur d’application nommé SCC AS (Service Centralization and Continuity).

SRVCC_fig3

Nous allons dans un premier temps décrire les notions  Single Radio  et Voice Call Continuity (SCC AS). Le SCC AS est un serveur d’application IMS, cette solution se diffère donc du CSFB pour lequel l’IMS n’est pas mis en place.

SCC AS

Avec le déploiement de l’IMS, lorsque le mobile émet ou reçoit un appel, la requête SIP INVITE est transmise jusqu’au S-CSCF. L’exécution de la tâche qui est associée (renvoi de la requête vers un AS) dépend des règles de souscription de l’abonné et la tâche qui est réalisée est obtenue en appliquant l’événement (par exemple un appel) à la liste de règles définie à travers les paramètres du filtre iFC (initial Filter Criteria). Si le mobile n’est pas compatible au mécanisme SRVCC ou si ce dernier n’est pas déployé, l’appel sera transmis au Serveur d’application Téléphonie (TAS  : Téléphony Application Server). Dans cet article, le cas qui nous intéresse est le mécanisme SRVCC on suppose donc que la technologie est déployée et que le  mobile est compatible, dans ce cas, l’appel sera dirigé vers un serveur qui sera considéré comme le serveur d’ancrage dans le réseau IMS. Ce dernier se nomme SCC AS avec la particularité suivante :

  • Si l’UE est à l’origine de l’appel, l’appel sera transmis d’abord au SCC AS avant d’être traité par le TAS.
  • Si l’UE est à destination de l’appel, l’appel sera transmis au TAS qui le transfère au SCC AS.

SRVCC_fig1

ICS : IMS Centralized Service.

Single Radio ou Dual Transfer Mode

La solution CSFB que nous avons étudiée est un mécanisme transitoire permettant, au téléphone en mode 4G initiant un appel, de passer du réseau LTE (PS) au réseau 2G/3G (CS). Dans le cas ou le téléphone migre vers le réseau 3G, les sessions Data en commutation de paquets peut à la fois gérer les services datas et la voix (VoHSPA).

Dans le cas de la migration vers la 2G, les sessions Datas seront suspendues jusqu’à la fin de l’appel téléphonique en CS c’est à dire jusqu’à ce que l’UE revienne sur le réseau 4G, sauf si l’UE 2G supporte le Dual Transfer Mode (DTM) qui permet à la fois la voix et la Data.

SRVCC : Single Radio Voice Continuity Call

L’arrivée de la VoLTE est concomitante avec le déploiement du réseau 4G de l’opérateur, il est donc nécessaire de pouvoir basculer l’appel en VoLTE sur le réseau IMS vers le réseau traditionnel en cas de perte de couverture 4G, tout en garantissant la QoS.

C’est le rôle du mécanisme SRVCC que de basculer l’appel du mode PS 4G vers le mode CS 2G/3G. Cela impacte le MSC car ce dernier doit gérer l’appel de l’UE vers le point d’ancrage IMS.  Le MSC est renommé « MSC Server enhanced for SRVCC ». La méthode présentée est à la fois compatible pour la VoLTE et la VoHSPA.

NB : Il y a deux mécanismes SRVCC, le premier SRVCC vers le GERAN/UTRAN que nous abordons ici et proposé  par le 3GPP, le second permet de basculer vers le réseau CDMA et est proposé par le 3GPP2.

Les entités impactées par ce mécanisme (SRVCC – R10) sont :

  • UE
  • MSC
  • eNb
  • MME
  • P-CSCF
  • HSS

avec l’ajout de deux autres entités lors de la R10 :

  • ATCF : Point d’ancrage de la signalisation SIP
  • ATGW : Sous le contrôle de l’entité ATCF

SRVCC_fig2

Le MME dans cette procédure doit être en mesure :

  • Séparer le flux Data (PS) du flux Voix (géré par le mode CS après basculement)
  • Gérer le handover des bearers PS non voix avec la cellule cible
  • Initier la procédure de handover SRVCC (en s’appuyant sur le QCI=1)

Une nouvelle interface, nommée Sv, est créée entre le MSC et le MME. Cette interface permet au MME de :

  • demander au MSC de réserver des ressources radios au niveau de l’interface d’accès radio CS (BTS ou Noeud B). Le MSC est donc responsable de la réservation de ressource pour la continuité d’appel
  • donner l’adresse du SCC AS au MSC afin que ce dernier émette une demande d’appel de la part de l’UE.

Procédure

Au cours de l’attachement au réseau, le MME récupère le STN-SR (Session Transfer Number for SR-VCC) de la part du HSS. Il s’agit d’un numéro au format téléphonique répondant à la spécification E.164. C’est cette adresse que le MME transmet au MSC afin que ce dernier puisse émettre un appel et créer un acheminement entre l’UE et le point d’ancrage IMS.

En effet, l’objectif du SRVCC est de transférer l’appel PS vers le mode CS, or l’appel est géré par le réseau IMS, et plus précisément par un serveur d’application nommé SCC (Service Centralization and Continuity). Le MSC quant à lui a besoin d’un numéro d’appel ou de commutation pour réaliser la jonction avec le réseau IMS. Le STN-SR est envoyé du MME au MSC via l’interface Sv.

SRVCC

Le MSC initie une requête SIP vers l’IMS via le numéro STN-SR. Le SCC-AS reçoit la requête INVITE avec le STN-SR avec le message de demande de transfert d’une session active. C’est au SCC AS de gérer ce transfert de session.

Sur le call flow suivant, on retrouve les deux étapes du SRVCC

  • un HandOver
  • un Transfert de session

SRVCC_callflow

Dans un prochain article, nous détaillerons la procédure.

VoLTE – Principe de base

J’ai eu souvent l’occasion de le répéter, le réseau 4G est un réseau tout IP ne permettant pas les appels voix par commutation de circuit comme c’est le cas pour la 2G ou 3G. Dans le précédent article, j’ai présenté le mécanisme permettant de quitter le réseau 4G et se connecter sur le réseau 2G/3G afin d’établir (émettre ou recevoir) un appel voix. Il s’agit du CSFB.

La VoLTE ou Voix sur LTE désigne le principe de service voix sur le réseau à commutation de paquet IP mais acheminée via le réseau LTE/SAE jusqu’au PGW pour être pris en charge par le réseau IMS.

Deux cas d’études  se présentent à nous :

  • L’APN pour le réseau IMS est il le même que l’APN pour accéder à Internet, autrement dit, la session Internet et la session VoLTE passent elles par le même PGW
  • Deux APN différents, un PGW pour accéder à Internet et un PGW pour accéder à l’IMS.

Principe général

Je ne vais exposer ici que le principe général, l’un des points clés est la réservation de ressources entre le réseau LTE et la négociation au niveau de l’entité P-CSCF de l’IMS. Je conseille de suivre la formation Nexcom : De l’ingénierie radio au service voix pour avoir une formation détaillée sur la VoLTE, l’IMS le RCS, et les services.

Pour comprendre le principe du VoLTE, il est nécessaire d’avoir des notions sur :

  • Le réseau IMS et la signalisation téléphonique SIP
  • Le réseau coeur 4G  et réseau d’accès – SAE – LTE
  • La SIG 4G et la mise en place de bearer (défaut et dédié)
  • La négociation de codec (SDP) et la réservation de ressource (PCRF – SPR)

Phase 1 : Procédure d’attachement – Création du Default bearer 

Lors de la procédure d’attachement, le MME met en place un bearer par défaut entre l’UE et le PGW permettant l’accès au réseau IMS. Le bearer par défaut est défini avec une QoS définie par son QCI=5.

defaultbearer_ims

On suppose que le PGW permet d’accéder au réseau Internet et au réseau IMS.

La mise en place du bearer est réalisé via de la SIG 4G permettant la création d’un contexte S5 entre le SGW et le PGW, d’un context S1 entre le SGW et l’eNb et d’un context RAB entre l’UE et l’eNb.

Phase 2 : Signalisation Téléphonique – Enregistrement

Une fois le context crée, l’UE s’enregistre au niveau de l’IMS. Il envoie une requête SIP REGISTER au PGW qui le transfère au premier point de contact du réseau IMS (P-CSCF). Ce dernier redirige la requête vers l’I-CSCF et après avoir définie les capabilités du serveur d’enregistrement au niveau du HSS, l’I-CSCF récupère l’adresse du serveur S-CSCF. Suite à des échanges de SIG Téléphonique SIP (Register, ACK, …) l’UE s’enregistre au niveau du S-CSCF.

Phase 3 : Signalisation Téléphonique – Appel

En règle général, le context S1 et RAB sont relâchés, à moins que l’utilisateur passe immédiatement un appel téléphonique après avoir allumé son portable.

Dans le premier cas, il faut re-établir le context RAB et S1. Une fois le context EPS Bearer default construit, l’UE envoie des requêtes SIP (Invite, …) pour demander la mise en relation avec son correspondant.  La requête SIP INVITE permet de chercher à joindre le correspondant et négocier le type de codec pour l’appel (SDP).

Lorsque le réseau IMS a négocier le type de codec (autrement dit la Bande Passante à garantir), le réseau LTE doit mettre en place un bearer dédié sur lequel la voix sera routée.

Phase 4 : Création du bearer dédié

On parle de Bearer Dédié car le bearer se différencie du bearer par défaut uniquement par la QoS (QCI=1). En effet, les adresses IP/Sources sont les mêmes.

La création du bearer dédié est réalisée par de la SIG 4G (Message NAS ESM PDN Connectivity entre l’UE et le MME puis Création des bearer : Create Session Request, S1-AP Bearer Setup Request, RRC connection Reconfiguration Request)

Dedicated_bearer

Si au cours de l’appel l’UE souhaite transmettre un média (document, tchatter) ou activer la vidéo, le réseau 4G mettra en place un autre bearer dédié (selon la disponibilité, les priorités et la pré-emption).

CSFB : Call Switch FallBack (2)

Dans le précédent article, CSFB : Call Switch FallBack (1), je vous ai présenté le mécanisme de CSFB avec comme exemple un MTC.

De manière général, le call flow est le suivant :

CSFB_callflow_complet

Le point critique du CSFB est la durée du processus, et principalement le temps mis par l’UE pour quitter la connexion 4G et se retrouver connecté en 3G.

CSFB_time1

Ces chiffres ne reflètent pas la réalité, cette figure est extraite d’un document Huawei qui propose une autre technique nommée Ultra-flash CSFB.

Il y a en réalité plusieurs mécanismes qui ont été proposés pour se rapprocher de la durée de connexion de service téléphonique sur le réseau 2G qui sont :

  • Redirection
    • Basic
    • SIB Skipping
    • SI Tunneling
  • Handover

Différences entre handover et redirection

Dans le cas de la procédure de Handover, la cellule cible Nb est informée (selon le type de Handover, soit par le RNC, soir par le MSC/VLR) de la prise en charge d’un UE. Des mesures inter-RAT (IRAT : Radio Access Technology) permettent à l’UE de mesurer la puissance du signal des cellules pouvant prendre en charge l’UE afin de guider le HandOver (HO). C’est au cours de la requête RRC Connection Reconfiguration (optional Measurement reports) que l’eNb demande à l’UE de lui fournir des mesures sur les cellules voisines.

Dans le cas de la procédure de Redirection, l’UE est informé du réseau d’accès sur lequel il doit se re-connecter, mais le réseau n’est pas informé. Par conséquent, l’UE est dans l’obligation de trouver des informations sur sa nouvelle cellule. Ainsi, une fois sur la cellule, l’UE initie des mesures de puissance des fréquences  balises puis, récupère les informations SIB diffusées en broadcast par la cellule cible.

Parmi les deux technique, les mesures ont montrées que la procédure de redirection est plus rapide que le HandOver pour le GSM, mais à l’inverse est moins rapide en 3G.

CSFB_time

Le tableau met en avant différents mécanismes de redirections déjà évoqués dans l’introduction de l’article à savoir :

  • Basic
  • SIB Skipping
  • SI Tunneling

Redirection Basic

R8  Release with Redirection—Basic, l’UE récupère et interprète l’ensemble des SIB avant de faire la demande de connexion à la cellule cible.

SIB Skipping

R8 Release with Redirection—SIB Skipping
(3G), l’UE n’a pas besoin de lire tous les SIB mais seulement les SIBs 1, 3, 5 et 7, en ignorant les autres SIB. Toutefois, les informations concernants les cellules voisines et transmises sur le SIB11 et SIB 12 ont été transmises à l’UE lors des messages de mesure de contrôle et transmise par le Nb une fois l’UE connecté.

R9 Enhanced Release with Redirection—SI
Tunneling

Les informations SIB de la cellule cible sont transmises via un tunnel dans le message RRC Connection Release transmise par l’eNb source.

La solution déployée à ce jour est la redirection basique ou SIB Skipping.

Nous présentons ici le cas du R8  Release with Redirection—Basic

CSFB_rrc

Dans cette capture, on s’aperçoit que finalement le délai apporté par le CSFB est de 3 secondes et 457 ms (jusqu’au Alerting)

CSFB : Call Switch FallBack (1)

Bien qu’aillant déjà consacré 2 articles sur le CSFB (http://blogs.univ-poitiers.fr/f-launay/2014/03/14/technologie-de-transport-de-la-voix-en-4g-csfb/ et http://blogs.univ-poitiers.fr/f-launay/2014/03/20/technologie-de-transport-de-la-voix-en-4g-csfb-part-2/) je vous propose d’expliquer à nouveau l’interet du CSFB et le fonctionnement de celui-ci via des call flow. Je finirai par presenter plusieurs techniques pour réduire le temps de basculement du réseau 4G vers le réseau 3G.

Le CSFB est un mécanisme permettant aux téléphones couvert par le 4G de se replier sur le réseau 2G/3G (plutot 3G) pour pouvoir passer un appel : La 4G étant un réseau tout IP, la voix est vue comme un service réseau, nécessitant la mise en place de l’IMS Mobile pour permettre la voix sur LTE dénommée VoLTE (qui fera l’objet d’un autre article). La VoLTE arrivera en septembre chez Orange et Bouygues, et fera prochainement l’objet de plusieurs articles.

Lorsque vous êtes couvert par la 4G, pour savoir si la fonctionnalité CSFB ou si le VoLTE est activé, regardez l’icône réseau. Normalement vous devriez voir le symbole 4G. Passez un appel, si vous voyez apparaitre le symbole 3G (ou 3G+ ou H+), alors votre téléphone est passé en 3G, si le symbole est 4G alors vous êtes en VoLTE.

CSFB (Circuit Switched Fallback):- est une fonctionnalité spécifiée par le 3GPP pour fournir à l’UE les services à commutation de circuit traditionnel (comme la voix, les SMS..) lorsque ce dernier est attaché au réseau de voix 4G.

Les fonctionnalités CSFB doivent être implementées au niveau de l’UE, du MME, du MSC/VLR, et du HSS : lorsque l’UE s’attache au PLMN, il effectue un attachement combine sur le MME et le VLR. Une nouvelle interface, nommée SG, est aussi créée entre le MME et le VLR.

CSFB_principe

Pourquoi un attachement combine – IMSI Attach, EPS Attach ?

On suppose que le mobile est attaché au réseau 4G uniquement. Un appel arrive dans le domaine CS, la demande est soumise au GMSC qui interroge le HLR/HSS. Pour ce dernier, l’UE n’est pas connecté au réseau 2G/3G (rattaché à aucun VLR), l’appel est donc renvoyé à la messagerie

Comment est réalisé l’attachement conjoint?

Pour plus d’information, se référer au document 3GPP TS 23.272

Combined_attach

La question qui se pose maintenant est comment le MME peut dériver le VLR? N’y a t’il pas conflit de localisation?

Revenons sur l’article Pool MME (http://blogs.univ-poitiers.fr/f-launay/2015/05/16/pool-de-mme/), le MME gère plusieurs TA (Tracking Area), mais lorsque l’UE est en mode connecté le MME sait précisément sur quelle TA il se trouve. Le MSC quant à lui localise l’UE sur  une LA (Location Area). La couverture d’une TA est plus petite qu’une LA pour avoir de bonnes conditions radios et assurer un SNR minimum compatible avec le debit espéré. Donc plusieurs TA sont regroupées dans une LA. Il suffit à l’opérateur d’éviter tout chevauchement de TA sur deux LA pour qu’il n’y ait pas ambiguïté.

Donc, une LA est découpée en plusieurs TA et aucune TA chevauche deux LA. Il n’y a donc plus de conflit de derivation de VLR, une TA n’appartenant qu’à une seule LA.

DoCoMo_MME1_database

Fonctionnement présenté dans le cas d’un MTC

On suppose maintenant pour l’UE A, le double attachement EPS Attach et IMSI Attach. L’utilisateur B appelle l’UE A. Le GMSC transfère l’appel au MSC/VLR lequel, via l’interface SG, informe le MME du’un appel en cours (Paging). Le MME va rediriger l’UE du réseau LTE vers le réseau 3G.

CSFB_callflow

L’UE perd sa connexion au réseau LTE, le mobile cherche les informations SIB sur sa nouvelle cellule pour se rattacher au Nb. Une fois connecté au réseau 3G, la procédure de paging est transmise du MSC vers le Nb et l’UE demande une connexion au réseau CS. Lorsque l’appel est terminé, l’UE retourne sur le réseau 4G.