MTC : Le réseau M2M / IoT sur la 4G – 1ère partie

I – Introduction

Les opérateurs en France proposent aujourd’hui des solutions  de connectivité pour les objets (réseau de l’Internet des Objets qui sont des réseaux longues portées sans fil à basse consommation dénommés LPWAN– LoW Power Wide Area Network) en s’appuyant sur des infrastructures de réseaux bas débit comme LoRa (Long Range pour Orange/Bouygues) ou SIGFOX (SFR). Mais, en 2018 les technologies LTE-M et NB-IoT sont attendues (en France) et viennent compléter les offres LPWAN pour des uses cases nécessitant un plus grand débit et une meilleure réactivité par rapport aux réseaux tels que SIGFOX et LoRA.  En 2020, l’Internet des Objets sur la 5G apportera en plus une très faible latence (nouveaux uses cases sur les communications critiques) et dans l’idéal à très faible pertes de paquets (les opérateurs espèrent se rapprocher de la règle des 3 neufs).Cette infrastructure réseau MTC : MTC (Machine Type Communication ou eMTC) constitue le socle sur lequel va s’adosser l’IoT sur la 4G et la 5G.

Les spécifications du MTC sont décrites dans les releases 3GPP R10, R11 et R12. La 3GPP R.13 introduit la notion de eMTC.  La R14 introduit de nouvelles fonctionnalités dans l’architecture du réseau pour gérer le roaming (SCEF), pour optimiser le transfert de faible quantité de données (Ip ou non IP nommé NIDD).

L’objectif de cet article est de comprendre l’évolution de l’architecture du réseau 4G pour l’Internet des Objets (Cellular IoT). La R.13/R.14  pour le réseau 4G MTC propose des optimisations pour le transport de faible quantité de données. Je ne présenterai pas ici des mécanismes d’optimisation d’énergie (DRX, PSM) qui ont déjà été présentés dans un précédent article (http://blogs.univ-poitiers.fr/f-launay/2016/11/04/paging-et-mecanisme-psmdrx/).

Concernant le DRX, le principe consiste pour l’UE à ne décoder le PDCCH que périodiquement selon un cycle DRX constitué :

  • D’une période d’éveil (entre 1 ms et 200 ms) pendant laquelle l’UE décode le PDCCH et effectue des mesures sur les cellules voisines. L’UE est dans l’état RRC_Connected
  • D’une période de repos (sleep sta te)

On appelle cycle DRX l’enchainement de ces deux périodes, un cycle DRX à une durée qui est comprise entre 2 ms et 640 ms. Si l’UE décode un message lors de la phase d’éveil, il passe de l’état RRC_Idle à l’état RRC_Connected. Dans ce cas, il reste alors en phase d’éveil pendant une période d’inactivité DRX allant de 1 ms à 2.56 secondes.

Concernant l’eDRX, dans l’état RRC_Connected, le cycle est étendu à 10,24 secondes (1024 trames), dans l’état RRC_Idle, le cycle est étendu à 43mn54 secondes pour les terminaux de catégories M1 et à 2h54 mn pour  les terminaux NB-IoT.

Il est possible d’augmenter la durée de l’état dormant du dispositif sur plusieurs jours avec le mécanisme PSM – Power Save Mode. Les deux mécanismes sont résumés sur la figure 1 ci-dessous :*

Figure1 : PSM/DRX

Mais, pour plus d’explication, se référer à l’article : (http://blogs.univ-poitiers.fr/f-launay/2016/11/04/paging-et-mecanisme-psmdrx/)

II – Architecture, protocoles et procédures

II-1) Généralité de l’IoT et du réseau cellulaire 4G

Revenons au concept général du réseau cellulaire 4G. Les réseaux cellulaires ont été conçus pour séparer la couche de signalisation et la couche de transfert de données (payload utile). L’UE (déjà enregistré sur le réseau) contacte le MME afin de préparer le tunnel pour le transfert des données. Cette procédure de rétablissement de bearer (le bearer S5 existe, la procédure consiste à rétablir le bearer radio et le bearer S1) génère un trafic de signalisation. Dans le cas d’un usage humain (Internet, messagerie, vidéo, …) la signalisation engendrée par le rétablissement de bearer est faible par rapport à la quantité de données qui va être transportée par ce bearer.

Dans le cas de l’IoT, la taille du TBS (Transport Bloc Size) de l’UE peut être limitée à 1000 bits sur le lien montant et 680 bits sur le lien descendant (cat NB1). L’objectif de l’évolution du cœur radio, nommée EPS optimization consiste à réduire la signalisation en encapsulant de manière transparente les données dans un message NAS EPS transmis au MME. L’architecture CIoT présentée dans la R.13 a donc pour but d’optimiser le transfert de faibles quantités de données entre l’application IoT et le dispositif IoT même si le dispositif IoT ne dispose pas de pile protocolaire IP (stack IP non fourni dans le end-device). On parle alors de transmission NIDD (Non IP Data Delivery) que le réseau CIoT doit savoir gérer (TS 23.682).

II-2) Architecture du réseau Cellulaire 4G – IoT

