Bearer par défaut, bearer dédié et Application à la VoLTE

Bearer par défaut ou bearer dédié ?

Le bearer est un circuit virtuel qui s’établit sur le plan utilisateur (user plane) entre l’UE et la PGW (exemple circuit en rouge de la figure 1).

Figure 1 : EPS Bearer

L’association du flux IP avec le bearer est déterminée par un gabarit de trafic nommé filtre TFP (Traffic Flow Template). Ce filtrage est réalisé au niveau du PGW pour les paquets entrants et au niveau de l’eNb pour les paquets sortants. Le gabarit de filtre TFT s’appuie sur les adresses IP (source et destination), les numéros de ports (source et destination) et le protocole IP. Le SDF (Service Data Flow) correspond à un ensemble de flux IP associé à un service utilisateur avec la même QoS (par exemple, plusieurs flux IP provenant de site différents). Les flux ayant les mêmes caractéristiques de QCI/ARP (QoS Class Identifier et Allocation and Retention Priority) seront transmis dans le même bearer (cf. figure 2).

Figure 2 : Association d’un flux dans un bearer

Chaque entité du plan de transport du réseau 4G (eNb, SGW, PGW) a pour rôle de transmettre les paquets vers l’entité suivante. Les paquets sont transmis à travers un bearer entre deux entités. Le choix du bearer est défini de manière unique par un couple d’identifiants entre l’entité qui émet le paquet et l’entité qui reçoit le paquet. Cet identifiant est nommé TEID (couple : TEID_émission, TEID_reception) et la valeur du TEID est définie de manière unique au niveau de chaque entité. Par exemple, on suppose la création d’un bearer (par défaut) pour permettre un accès IP entre l’UE et le PGW. Le PGW crée un TEID=124 pour un bearer, et informe le SGW de son TEID. Le SGW sauvegarde le TEID du PGW et crée lui-même un numéro TEID (par exemple 2028 ou par coïncidence on pourrait aussi avoir un TEID 124 si ce numéro TEID n’existe pas au niveau du SGW, il s’agit alors d’une coïncidence avec une probabilité très faible) qu’il communique au PGW. Le SGW va créer un autre identifiant de bearer (par exemple le 11014) qu’il communique à l’eNB. L’eNb crée un numéro de bearer (ex : 100) qu’il communique au SGW.

Le SGW peut ainsi créer une table de contexte : Le TEID 2028 est associé au TEID 124 du PGW. Le TEID 11014 est associé  au TEID 100 du eNB. Le SGW fait l’association entre son TEID 2028 et le TEID 11014.

Exemple d’une table de contexte simplifiée au niveau du SGW

TEID_SGW TEID_entité @IP_entité Association TEID QoS
2028 124 @IP_PGW 11014 QCI=8 ARP
11014 100 @IP_eNb 2018 QCI=8 ARP

 

Ainsi, lorsqu’un paquet arrive sur le TEID=2028 du SGW, il associe le TEID=2028 au TEID=11014 et réalise l’action qui consiste à transmettre le paquet vers le numéro TEID=100 de l’entité dont l’adresse est @IP_eNb .

Le traitement des paquets est donc réalisé à partir d’une table de contexte, indiquant le « routage » à effectuer vers le TEID de sortie lorsque le paquet arrive par le TEID entrant. Cette table de contexte est créée par la signalisation 4G lors de l’attachement du mobile pour un bearer par défaut, ou déclenchée soit par le mobile soit par le PGW pour la création d’un bearer dédié. C’est ce que nous allons présenter dans cet article.

Par conséquent, nous allons dans cet article décrire le rétablissement d’un bearer par défaut et l’établissement d’un bearer dédié pour la mise en place d’une session. Afin de faciliter la compréhension de l’article, nous allons respecter un code couleur :

  • Message RRC en noir
  • Message EMM en bleu
  • Message ESM en vert
  • Les procédures en rouge

Cet article s’appuie sur le livre : VoLTE et ViLTE de M Perez André.

Procédure de demande de session

Lorsqu’un UE souhaite établir une session, il transmet au MME (il s’agit donc d’un message NAS) une demande d’établissement de session initiée par la sous-couche ESM. Les messages ESM seront encapsulés dans les messages RRC. Les messages RRC transportent également des messages NAS de la sous couche EMM. Les procédures seront définies par un code couleur rouge. Suite à la demande de création d’une session, le MME va déclencher l’établissement de bearer grâce aux protocoles RRC (bearer radio), S1-AP et GTPv2-C (respectivement pour la création du bearer radio, du bearer S1 et S5).

Cet  article s’appuie sur la spécification 3GPP TS 24.301

Rappel sur la mise en place du bearer par défaut lors de l’attachement.

Le default bearer est le bearer par défaut mis en place lors de la procédure d’enregistrement de l’UE (aussi nommée attachement de l’UE) : L’UE fait une demande d’attachement au MME, le MME sélectionne le PGW en fonction de l’APN de l’UE (l’opérateur doit s’assurer que l’algorithme de résolution d’APN au niveau du MME est correctement implémenté). En cas de roaming, le HSS peut notifier au MME de nouvelles données de souscriptions EPS (le HSS fournit donc un nouvel APN), permettant ainsi de réaliser un roaming selon le service LBO (Local Break Out, un contrat d’itinérance particulier). Le PGW fait une requête d’adresse IP au serveur DHCP et attribue une adresse IP permanente à l’UE (permanente signifie tant que l’UE reste attaché au réseau). Le PGW vérifie les valeurs des paramètres de QoS (QCI, ARP, GBR, MBR, AMBR) proposées par le MME (valeurs récupérées au niveau du HSS).

Comme nous l’avions déjà évoqué dans des articles précédents,  le bearer par défaut est un bearer sans débit garanti qui s’établit en même temps que la procédure d’attachement réalisée par la sous-couche EMM  : La sous-couche EMM de l’UE, lors de la demande d’attachement, envoie le message NAS ATTACH à la sous-couche RRC laquelle encapsule le message EMM dans le message RRC Connexion Setup. La sous-couche ESM demande en plus l’émission du message PDN Connectivity Request, comme le montre le tableau 1. Il s’agit d’une différence entre le réseau 3G et le réseau 4G, ce dernier profite de l’attachement pour demander la création de contexte de bearer et accélérer l’accès au réseau pour des demandes de sessions.

Se référer à l’article http://blogs.univ-poitiers.fr/f-launay/2015/05/19/emm-procedure-initial-attach-part-2/ pour plus de détail

Table 1 : RRC Connection Setup : ATTACH REQUEST