L’architecture du cœur réseau 4G pour l’IoT, présenté sur la figure 2, intègre une entité supplémentaire nommée SCEF – Service Capability Exposure Function

Le SCEF est une entité destinée à sécuriser le réseau de l’opérateur vis à vis d’une requête extérieure (API). Les fonctions de bases sont :

  • Double authentification avec le device
  • Correspondance entre les identités privées (IMSI/IMPI) et une identité pubique
  • Autorisation ou non des services demandées par le serveur d’application (AS) du client
  • Gestion d’ACL
  • Génère des CRA

Figure 2 : Architecture générale

On peut noter en passant l’API qui est l’interface entre le réseau 3GPP et le serveur du client. C’est une nouveauté entre la R.12 et la R.13. Dans la R.12, l’entité SCEF n’existait pas, le client devait reveiller le dispositif via une requête DIAMETER vers l’entité MTC-IWF. L’entité MTC-IWF sera remplacée par le SCEF et le message DIAMETER par une API. Dans la R.12, le serveur client ne pouvait lancer qu’une procédure de reveil de device par SMS (on parle de procédure de trigger).

Revenons sur le principe d’optimisation du cœur réseau. La quantité de données à transmettre pouvant être faible, les données peuvent être acheminées de deux façons différentes :

  1. Via le plan de contrôle (MME) s’il y a peu de données : Control plane
  2. Via le plan de données (SGW/PGW) à travers un tunnel IP : User plane

Pour ce faire, les spécifications 3GPP définissent

  1. deux optimisations définies sous le nom :
  • Control plane CIoT EPS optimisation;
  • User plane CIoT EPS optimisation;

2 – trois nouvelles entités :

2-1) MTC-IWF : MTC Interworking Function (remplacé par le SCEF qui sera décrit dans un autre article

2.2) SCEF – Service Capability Exposure Function

2.3) C-SGN (CIoT Service Gateway Node).

3-Une nouvelle interface pour le transport de données entre le SGW et le MME : S11-U

Le SCEF est une passerelle sécurisée permettant à une tiers player non 3GPP d’être connecté au réseau opérateur par des API. Nous allons nous contenter d’étudier le rôle du  SCEF dans le plan utilisateur. Nous allons considérer que le SCEF se limite à récupérer les données émises par le dispositif lorsque ce dernier ne possède pas de stack IP. Ainsi, lorsque l’objet ne peut pas utiliser la couche IP, les données reçues par le MME seront soit transférées au SGW et PGW (donnée IP ou non IP encapsulé dans un tunnel IP) soit émises du MME vers le SCEF. On appelle cette procédure NIDD Non Ip Data Delivery.

Figure 3 : Architecture du réseau MTC

Le C-SGN représenté sur la figure 3 réunit la fonctionnalité du MME et du SGW sur la même entité. Le C-SGN est défini comme une nouvelle entité pour le CIoT EPS optimization.

II-3) CIoT EPS optimization : Nouvelles Méthodes

Les Releases R.13 et R.14 définissent de nouvelles procédures afin d’optimiser le transfert de faible Data comme c’est le cas pour l’IoT. Il est donc nécessaire dans un premier temps de s’assurer que le device UE est compatible avec ces évolutions. Ainsi, si l’UE supporte les fonctionnalités du réseau optimisé par l’IoT, il en informe le réseau lors de la procédure d’attachement et à chaque TAU (UE supporting CIoT EPS optimizations). Il indique ainsi au réseau quelles fonctionnalités il peut supporter parmi les 4 suivantes :

  • control plane CIoT EPS optimization
  • user plane CIoT EPS optimization
  • EMM-REGISTERED without PDN connection
  • S1-U data transfer and header compression

 

Le Control plane CIoT EPS optimization permet de transporter des données utilisateurs (IP, non IP ou SMS) sur le plan de contrôle vers le MME sans déclencher l’établissement de RAB (bearer radio pour la data). De la compression d’entête sur les données IP peuvent, de façon optionnelle, être appliquées sur les connexions de type PDN.

Le User plane EPS optimization permet de passer du mode EMM-IDLE mode au mode EMM-CONNECTED sans avoir besoin de déclencher la procédure de Service Request. Si le MME supporte le User Plane EPS Optimization, il doit obligatoirement supporter le S1-U Data Transfer

Si l’UE indique « Attach without PDN connexion » au cours de la procédure d’attachement, alors l’UE n’a pas besoin d’une connexion PDN pendant l’attachement (bearer S5). S’il indique « SMS only », dans ce cas, il n’a pas besoin d’un attachement conjoint sur le réseau 2G

L’UE optimisé pour

le plan de contrôle

(Control Plane CIoT EPS – en rouge sur la figure 4) est obligatoire pour les UE de catégorie LTE-M1 (cat M1) ou NB-IoT (cat NB1).

L’UE optimisé dans

le plan utilisateur

(user plane CIoT EPS optimization – en bleu sur la figure 4) est optimisé pour gérer les contextes en mobilité.

Les deux plans supportent les transmissions de données IP ou non IP.
Nous allons décrire dans le prochain article les 4 fonctionnalités citées ci-dessus.