Après la procédure d’authentification (détaillé dans l’article …), le MME contacte le HSS (informe le HSS de la localisation du MME qui gère l’UE et le MME récupère le profil de l’UE dont les paramètres de QCI, MBR, …). A partir de cette information, le MME demande la création du bearer S1 et S5 (messages Create Session Request avec le SGW et Create Default Bearer Request portés par le protocole GTPv2-c et transmis respectivement au SGW et au PGW) avec la valeur de QoS du profil. Le PGW vérifie quant à lui les caractéristiques du bearer. Une fois les contextes de bearers S5 et S1 créés (ajout d’une nouvelle entrée dans la table de contexte avec un Identifiant de Chargement), le MME répond à la demande d’attachement de l’UE en transmettant via le protocole S1AP le message Initial Context Setup Request à l’intérieur duquel est encapsulé le message ATTACH ACCEPT et la demande d’activation du contexte de bearer par défaut (message ESM Activate Default EPS Bearer Context Request). L’eNb reçoit le message, rajoute l’entrée à sa table de contexte puis transfère le message EMM et ESM vers l’UE via le message RRC Connection Reconfiguration. Dans la description du message, on peut noter que le réseau indique les caractéristiques du bearer (QoS), l’adresse IP affecté au mobile, l’APN et l’adresse IP du PGW.

Table 2 : RRC Connection Reconfiguration : ATTACH ACCEPT et demande d’activation du bearer par défaut

L’UE répond par un message ESM Activate Default EPS Bearer Context Accept du message NAS ATTACH Complete encapsulé dans la réponse RRC Connection Reconfiguration

  • Etablissement d’une session sur le bearer par défaut : Ré-établissement du bearer par défaut

On suppose ici que l’UE est enregistré, les contextes de bearer ont déjà été créés au niveau du PGW et du SGW (via les messages Create Bearer du protocole GTPv2-c indiqués dans le paragraphe précédent). Ainsi, les paramètres de QoS sont déjà appliqués (remarquer le PGW lors de la création du bearer par défaut avait contacté le PCRF consécutivement à la requête CREATE SESSION REQUEST (etape 7 : http://blogs.univ-poitiers.fr/f-launay/2015/05/19/emm-procedure-initial-attach-part-2/). Par contre, suite à une période d’inactivité, la connexion S1 est libérée au niveau de l’eNb et l’UE n’a plus de ressources radios.

La première phase consiste à réaliser une connexion sécurisée entre l’UE et l’eNb  (RRC Connexion Establishment). La procédure RRC Connexion Establishment est la procédure permettant à l’UE d’informer le réseau qu’il souhaite établir une requête afin de passer de l’état RRC-Idle à l’état RRC-connect. Cette procédure RRC Connexion Establishment est constituée de trois messages : Le message RRC Connexion Request (UE vers eNb avec l’identité S-TMSI de l’UE), RRC Connexion Setup (eNb vers UE) suivi du message RRC Connexion Setup Complete (UE vers eNb). La sous-couche EMM de l’UE envoie le message NAS SERVICE REQUEST à la sous-couche RRC laquelle encapsule le message EMM dans le message RRC Connexion Setup Complete pour indiquer le type de session (session data, appel voix, réponse à un paging..). Le message est crypté en utilisant les clés de chiffrement connues depuis l’attachement (contexte de sécurité NAS comprenant les clés de chiffrement et d’intégrité NAS). La procédure d’authentification est optionnelle (pas d’authentification si la vérification d’intégrité du message est valide). L’eNb reçoit la requête NAS déclenchée par le téléphone et doit le re-transmettre vers le MME. Pour cela, l’eNB utilise le protocole S1AP et émet le message Initial UE Message. A ce stade, l’eNb crée une identité nommée eNb_UE_S1AP_ID pour identifier de manière unique l’UE. Il transmet alors cette information dans le message Initial UE Message et encapsule la requête NAS.

Lorsque le MME reçoit le message NAS Service Request (pour rappel ce dernier est déclenché par l’UE, reçue par l’eNB et retransmis par l’eNb), le MME démarre une procédure d’établissement du RAB, ce qui consiste à établir un lien DRB (Data Radio Bearer) et un bearer S1 entre l’eNb et le SGW.

  • MME –> eNb : L’établissement du contexte au niveau de l’eNb (seulement au niveau de l’eNb) est activé par le MME via le message Initial Context Setup Request. Le MME communique à l’eNb le numéro de tunnel TEID du SGW et les clés de chiffrements et les informations sur la QoS (UE-AMBR, GBR, MBR). Le MME encapsule dans ce message le NAS SERVICE ACCEPT à destination de l’UE

Table 3 : Paramètres échangés dans le message Initial Context Setup Request

Figure 3 : Initial Context Setup Request – Source EventHelix.com

  • eNb <-> UE : L’eNb accomplit une procédure de sécurité AS (afin de dériver les clés de chiffrement des données et d’intégrité sur la couche radio RRC) puis établit le bearer radio avec l’UE en 2 étapes grâce aux messages RRC suivants :
    • eNb -> Ue : message RRC Connection Reconfiguration. L’eNB alloue une identité DRB pour identifier le bearer
    • Ue -> eNb : Message RRC Connection Reconfiguration complete. L’UE confirme l’établissement de la connexion radio (SRB2, DRB)

Ces deux étapes (Sécurité AS – SRB et DRB, puis RRC Conn Rec) correspondent à la procédure Radio Bearer Establishment au niveau du call flow. Cela permet de modifier/configurer la connexion RRC.

A partir de ce moment, les données de trafic de l’UE peuvent être transmises vers le réseau (SGW et PGW). Le lien Uplink DATA est établi, mais pas le lien Downlink car le SGW ne connait pas l’identifiant de tunnel TEID de l’eNb. L’eNb attribut donc une identité du bearer S1 eNB TEID afin de transmettre cette identité au SGW.

L’eNb informe le MME de l’identifiant de tunnel crée pour ce flux de données dans le message Initial Context Setup Response (7) (consécutif donc au message Initial Context Setup Request). Le Message Initial Context Setup Response  contient les informations suivantes : Les Eléments d’Information de la couche Radio de l’UE, l’indicateur CSFB et SRVCC. Le MME informe ensuite le SGW de cet identifiant de tunnel via le message Modify Bearer Request (8). Le SGW doit donc répondre au MME pour lui confirmer l’activation du contexte de bearer par le message Modify Bearer Response (12). Les données de l’UE ayant été transmise via le lien Uplink, si l’UE s’est déplacé, le mécanisme de handover pour la partie Data (Plane User) permet la continuité du trafic montant. Par contre, le plan de contrôle doit aussi prendre en compte cette modification. Ainsi, si le type de RAT a changé (localisation du mobile sur la cellule – ECGI ou de TAI), il faut en informer le PGW via le message Modify Bearer Request (9), et si les règles PCC ne sont pas des règles prédéfinies (règles dynamiques), le PGW contacte le PCRF pour définir s’il faut modifier les règles PCC en fonction du nouveau RAT.

Figure 4 : Rétablissement du  bearer par défaut (référence : TS 23.401, chap 5.3.4.1 UE triggered Service Request)

  • Création d’un autre bearer : Bearer par défaut ou bearer dédié ?

Si une application de l’UE nécessite l’accès à un autre PGW alors, un deuxième bearer par défaut doit être construit (sous condition d’avoir les droits  au niveau du PGW). Dans les faits, l’UE lance une demande de connectivité PDN Connectivity Request vers le MME en précisant l’APN et la QoS, si la résolution au niveau du MME conduit au choix d’un autre PGW, la demande de connectivité sera établie vers ce PGW.

Figure 5 : UE requested PDN connectivity procedure

Attention, un même PDN peut être associé à plusieurs APN. Ainsi, si une application avec la même QoS nécessite une APN différente laquelle renvoie vers le même PGW, il n’y aura pas de création d’un nouveau bearer par défaut. Par contre, si les caractéristiques de QCI sont différentes, alors le réseau va créer un bearer dédié (l’UE peut avoir deux bearer par défaut ayant le même QCI mais avec des ARP différents).

Pour résumer, des bearers dédiés devront être établis si l’EPC décide de mettre en œuvre d’autres caractéristiques de bearer (GBR ou nouvelle valeur de QCI, ce qui nécessite la création d’un autre tunnel et par conséquent la sauvegarde de nouveaux contextes de bearer au niveau du PGW, SGW et eNb).

  • Création d’une session avec une QoS spécifique (Création d’un bearer dédié initié par l’UE)

On suppose le cas suivant : L’utilisateur souhaite lancer une session vers le PGW défini lors de la procédure d’attachement mais avec une valeur de QCI différente de celle définie pour le bearer par défaut. Si l’UE est au repos (mode ECM-Idle/RRC Idle), il doit activer la connexion RRC via la procédure RRC Connexion Establishment (pour rappel la procédure RRC Connexion Establishment est la procédure permettant à l’UE d’informer le réseau qu’il souhaite établir une requête c’est-à-dire pour passer de l’état RRC-Idle vers l’état RRC-connecte). La procédure procédure RRC Connexion Establishment est constituée de trois requêtes : Le message RRC Connexion Request (UE vers eNb), RRC Connexion Setup (eNb vers UE) suivi du message RRC Connexion Setup Complete (UE vers eNb). Dans ce dernier message, la couche RRC encapsule le requête EMM NAS Service Request afin d’établir une connexion sécurisée entre l’UE et le MME (procédure EMM).  Puisque l’UE souhaite établir un bearer dédié, il est nécessaire d’établir une connexion ESM, laquelle nécessite l’encapsulation du message NAS ESM Bearer Ressource Allocation Request délivré avec le message RRC Connection Reconfiguration. Nous avons déjà évoqué le message RRC Connection Reconfiguration lors de la procédure d’attachement avec encapsulation d’un message NAS, mais nous avons aussi vu que le message RRC Connection Reconfiguration permet aussi de définir des paramètres sur l’établissement du lien radio (PHR, DRX, …) Ici, l’UE est déjà attaché, par conséquent seule la sous-couche ESM encapsule la demande de création d’un bearer dédié.

Dans cette requête, l’UE envoie le QCI et le GBR, MBR désiré pour le lien UL et DL. Le MME reçoit le message et le transmet au SGW puis au PGW via le protocole GTP-C.

Figure 6 : Création d’un bearer dédié initié par l’UE

le PGW contacte alors le PCRF via Diameter. La requête CC-Request contient l’identifiant IMSI du mobile et la QoS demandée. Le PCRF regarde les détails dans sa table de souscription pour confirmer ou modifier la QoS demandée par le mobile ou contacte le SPR pour avoir le détail de la souscription du mobile.

Le réseau répond à la demande de l’UE par l’activation d’un bearer ou la modification du contexte d’un bearer, éventuellement d’un rejet de la demande.

Figure 7 : Activation d’un bearer dédié

 

  • Modification d’une session avec une QoS spécifique (Modification d’un bearer dédié)

L’UE va émettre le message Request Bearer Ressource Modification vers le MME. Cette requête permet à l’UE de demander une modification du bearer (modification d’un bearer par défaut, demande de création ou libération d’un bearer dédié). Si la demande est acceptée par le MME, ce dernier va mettre en place une procédure d’activation de bearer dédié.

Figure 8 : Modification d’un bearer

L’activation (ou création) du bearer dédié correspond à la mise en place de contexte de routage de bearer au niveau des entités PGW, SGW et eNb. L’étape 5 est présenté sur la figure 8.

 

  • Etablissement d’un bearer dédié en cours d’appel : Création d’un bearer dédié initié par le réseau

On suppose maintenant qu’un flux existe sur un bearer par défaut (ex application sur un serveur IP comme YouTube ou MyGoogle) et l’utilisateur souhaite activer un service supplémentaire (par exemple payer une VoD avec une QoS associée).

Dans ce cas, le serveur VoD va informer le PGW de la présence d’un nouveau flux de trafic nécessitant une QoS spécifique. La fonction PCEF au niveau du PGW va décider la création d’un bearer dédié à partir des règles de PCC indiquées par le PCRF (QCI=1, GBR, ARP=1, …). Le PGW vérifiera le débit entrant du PDN vers l’UE

Le PGW va envoyer une demande de création d’un bearer dédié (via le message Create Bearer Request) vers le SGW puis relayé au MME. Le MME déclenche la procédure d’établissement d’un E-RAB via l’application S1 AP E-RAB Setup Request avec les caractéristiques de QoS définies par le PCRF.

L’eNb, en cas de non saturation, accepte la demande et informe l’UE de la demande d’un bearer radio via le message RRC Connection Reconfiguration, lequel encapsule le message NAS ESM Activate Dedicated EPS bearer.

Table 4 : RRC Connection Reconfiguration

Si le bearer est crée, on acquitte le MME par le message RRC Conn Reconf Complete, et le MME acquitte le PGW par le message Create Bearer Response, et enfin le PGW informe le PCRF.

Figure 9 : Création d’un bearer dédié à partir d’une application utilisant le bearer par défaut (sur une connexion existante)

Application à la VoLTE

Ce paragraphe exploite l’article suivant : https://www.linkedin.com/pulse/dedicated-bearer-setup-lte-impact-volte-precondition-arindam-ghosh

  • Bearer par défaut dans le réseau Home

A l’allumage, le mobile démarre la procédure d’attachement. Si les données de souscriptions permettent d’identifier l’APN IMS comme l’APN pour le bearer par défaut sans autre APN alors le MME connecte l’UE vers l’APN IMS. La particularité de ce bearer est la valeur de QCI=5. Le MME fournit également l’adresse IP du P-CSCF à l’UE.

Si le mobile se connecte sur un APN non IMS au cours de la procédure d’attachement, alors il se connectera ultérieurement à l’APN IMS par une procédure d’établissement de bearer. Dans la procédure de demande de connexion PDN, le mobile informe l’APN IMS et demande l’établissement d’un bearer par défaut pour la signalisation téléphonique SIP. LE MME établit le bearer par défaut (QCI=5) et fournit l’adresse du P-CSCF au mobile.

  • Bearer par défaut dans le réseau Visité

Si le mobile est en roaming, la question est de savoir si le réseau visité supporte l’IMS.

  • Le réseau visité supporte l’IMS

On suppose évidemment que le réseau home supporte l’IMS (sinon la question ne se poserait même pas), alors le MME du réseau visité propose à l’UE de se connecter au PGW du réseau visité pour les appels voix et donc au P-CSCF du réseau visité.

  • Le réseau visité ne supporte pas l’IMS

On suppose évidemment que le réseau home supporte l’IMS (sinon la question ne se poserait même pas), alors le MME du réseau visité propose à l’UE de se connecter au PGW du réseau HOME et donc au P-CSCF du réseau Home mais le MME refuse les appels voix sur IMS. Toutefois, le mobile pourra utiliser le réseau Home IMS pour d’autres services comme par exemple le SMS.

  • Rétablissement du bearer par défaut pour transmettre les messages SIP

L’application VoIP échange des flux SIP vers le réseau IMS afin de joindre le correspondant appelé et de négocier les codecs si celui-ci est joignable.

  • L’appelant utilise le bearer IMS par défaut pour transmettre la signalisation SIP de demande d’invitation d’appel vers l’appelé (figure 1).
  • Le réseau IMS contacte le PGW de l’opérateur de l’appelé (données entrantes) pour transmettre la signalisation SIP vers l’appelé. Le réseau de l’appelé émet une requête de paging (non présenté dans cet article), l’UE appelé demande le rétablissement du bearer par défaut (figure 1).

L’UE appelant envoie dans le message SIP INVITE la liste des codecs compatibles vers l’UE appelé. L’UE appelé reçoit la liste des codecs et n’en retient qu’un. Il informe l’UE appelant du codec choisit.

  • Création du bearer dédié de l’appelant et de l’appelé.

A ce stade, l’appelant connait le type de codec, le réseau peut donc demander la création d’un bearer dédié avec le codec désiré et le réseau créé également un bearer dédié du coté de l’appelé.

  • Appelé : Figure 9 – Création d’un bearer dédié initié par le réseau
  • Appelant : Figure 9 – Création d’un bearer dédié initié par le réseau

Dans ce cas, l’AF (il s’agit du P-CSCF) informe le PCRF d’une modification de la session IP-CAN en indiquant les paramètres du nouveau bearer. Le PCRF envoie une requête IP-CAN session modification vers le PGW, lequel décide contacte le MME via une requête Create Bearer Request. Le MME analyse la demande et si elle accepte la demande, envoie un E-RAB setup request au eNb. Enfin, l’eNb envoie une requête RRC Connection Reconfiguration vers l’UE.

  • Fonction du PCRF

Dans les deux cas précédent, le PGW contacte alors le PCRF via Diameter. La requête CC-Request contient l’identifiant IMSI du mobile et la QoS demandée. Le PCRF regarde les détails dans sa table de souscription pour confirmer ou modifier la QoS demandée par le mobile ou contacte le SPR pour avoir le détail de la souscription du mobile.

Le PCRF peut recevoir des requêtes de la part d’une entité extérieure (AF : Application Function comme par exemple le P-CSCF) ou de la part du mobile afin de mettre en œuvre un service utilisant un bearer dédié (meilleure qualité que le bearer par défaut).

Dans tous les cas, le PCRF définie une règle PCC (préétablie ou établie à la volée) et retourne le QCI/ARP pour établir un bearer dédié. Il transmet aussi les paramètres de taxation au PCEF.

Si le PGW reçoit une valeur de QCI et un ARP tous deux identiques aux paramètres d’une session déjà en cours, alors le PGW demande la modification du bearer actuelle pour insérer ce nouveau flux (augmentation du débit). Le PGW réalise le mapping entre le flux de données (SDF : Service Data Flows) et le bearer correspondant.

Le PCRF assure aussi la fonction de Gating, c’est-à-dire peut bloquer un type de paquet ou tous les paquets (par exemple lors du dépassement de son forfait) au niveau du PGW.

La fonction Gating est une fonction qui détermine si oui on non un paquet peut traverser le PGW.

 

Mécanisme DRX en mode connecté et en mode idle. Extension à l’eDRX et au PSM

Dans l’article précédent, Allocation de ressources et scheduling, nous avons vu que l’eNB transmet dans la zone PDCCH des informations de contrôle DCI vers l’UE, comme par exemple le DCI 1A, informant l’UE de l’emplacement des données sur le PDSCH destinée à l’UE.

La sous-trame est composée d’une paire de slot. Un slot est découpé en RB, chaque RB est composée de 12 porteuses et de 7 symboles. Le PDCCH correspond à un zone de 1 à 3 symboles (la valeur est défini par le PCFICH) du premier time-slot (pour une bande d’au moins 3 MHz) sur toutes les RB de la bande. Le reste porte les données utiles (PDSCH)

Pour prendre connaissance de l’allocation des données, l’UE doit lire le DCI toutes les 1 ms pour ne pas rater l’allocation proposée par l’eNb :

RRC connected

Figure 1 : Lecture du PDCCH en mode connecté et DRX en mode de veille

1 – DRX : La réception Discontinue

Afin de réduire la consommation de puissance dans l’état RRC Connected et RRC Idle, il existe un mécanisme propre au LTE consistant à éteindre le module RF de l’UE pour le rallumer périodiquement afin de monitorer le canal PDCCH. On appelle cycle DRX (cf. figure 2), une période pendant laquelle le module de transmission est au repos (DRX sleep) alternée d’une période d’activité (DRX Active State). C’est au cours de cette période d’activité que l’UE scrute le PDCCH et effectue les mesures sur les cellules voisines.

fig2Figure 2 : Cycle DRX

Les valeurs du cycles DRX varient entre 2 ms et 640 ms. Le cycle est composée d’une période de repos (DRX Sleep) au cours de laquelle la chaîne de réception RF est éteinte et d’une période de scrutation (ON Duration). La valeur de la période d’activité est comprise entre 1 et 200 ms (donc la valeur de repos se calcule facilement). Ces valeurs sont fixées par l’eNb. Pour que l’UE prenne connaissance de ces valeurs, l’eNb transmet dans le SIB2 les informations de configuration du PCCH comprenant les indicateurs suivants :

  • OnDurationTimer indique le nombre de sous-trame pendant laquelle l’UE écoute le PDCCH
  • DRX Inactivity Timer indique la période pendant laquelle l’UE doit rester en état connecté (le mode DRX est inactif donc l’UE est en phase de réception). Ce timer démarre lorsque l’UE détecte, lors de la phase d’écoute du PDCCH, une information DCI le concernant, par exemple une allocation de données DL ou UL à venir. Le DRX Inactivity Timer doit être suffisamment long pour que l’eNb puisse avoir le temps de préparer le séquencement (l’allocation) des données. La valeur du timer varie de 1 ms à 2,56 secondes
  • HARQ RTT Timer : Indique la durée en TTI pendant laquelle l’UE est susceptible d’attendre un HARQ de la part de l’eNb
  • Short DRX Cycle/Long DRX Cycle  est la durée d’un cycle DRX court (période de scrutation pendant la période OnDurationTimer et période de repos). Le compteur OnDurationTimer démarre à chaque cycle DRX.
  • DRX Short Cycle Timer indique la durée en TTI pendant laquelle l’UE suit le cycle DRX court. La durée DRX Short Cycle Timer est un multiple du Short DRX Cycle. L’UE va suivre une phase composée de plusieurs cycles court consécutifs à la fin du Timer d’inactivité DRX. Cela signifie que si l’UE décode un DCI, il est en état d’écoute pendant la durée DRX Inactivity Timer et en fin de cette période, il entre dans un cycle DRX court qui se répète plusieurs fois. Le nombre de cycle court est égal à la fraction DRX Short Cycle Timer / Short DRX Cycle.

Le cycle court est optionnel,et dépend de la configuration du DRX Short Cycle Timer. Si celui-ci n’est pas configuré, l’UE n’exécute que des cycles longs.

fig4Figure 3 : Paramètres DRX

Au cours de l’état RRC-Connected, l’UE va périodiquement scruter les canaux PDCCH et se mettre en état de repos entre deux scrutations (DRX Sleep, DRX On). Sur la figure 4, on suppose qu’en fin de Timer DRX Inactivity Timer, l’UE suit deux cycles court et trois cycles long avant de passer en état déconnecté.

fig6

Figure 4 : Cycle Long/Cycle Court

Exemple d’application de la procédure DRX en mode connecté.

  • L’UE se réveille et pendant la durée du Timer OnDurationTimer décode le PDCCH
  • Si l’UE reçoit une commande DCI sur le canal PDCCH, il décode le bloc reçu et déclenche la temporisation d’inactivité DRX. Le rôle de ce temporisateur est de maintenir l’UE en état d’éveil pour que l’eNb puisse envoyer des allocations de ressources pour le sens descendant (l’eNb peut ainsi ordonnancer les données à transmettre vers l’UE sur plusieurs TTI consécutifs). A chaque allocation d’un DCI sur le PDCCH (de nouvelles données), le Timer redémarre.
  • Si l’UE ne parvient pas à décoder le bloc de données reçu, il démarre le timer HARQ RTT (permettant la retransmission du bloc, la durée pour  le FDD est de 8 ms)
  • A la fin de l’expiration du timer DRX-InactivityTimer, l’UE démarre un ou plusieurs cycles DRX court. Le nombre de cycle court consécutif est compris entre 1 et 16. Le cycle court a une durée DRXShortCycle dont la durée varie de 2ms à 640 ms, par conséquent la durée totale des cycles courts s’étend jusqu’au plus 16*640 ms soit 10.24 s. Cette période s’appelle DRXShortCycleTimer. Durant le cycle court, l’UE réalise deux fonctions :
    • Analyse du canal PDCCH sur la durée OnDurationTimer
    • Si l’UE ne décode aucune information sur le PDCCH, il entre en mode de veille jusqu’à la fin du temporisateur DRXShortCycle
  • A la fin du Timer du cycle court (DRXShortCycleTimer), l’UE bascule dans un cycle long

Les figures 4 et 5 présentent un schéma pour lequel le cycle DRXShortCycleTimer se compose de 2 cycles courts.

fig5Figure 5 : Exemple de cycle DRX

A la fin de la procédure, s’il aucune activité n’est détectée, l’UE passe dans l’état RRC_Idle, le cycle DRX est un cycle plus long. Le module RF est éteint sur une longue période et ne sera activée que pour détecter des éventuels paging. On parle de cycle de Paging DRX.

2 – DRX en mode Idle : Introduction au Paging

Un UE présent sur une cellule du réseau cellulaire est en mode de veille lorsqu’il n’a pas de connexion activée avec la station de base (on dit que le mobile est dans l’état RR Idle si l’UE est campé sur le réseau 2G ou RRC Idle dans le cas ou l’UE est campé sur le réseau 3G ou 4G). Ainsi, si le coeur réseau mobile (2G/3G/4G) souhaite communiquer avec un UE (appel téléphonique en Commutation de Circuit -2G/3G- ou en commutation de paquet via une requête SIP -4G-, un message court, une authentification, un PUSH Data, une notification d’alerte), l’entité du coeur réseau qui gère l’UE émet un message de Paging.

La procédure de Paging est réalisée dans l’un des 4 cas suivants :

  • Informer l’UE d’une terminaison d’appel en commutation de circuit
  • Informer l’UE d’une terminaison de session en commutation de paquet
  • Déclencher l’UE pour faire une lecture d’un SIB
  • Notifier l’UE d’information sur la sureté civile (ETWS Earthquake and Tsunami Warning System)

Si on se place dans le réseau 4G, la notification de Paging (message RRC de paging) est transportée par le canal logique PDCCH. La notification de paging est broadcastée par la cellule avec l’identifiant P-RNTI. Comme l’identifiant P-RNTI est commun à tous les UE (la valeur de l’identifiant est fixe : 0xFFFE ; et le P-RNTI est transmis sur l’espace de recherche commun du canal PDCCH), tous les terminaux vont donc être notifiés d’une procédure de paging. Chaque UE doit alors décoder le canal PDSCH (l’information de paging est contenue sur le PDSCH et se trouve sur les RB indiqués par le PDCCH) pour savoir si le paging le concerne (au message de paging utile est ajouté un code correcteur d’erreur CRC lequel est codé par l’identité S-TMSI du mobile concerné. Le codage est effectué par un OU logique).

En général, la procédure de Paging est initiée par le MME, et par conséquent la procédure s’applique lorsque l’UE est dans l’état EMM-IDLE,  ce qui signifie que l’UE est aussi dans l’état RRC-Idle (se reporter à l’article Etat RRC – EMM). Cependant, la demande de paging peut aussi être initiée par l’eNB dans les deux cas particuliers évoqués ci-dessus :

  • L’eNB génère une procédure de paging en cas de modification des informations SIB (exemple de congestion avec une modification de la classe d’accès).
  • L’eNB génère une procédure de paging en cas d’événement ETWS

Lorsque le paging est initié par l’eNb, l’UE peut être à l’état RRC-Connected.

Quand la procédure de paging est initiée par le MME, l’UE est forcément en état de veille (sinon le MME initierait éventuellement un RAB supplémentaire via un message RRC avec l’eNB sur lequel est connecté l’UE donc pas de paging). Lorsque l’UE est en veille, il est localisé par le MME sur une zone étendue (TAI). Ainsi, tous les eNb concernés (inscrit sur le même TAI que la dernière position de l’UE) autrement dit toutes les cellules définies avec le même TAI (soit entre 100 et 500 cellules) transmettront le message de paging. Sans aucune optimisation, chaque UE doit scruter toutes les 1 ms, l’espace commun du  PDCCH pour prendre connaissance d’un indicateur du message de Paging et décoder le PDSCH pour savoir s’il est à destination du paging.

Lors du décodage du message de paging (PDSCH : message + CRC codé), si le CRC décodé avec l’identité S-TMSI de l’UE est cohérent avec le message de paging, alors l’UE est destinataire du message et va prendre connaissance de la raison de la demande de connexion (Paging Cause) afin d’initialiser la procédure appropriée avec le cœur réseau. L’UE passe alors de l’état RRC_Idle à l’état RRC_connected (avec le DRX correspondant au cycle expliqué dans le paragraphe 1)

3 – La procédure de Paging

La durée du cycle Paging DRX est soit définie par la cellule (SIB2 dans le paramètre PCCH : defaultPagingCycle nommé Tc dans le tableau ci-dessous) soit imposée par le MME si ce dernier transmet un message NAS (UE specific DRX cycle) à l’UE pour lui indiquer la durée spécifique du cycle DRX. La durée maximum du cycle est de 2.56s, valeur maximum du paramètre Long DRX Cycle (figure 2), les valeurs du tableau s’exprime en durée trame (10 ms).

Tableau paramètres DRX

Tableau 1 : Paramètres DRX

Ainsi, T=T_UE ou T_C en fonction du choix du cycle DRX. Si Tc=128, alors le cycle DRX est configurée pour 1.28 secondes (1 trame=10 ms).

nB est un paramètre qui définit le nombre de PO (Paging Occasion) par cycle DRX autrement dit le nombre de fois que l’UE écoute le canal PDCCH pour détecter un Paging.

1er cas : nB<T

Si nB=T/32 avec T=128  alors il y aura 4 PO durant le cycle de 1,28s soit un PO toute les T/32 trames. La trame qui va porter le message de Paging n’est évidemment pas aléatoire. Pour synchroniser l’UE et l’eNB à l’émission/réception d’un message de Paging, le MME transmet à l’eNb le paramètre UE_ID (UE Identity Index Value) via le protocole S1_AP, sachant que UE_ID=IMSI mod 1024. L’UE calcule de son coté la valeur UE_ID, le paging pour un UE est donc sur une trame dont le numéro de trame (SFN) dépend de l’IMSI.

Numéro des trames SFN portant un Paging = 32*(UE_ID mod 32). Le compteur est remis à 0 à chaque cycle donc :

PFN =SFN modulo 128

Le calcul est différent si nB>T.

2ème cas : nB>T

Si nB=2T, alors on aura 256 PO par cycle DRX (2 PO par trame), 1 PO toutes les 5 ms.

Numéro des trames SFN portant un Paging = 256*(UE_ID mod 128). Le compteur est remis à 0 à chaque cycle donc :

PFN =SFN modulo 128

Formule Générale : On pose N=min(T,nB) :

  • SFN = (T div N)*(UE_ID mod N)
  • PFN = SFN mod N

Il ne reste plus qu’à déterminer la sous trame portant le Paging (PO). On pose Ns=max(1,nB/T)

i_s = floor(UE_ID/N) mod Ns

Application :

1er cas : nB<T :  Ns=1, donc is prend pour valeur 0 ou 1

2ème cas : nB<T  Ns=1, 2 ou 4 donc _s prend pour valeur 0,1 ou 2 ou 3.

La sous trame est définie par le tableau ci-dessous :

Sous trame portant le PO

Tableau 2 : Sous trame portant le PO

4 – Call Flow et étude simplifiée

Le call Flow présenté en figure 6 porte plusieurs informations que nous allons détailler, comme par exemple le mécanisme DRX (Discontinuous Receive cycle) sur lequel se synchronise le cycle de PO (Paging Occasion), le rôle du Timer T3413 et les messages.

Call Flow PagingFigure 6 : Call Flow Paging détectée par l’UE et spécifique à l’UE

II-a) Etat du téléphone

L’état du téléphone ne doit pas vous échapper, vous pouvez revenir sur l’article ETATS RRC – ECM EMM pour plus de détail.

Dans le cas du call flow, l’UE est dans l’état ECM Idle et RRC Idle, cela signifie qu’il n’a pas de connexion radio avec l’eNb.

Le téléphone est enregistré sur le réseau, il existe donc un contexte au niveau du MME, un contexte au niveau du PGW et le HSS connait l’identité du MME sur lequel l’UE est enregistré. En cas de session DATA en provenance du réseau (VoLTE  par exemple), le PGW sera en mesure de router les paquets vers le SGW et ce dernier informera le MME de paquets en attente.

II-b) Première lecture du call flow

Le MME va générer le message S1AP Paging et va ensuite démarrer le timer T3413. Ce Timer a pour rôle de limiter la période pendant laquelle le MME considère le message S1AP valide. Il s’agit donc du temps de réponse maximum autorisé pour que l’UE réponde au message S1AP.

Le message S1AP est transmis à une liste de eNB. Cette liste est connue par le MME car ce dernier maintient le contexte de l’UE (celui est attaché car l’UE est en état MME registered, les eNb concernés sont définis par le TAI), c’est donc le MME qui connait la position approximative de l’UE (Tracking Area ou TA List). Chaque eNb qui reçoit le message S1AP décode l’identité de l’UE (S-TMSI) et transmet la requête de paging sur l’accès radio.

L’UE destinataire recevant et décodant le message de paging répond à la requête en faisant une demande d’accès radio (procédure d’accès aléatoire : Random Access Procedure). Une fois l’accès radio mise en oeuvre, l’UE est en état connecté. Le Timer DRXInactivityTimer est déclenché, l’UE est en écoute jusqu’à la fin du Timer ou il se mettra en cycle DRX court puis long si rien ne se passe.

5) eDRX et Mode PSM – Power Saving Mode – Extension pour le MTC (IoT)

eDRX (R.13)

Dans le cas de l’IoT, la durée en mode de veille du cycle DRX est allongée et peut s’étendre jusqu’à 44 mn (Trigger eDRX Long Cycle) en prenant comme référence non plus la durée d’une trame, mais d’une hyper-trame H-SFN. L’Hyper-trame a une durée de 1024 trames soit 10.24 secondes. Il est donc nécessaire que l’eNb et le MME se synchronise sur le H-SFN.

A titre d’exemple, sur la figure 7 on représente le mode discontinue en mode de veille.

fig10Figure 7 :  Extension du timer -eDRX

Le eDRX s’applique pour l’UE dans l’état RRC-Idle et RRC-Connected. La figure 7 présente un exemple dans l’état RRC-Idle.

Les valeurs du trigger TeDRX (mode de repos) et TPTW sont indiquées au device lors de la procédure d’attachement ou de RAU sous le nom respectif T331 et T332 (Information Element lors du message RRC), mais la valeur eDRX peut aussi être broadcastée par l’eNb. L’UE prendra alors la plus petite valeur des deux.

PSM (R.12)

Le mode PSM est un mode pour lequel le device s’éteint sans faire la demande de détachement. Pour le mode PSM, le device utilise deux valeurs de triggers (T3324 et T3412) lesquelles lui ont été fournies lors de la procédure d’attachement ou de mise à jour de sa localisation (TAU). La première valeur de timer, le T3324 indique le temps pendant lequel l’UE reste en mode de veille suite à la procédure d’attachement (c’est la durée du mode DRX et est nommée Active Timer) et le deuxième Trigger est le temps pendant lequel le device est endormi avant une mise à jour périodique de sa localisation. Ainsi, la valeur du trigger T3412 correspond toujurs à la durée de la demande de Mise à Jour de localisation Périodique (periodic TAU). Durant cette période, le device reste attaché au réseau mais est non joignable : Il ne lit aucune signalisation, et par conséquent, le MME ne doit envoyer aucun message. Le MME enregistre l’état du device (enregistré et non localisé). La durée maximum du trigger T3412 pour le mode PSM est de 12,1 jours, mais le device peut à tout moment interrompre ce mode en émettant une requête de TAU (Mobile Originated Transaction).

Mode PSM

Figure 8 : Mode PSM

Figure 9  : Call Flow

Différence entre PSM et eDRX

Concernant les cycles DRX, l’UE et l’eNb sont synchronisés, autrement dit l’UE connait les instants pendant lesquels l’UE est en écoute (DRX awake). Ainsi, si l’eNb doit adresser un message au mobile (allocation par exemple) sur le PDCCH, il devra attendre la période de réveil pour séquencer l’UE, ce qui introduit un peu de latence. Les transmissions Uplink ne sont pas affectées par le DRX puisque l’UE peut à tout moment activé le module RF pour transmettre une demande d’allocation (Scheduling Request).

 

Les cycles DRX sont émis par le SIB 2, mais la couche MAC de l’eNb peut aussi contrôler les paramètres DRX de l’UE en transmettant des commandes MAC CE DRX.

Commandes MAC CE : MAC Contrôle Element est une structure MAC du LTE qui porte des informations de contrôle spécifiques entre l’eNb et l’UE comme le Timing Advanced, le PHR, les commandes DRX, …

 

Dans le mode PSM, le device fait une demande de TAU périodiquement. Lorsque le mobile est à l’état PSM, toutes ses fonctions non critiques sont désactivées, ce qui permet de consommer encore moins d’energie que l’UE en mode idle, et ceci tant que le Timer n’a pas expiré. En contrepartie l’UE est injoignable pendant toute cette phase. Le PSM est donc réservé uniquement aux UE en commutation de paquet qui n’ont pas à être déclenché.  La durée maximum du Timer T3412 est de 12.1 jours.

Dans le cas eDRX, le device scrute périodiquement le PDCCH sur une courte durée. Par conséquent, les devices susceptibles de recevoir des notifications du réseau (trigger) mais qui sont tolérants au délai seront programmé en mode eDRX devices qui fonctionnent plutôt en transmission de données (originated device) seront plutôt programmés en mode PSM.

fig12
Figure 9: Comparaison PSM/DRX

Pour aller plus loin : https://www.youtube.com/watch?v=wY7XHrbm1oQ

Cet article constitue aussi deux mécanismes de gestion de batterie sur lesquels nous reviendront dans un futur article traitant du MTC (Machine Type Communication).

Remerciement :

Merci à André PEREZ d’avoir contribué à la rédaction de l’article. L’article s’appuie sur le livre VoLTE et ViLTE

Merci à Louis Gibault d’avoir relu l’article et annoté des remarques

Allocation de ressources et scheduling

Dans cet article nous allons voir la signalisation émise par l’eNb pour informer l’UE de la taille du bloc de transport (TBS) alloué à l’UE pour transmettre ses données utiles (payload). La taille dépend de la qualité du lien radio (renseigné par l’UE via le CQI) et des ressources allouées par l’eNb à l’UE (scheduling).

Nous ne nous intéresserons pas ici à la procédure de scheduling mais uniquement à l’échange de signalisation pour informer l’UE de la taille et des ressources allouées pour transmettre ses données.

Allocation de ressources

La trame physique du LTE est partagée entre tous les utilisateurs, et nécessite la transmission de signalisation 4G sur des ressources blocs commun aux UES allouées au canal physique nommé  PDCCH* et l’échange de données sur des RB specifiques avec un format de modulation et de codage imposée par l’eNb et qui dépend des conditions radios.

Le mapping physique LTE (cf http://blogs.univ-poitiers.fr/f-launay/2013/08/27/rsrp-et-rsrq/) rappelle la répartition des ressources en temps et en fréquence entre utilisateurs et la disposition de RB spécifique pour la gestion des ressources.

L’UE doit donc attendre l’ordre spécifiant :

  • Le Time Slot sur lequel il va recevoir/émettre des données
  • Le RB (les blocs de fréquence) sur lequel il va recevoir/émettre des données
  • Le schéma de codage et de modulation (MCS) pour démoduler/moduler les données
  • La puissance d’émission

*Le canal PDCCH est le canal physique de contrôle dans le sens descendant qui porte les informations permettant à  l’UE de connaître les ressources qui lui sont allouées dans cette sous-trame (position des RB, format MCS) et des informations de contrôle permettant à l’UE de connaître les ressources et le schéma de modulation qu’il utilisera 4 TTI plus tard pour émettre ses données vers l’eNb.

Alloc_ressource_fig1

Figure 1 : Schéma général d’un échange d’information de contrôle

L’eNb doit donc transmettre de nombreuses informations vers chaque UE par un message nommé DCI  (Downlink Control Information). Le DCI est transmis soit à un groupe d’UE, soit spécifiquement à un UE afin de lui porter à connaissance l’attribution des ressources pour la transmission de ses données (payload). Dans ce cas, l’information portée par le PDCCH (et transmis en broadcast) est destiné à un seul UE. Pour savoir si le PDCCH lui est destiné, l’UE doit décoder le CRC avec ses identifiants RNTI (P-RNTI, C-RNTI, SPS-RNTI, RA-RNTI).  Toutefois, l’eNb doit aussi transmettre des informations systèmes destinées à plusieurs UE simultanément donnant ainsi des règles d’allocation suivant le mode de transmission de l’UE (la classe du terminal permet de définir ses capacités notamment sur la diversité de transmission, de réception et le MIMO). Dans ce cas, le CRC du PDCCH est codé avec la valeur du SI-RNTI.

Puisqu’un mobile ne peut deviner si un PDCCH lui est transmis, chaque UE qui n’est pas dans l’état discontinue (DRX) décode sur la sous-trame correspondante l’ensemble des CRC en fonction de ses identifiants RNTI. La taille allouée pour le PDCCH est néanmoins connue par le mobile sur un espace de recherche dit espace de recherche commun et son emplacement est toujours situé sur les premiers symboles OFDM. Quant à sa taille, elle est formée par l’agrégation de 1,2, 4 à 8 CCE sur lequel l’eNb transmettra respectivement 8 PDCCH, ou 4 ou 2 ou 1 (selon le format du PDCCH c’est  dire à la quantité d’information à transmettre). Sur l’espace de recherche commun, l’eNb transmet des informations système (SI-RNTI).

Lorsque le PDCCH est spécifique à un UE, on parle alors d’espace de recherche spécifique. L’emplacement de ce dernier est défini en fonction du RNTI de l’UE et du numéro de trame. Lorsque l’UE a reconnu un PDCCH spécifique, il répond en retour sur le PUCCH ou PUSCH. Il informe notamment  l’eNb de la qualité du lien radio via l’indication de la qualité du canal nommé CQI, ce qui permet à l’eNb d’adapter les paramètres de transmission à savoir :

  • L’efficacité du code correcteur.
  • Le type de modulation (QPSK, 16 QAM, 64 QAM).
  • Dans le cas du MIMO, les indicateurs RI et PMI.

Pour satisfaire aux différents besoins, il existe plusieurs formats DCI spécifiant le type d’information à transmettre (de taille par conséquent différent, ce qui revient à une allocation en terme de CCE différent) et décrites dans la norme 3GPP R8/R10 :

  • DCI Format 0 est utilisé pour informer l’UE de l’allocation des ressources sur la voie montante
  • DCI Format 1 est utilisé pour informer l’UE de l’allocation des ressources de la voie descendante lorsqu’il y a une diversité de transmission (MISO ou MIMO rank 1)
  • DCI format 2 est utilisé pour informer l’UE de l’allocation des ressources de la voie descendante pour le MIMO.
  • DCI format 3 est utilisé pour la transmission des commandes de contrôle de puissance (TPC commande) pour le canal de la voie montante.
  • DCI format 4 est utilisé pour informer l’UE de l’allocation des ressources sur la voie montante dans le cas MIMO

 

Pour un format donnée, les informations transmises dépendent du type de RNTI (P-RNTI, C-RNTI, RA-RNTI, …) et du mode de transmission. Ainsi , en se basant sur le mode de transmission,  la norme précise des sous-formats :

Alloc_ressource_tab1Tableau 1 : Format DCI et informations transmises

Nous avons précédemment dit que le PDCCH était décodé selon l’identifiant RNTI. Pour faire une synthèse, le tableau 2 reprend selon l’état du mobile (connecté, en veille)la liste les formats DCI correspondant en fonction du type d’identifiant :

Alloc_ressource_tab2Tableau 2 : Correspondances entre le type RNTI et les formats DCI compatibles

Entre la Release 8 et la Release 10, le 4ème format est apparu. Ce dernier est utilisé pour informer l’UE de l’allocation des ressources sur la voie montante en utilisant le multiplexage spatial, ce qui nécessite donc de transmettre davantage d’informations comparé au DCI format 0.

Alloc_ressource_tab3

Tableau 3 : Les différents formats selon la release

Mais, ce n’est pas la seule différence, car en effet, la R10 traite du LTE-Advanced laquelle autorise l’agrégation de plusieurs bandes de fréquences et par conséquent chaque format du R10 comporte un champ supplémentaire précisant la porteuse concernée.

Alloc_ressource_tab4

Tableau 4  : Les différents champs concernant les informations portées par le DCI selon la release pour le format 0

Alloc_ressource_tab5

Tableau 5  : Les différents champs concernant les informations portées par le DCI selon la release pour le format 2

 

 

Exemple

Alloc_ressource_fig2

Figure 2 : Exemple issu du site http://niviuk.free.fr/lte_dci_decoder.html

Le tableau donne des informations concernant la valeur hexadécimales du DCI. En remplaçant 2584A800 par 2585A800, la modulation est une 64QAM

(Cf Specification ETSI 3GPP TS 36.213 R8, Table 7.1.7.2, http://www.qtc.jp/3GPP/Specs/36213-920.pdf, la table TBS donne la taille 9144 à la ligne 22, colonne 18)

Alloc_ressource_fig3

Figure 3 : Exemple issu du site http://niviuk.free.fr/lte_dci_decoder.html

 

Comme dernier exemple, je vous propose de découvrir les informations contenues dans le PDCCH spécifiant le niveau de puissance

Alloc_ressource_fig4

 

Ref : http://blogs.univ-poitiers.fr/f-launay/tag/pdcch/ pour calculer le nombre maximum d’UE pouvant simultanément échanger des données avec l’antenne et le nombre maximum d’UE pour la VoLTE

http://www.sharetechnote.com/html/DCI.html

http://nitintayal-lte-tutorials.blogspot.fr/2013/05/all-about-pdcch-and-cce-allocation.html

 

 

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.