L’IoT – Evolutions R16 et R17

Introduction

Le standard 3GPP a démarré ses travaux de normalisation pour l’IoT à partir de la R.10 pour définir une liste de spécifications pour les terminaux et le cœur de réseau afin d’éviter la congestion (Extended Access Barring), d’avoir moins d’impact sur les smartphones (LAPI), réduire la complexité (Half Duplex, réduction de la puissance, bande plus petite …), avoir une meilleure sensibilité pour une transmission à faible débit (bande plus petite).

Dans la R.11, la 3GPP propose une méthode de réveil de terminaux et une transmission de données par SMS.

Dans la R.12, la 3GPP propose des optimisations pour la réduction de la consommation énergétique (UEPCOP : mode PSM et eDRX) et une méthode de transmission de données de taille réduite (Small Data)

Figure 1 : Le standard 3GPP R10 à R12 pour l’IoT

Dans la R.13, la 3GPP une optimisation du cœur de réseau pour prendre en charge la transmission de données :

  • dans le plan de contrôle Control-Plane CIoT EPS Optimization ;
  • dans le plan de trafic User-Plane CIoT EPS Optimization.

L’optimisation CP CIoT EPS Optimization propose de transmettre des données dans un message NAS entre l’UE et le MME. Sur l’interface radioélectrique, le message NAS est encapsulé dans un message RRC, lorsque le mobile est à l’état RRC_CONNECTED, c’est-à-dire à la suite de la procédure d’accès aléatoire. Dans l’optimisation CP CIoT EPS Optimization , la mise en sécurité AS n’est pas mise en œuvre, c’est-à-dire la connexion RRC n’est ni chiffrée, ni authentifié (intégrité).

L’optimisation UP CIoT EPS Optimization permet de transmettre des données entre l’UE et le MME lorsque le mobile est à l’état RRC_CONNECTED avec la mise en sécurité AS. Cela suppose que le contexte AS soit conservé au niveau du terminal UE et de la station de base. La R.13 propose une procédure de suspension/reprise de la connexion RRC lorsque le mobile passe de l’état RRC_CONNECTED à l’état RRC_IDLE.

Figure 2 : L’optimisation du coeur de réseau

Sur l’interface LTE, l’optimisation CIoT EPS Optimization permet de transporter les données sur la couche RRC. Le MME peut ensuite transférer les données vers le plan de transport SGW ou l’entité SCEF (Service Capability Exposure Function).

La R.14 introduit les spécifications à mettre en oeuvre pour le 5G MTC.

Figure 3 : Les améliorations proposées de la spécification R.10 à la R.14

La transmission EDT

Pour réduire la signalisation, la transmission EDT (Early Data Transmission [1]) propose de transmettre les données dans un message RRC au cours de la procédure d’accès aléatoire (RACH EDT). On distingue la transmission CP-EDT s’appuyant sur l’optimisation du plan de contrôle CP-EDT (sans chiffrement) de l’optimisation du plan utilisateur UP-EDT (avec chiffrement).

L’inconvénient de la procédure EDT est la transmission du message sur le canal de contrôle commun. Celle-ci est donc interférée par les demande d’accès aléatoire pouvant simultanément avoir lieu sur les mêmes bandes de fréquences.

La transmission UP-EDT est :

    • soit à l’initiative du terminal (Mobile Originated MO-EDT) spécifiée dans la R.15
    • soit à destination du terminal (Mobile Terminated MT-EDT) spécifiée dans la R.16.

La transmission EDT a été proposée dans la R.15 pour optimiser la transmission de messages courts lors de la procédure d’accès aléatoire. Au cours de cette procédure, le mobile reste à l’état RRC_IDLE sans contexte AS (CP EDT – Contol Plane EDT) ou en ayant conservé le contexte AS (UP EDT – User Plane EDT). A l’issue de la demande d’accès aléatoire, la transmission EDT étant finalisée, le mobile rester à l’état RRC_IDLE. Si d’autres données doivent être émises ou reçues, le terminal passe à l’état RRC_CONNECTED.

Dans ce cas, le premier paquet est transmis selon la procédure EDT, les autres paquets seront transmis de manière traditionnel.

La transmission PUR (Preconfigured Uplink Resource) consiste à pré-configurer les ressources du lien montant (UL) au cours d’une première connexion radioélectrique (RRC_CONNECTED). Cela signifie que la transmission PUR nécessite qu’en amont le terminal ait été dans l’état RRC_CONNECTED afin de recevoir la pré-configuration désirée.

La transmission PUR est utilisable par le terminal à l’état RRC_IDLE sans nécessité de procédure d’accès aléatoire mais en ayant conservé un contexte AS et l’allocation UL.

Ensuite, lorsque le mobile est en mode de veille, il peut utiliser les ressources qui lui sont réservées pour transmettre ses données sans avoir à mettre en œuvre la procédure d’accès aléatoire

Sur un cœur de réseau 5GC, la 3GPP propose un nouvel état radioélectrique du mobile nommé RRC_INACTIVE dédié aux terminaux IoT.

Le cœur de réseau 5GC pouvant être connecté à l’interface radioélectrique 4G E-UTRA et 5G-NR, l’état RRC_INACTVE s’appliquera à l’UE sur chacune des interfaces.

La transmission SDT (Small Data Transmission) est une procédure permettant de transmettre des petites quantités de données entre un terminal UE et le cœur de réseau 5GC en passant soit par l’accès radioélectrique 4G E-UTRA ou l’accès radioélectrique 5G-NR lorsque le terminal UE reste à l’état RRC_INACTIVE. La transmission SDT peut se faire sur l’interface E-UTRA comme sur l’interface 5G-NR.

La transmission non SDT correspond à la transmission traditionnelle de données entre un UE et le cœur de réseau 5GC via l’établissement de bearers lorsque l’UE est à l’état RRC_CONNECTED.

La transmission SDT sur l’interface 5G-NR a été introduite dans la spécification R.16 sous le nom NR SDT. La spécification R.17 propose deux technologies nommées RA-SDT (RACH SDT) et CG-SDT (Configured Grant SDT) lorsque le mobile est à l’état RRC_INACTIVE.

Figure 4 : Les types de transmissions IoT sur les réseaux 4G et 5G

[1] Andreas Höglund, Dung Pham Van, Tuomas Tirronen, Olof Liberg, Yutao Sui, and Emre A. Yavuz, “3GPP Release 15 Early Data Transmission”, 2018, IEEE Communications Standards Magazine ( Volume: 2, Issue: 2, JUNE 2018), p90-96, https://doi.org/10.1109/MCOMSTD.2018.1800002

BL UE, non BL UE et NB-IoT, quelles sont les différences?

Les procédures relatives au fonctionnement des terminaux UE différent selon le type de terminal.

A titre d’exemple, la procédure d’accès aléatoire (se référer au paragraphe 5.1.1 de la spécification TS36.321) indique :

« Before the procedure can be initiated, the following information for related Serving Cell is assumed to be available for UEs other than NB-IoT UEs, BL UEs or UEs in enhanced coverage « 

L’objectif de cet article est de préciser à quel terminal fait référence la spécification.

Dans le cadre des transmissions IoT, la spécification 3GPP a proposé plusieurs techniques :

  • d’optimisation d’énergie (eDRX, PSM, Half Duplex, réduction de la puissance d’émission)
  • de simplification des terminaux (Half Duplex/absence de duplexeur, réduction de la puissance d’émission – PA optionnel, largeur de bande réduite – moindre complexité des antennes et des filtres)
  • d’amélioration de la couverture dite aussi CE Coverage Enhanced (réduction de la bande – meilleure sensibilité, répétition – mode A ou mode B)

L’implémentation de ces optimisations a permis de définir différentes catégories de terminaux dédiés à l’IoT :

  • NB-IoT qui émet/reçoit sur une sous porteuse jusqu’à 12 sous porteuses maximums (RB)
  • BL UE (Bandwidth reduced Low Complexity) qui utilise une sous bande réduite de l’interface LTE, typiquement de :
    • 6 RB (LTE-M1) pour les liens montants et descendants
    • 24 PRB (LTE-M2) pour augmenter le débit de transmission. Ces terminaux augmentent uniquement la largeur de bande des canaux PDSCH et PUSCH
  • Non BL UE fonctionnant dans le mode CE (Coverage Enhanced) utilisant jusqu’à 24 PRB dans le lien montant et 24 PRB ou 96 PRB dans le sens descendant.

La largeur de bande pour le lien montant et descendant est configurée par la signalisation RRC.

Un terminal BL UE se synchronise sur les canaux PSS/SSS de l’interface LTE mais, le terminal ne peut camper sur la cellule seulement si l’information MIB indique la présence d’un SIB1 (nommée SIB1-BR) dédié aux terminaux UE BL La cellule est considérée comme barrée en absence de cette information.

Les informations sur la localisation du SIB1 est diffusée par le MIB via l’information schedulingInfoSIB1-BR-r13 codée sur 5 bits. Si la valeur est égale à 0, le SIB1-BR n’est pas transmise. La valeur entre 1 et 31 indique la transmission du SIB-BR et la répétition du canal PDSCH qui transporte le SIB1-BR.

Les autres SIB sont séquencés à partir du SIB1-BR. Le SIB2-BR permet au terminal BL UE d’acquérir les informations sur les préambules d’accès aléatoires.

On différence ainsi les catégories de terminaux :

  • NB-IoT
  • BL UE : LTE-M1/LTE-M2
  • Non BL UE : LTE cat.0

La taille du bloc de transport TBS (Transport Block Set) pour la diffusion d’information est limitée à 1000 bits pour les terminaux BL UE.

La taille du bloc de transport pour le canal de trafic PDSCH/PUSCH est limitée à 1000 bits pour les terminaux LTE-M1 et à 680 bits pour les terminaux NB-IoT.

.

Master Objets Connectés / IoT de l’université de Poitiers (ouvert à l’alternance)

Le master Objets Connectés / IoT de l’université de Poitiers a pour objectif de former les étudiants aux nouveaux métiers pluridisciplinaires d’ingénierie de l’IOT (Internet Of Things). Les compétences développées dans cette formation répondent aux besoins actuels d’architectes logiciels et matériels sur toute la chaîne de transmission et de traitement dédiée aux objets connectés et intelligents. Les modules d’acquisition, d’analyse et de traitement des données, de vision, d’intelligence artificielle, d’électronique et d’informatique embarquée, de technologies sans fil, de réseaux et de cyber sécurité illustrent cette approche. Afin d’atteindre le niveau d’expérience recherché dans ces domaines, et en lien avec les nouvelles pédagogies, une partie importante de la formation est dédiée à la mise en œuvre pratique sur des cas d’usages proposés par nos partenaires industriels et notre laboratoire de recherche support XLIM.

Vous êtes étudiants, une entreprise/structure en recherche de stagiaires ou contrats d’alternance, ou autre contactez :

Clency.perrine@univ-poitiers.fr

www.sfa.univ-poitiers.fr/objetsconnectes/

E2E Network Slicing : le découpage du réseau de bout en bout (Partie 1)

Le découpage du réseau (Network Slicing)

Au cours de cet article, nous allons décrire plus précisément le découpage du réseau de mobiles en reprenant plusieurs articles précédents sur la virtualisation et la programmation du réseau (NFV/SDN).

La vision du NFV dans cet article reprend les travaux de l’organisme de spécification ETSI et les fonctionnalités du SDN s’appuie sur le travail de l’ONF.

Ainsi, le SDN est vu comme un contrôleur de tranche de réseaux et un contrôleur du plan de transport, et le NFV gère l’allocation des ressources virtuellement (déploiement, dimensionnement et relachement).

Je remercie Antoine Mouquet (Expert 3GPP – Orange), Nicolas Bihannic (Chercheur Orange Labs) et le professeur Adlen Ksentini (Eurecom Sophia Antipolis) pour les échanges qui ont permis d’améliorer considérablement cet article.

Le déploiement d’un réseau 5G s’effectue en deux étapes :

  • La première étape est le déploiement d’un accès radioélectrique 5G. La 5G-NSA est la 5G non autonome. Pour le déploiement à venir (5G NSA option 3), le cœur de réseau est le réseau 4G (EPC) et l’accès radioélectrique 5G est contrôlé par une station de base 4G grâce au mécanisme de double connectivité ;
  • La deuxième étape est nommée 5G-SA, il s’agit de la 5G autonome. Le cœur de réseau est entièrement 5G permettant ainsi d’apporter de la souplesse du cœur de réseau en exploitant la virtualisation des fonctions réseaux.

Le découpage du réseau s’appuie sur la virtualisation du cœur de réseau et la virtualisation de l’accès radioélectrique. Le découpage de réseau est la solution permettant d’apporter une qualité de service spécifique (SLA : Service Level Agreement) pour les utilisateurs en fonction des usages suivants :

  • les usagers de smartphone ;
  • les entreprises ;
  • des processus verticaux (IoT) ;
  • le marché de gros (wholesale business).

L’objectif de cet article est d’expliquer le fonctionnement du découpage du réseau (network slicing). Ce découpage doit nécessairement être mis en œuvre pour pouvoir répondre aux exigences des différents services auxquels la 5G souhaite répondre. La spécification 3GPP a normalisé à ce jour 4 catégories : smartphones (eMBB), les terminaux IoT (mMTC), les communications critiques (URLLC), les véhicules connectés (autonomes : V2X), mais les opérateurs peuvent mettre en œuvre d’autres fonctionnalités dédiées.

L’article est décomposé en quatre parties techniques :

  1. la description d’un réseau basé sur les services et identifications des services ;
  2. la description d’une tranche de réseau et mise en œuvre de la virtualisation ;
  3. la virtualisation du cœur de réseaux ;
  4. la virtualisation de l’accès radioélectrique.

En conclusion, nous reviendrons sur la virtualisation des fonctions du réseau et l’avantage de cette architecture.

I) Un réseau basé sur les services (SBA : Service Based Architecture)

Le réseau de 5ème génération est avant tout un réseau cellulaire devant assurer la continuité des services offerts par le réseau de mobiles 4G. Il est ainsi conçu pour répondre aux exigences des smartphones à très haut débit, et aux exigences du marché des objets connectés.

Toutefois, le réseau de mobiles 5G s’ouvre également à des applications nécessitant des latences faibles pour des communications critiques avec une convergence des marchés PMR (Private Mobile Radio), et des offres TETRA, GSM-R (voir la spécification FRMCS : Future Railway Mobile Communication System).

L’un des objectifs des spécifications 5G est de définir un déploiement automatique de fonctions réseaux afin de répondre aux différentes exigences à respecter (KPI : Key Performance Indicator) spécifique à chaque type de services à mettre en œuvre. La stratégie est de réduire le délai de la mise sur le marché d’un service Tiers players. On parle ainsi de services verticaux et pour identifier les besoins, nous allons dans un premier temps lister de manière non exhaustive un panel de secteurs :

  • La réalité augmentée et la réalité virtuelle : l’humain interagit avec son environnement nécessitant une latence de 7 à 15 ms, un débit de 250 Mbps (3D/ 12k) à 2.34 Gbps pour de la 3D 24 k et une perte de paquets de 10-6; Le Wi-VR (Weak Interactive VR) peut nécessiter une latence RTT de 10 ms (Ultimate VR) ;
  • Le secteur de l’automobile avec des connectivités pouvant gérer des services de loisir (Infotainment), de télématique (IoT), de sécurité routière (partage d’informations, assistance à la conduite, conduite coopérative, gestion d’une file de camions (platooning), opération à distance) ;
  • Le secteur de l’énergie et du smart-grid (latence < 10 ms, disponiblité de 99,999% et un TEB de 10-9) ;
  • Le secteur de la santé (tracking de patient ou de matériel, soin à distance, soin en urgence) avec le téléchargement d’imagerie radio jusqu’à la télé-chirurgie ;
  • Le secteur de l’industrie 4.0 (smart factory) : automatisation du processus de fabrication, logistiques, maintenance prédictive, systèmes cyber-physiques (C2C : Control To Control Communication), robots mobiles;
  • Le secteur de l’IoT avec la technologie LPWAN qui permet à titre d’exemple la gestion des déchets, le suivi des mobiles, la mesure de consommation (gaz, électricité, eau, …), la détection de fuite, le parking intelligent ;
  • La sécurité publique (Push To Talk, vidéo, …) répondant aux exigences du réseau TETRA;
  • Le secteur du smart-cities (lampadaire intelligent, sécurité publique par détection de bruit).

La liste est non exhaustive, et chaque service nécessite des caractéristiques que l’on peut résumer avec les critères suivants :

  • latence ;
  • débit ;
  • sécurité de la communication;
  • mobilité ;
  • localisation ;
  • accessibilité ;
  • disponibilité ;
  • résilience ;
  • densité de connexion.

Les indicateurs de performance doivent être respectés au niveau du cœur de réseau et de l’accès radioélectrique.

Figure 1 : Des exemples de services 5G

II) Description d’une tranche de réseau et mise en œuvre de la virtualisation

II-1) Définition

La spécification 3GPP défini :

  • Un modèle d’une tranche de réseau (Network Slice Template). Le NST est une description complète d’une tranche de réseau en listant les fonctions virtuelles, les ressources matérielles nécessaires pour chaque fonction en vue de gérer le plan de trafic de bout en bout. Ce modèle sert de référence pour instancier une tranche de réseau ;
  • Une instance de tranche de réseau (NSI : Network Slice Instance) correspond aux entités du réseau de mobile qui répondent aux indicateurs de performances demandés par le support opérationnel et fonctionnel (OSS/BSS). Une entité est une ressource matérielle et une fonction logicielle déployée au moment de la création de l’instance. Afin de simplifier le réseau de mobile, chaque instance se décompose de sous-instance (SNI : Sub Network Instance) qui sont partagées. Ainsi, une instance de tranche de réseau est composée d’une sous-instance RAN (Radio Access Network), d’une sous-instance de cœur de réseau 5G CN (Core Network). Une sous-instance SNI peut appartenir à plusieurs instances de tranche de réseau ;
  • Un support opérationnel et de supervision. Afin de s’assurer que les indicateurs de performances soient respectés à tout instant, la tranche de réseau (NS : Network Slice) contrôle l’instance de tranche de réseau (NSI) à partir de fonctions de gestion et de supervision. La supervision permet d’alerter le contrôleur si les performances se dégradent et le contrôleur va pouvoir gérer de nouvelles entités ou mettre à l’échelle une ou plusieurs entités (scalability and elasticity).

La supervision d’une tranche de réseau est essentielle pour valider la qualité de service (QoS) et le respect des indicateurs de performance.

L’isolation opérationnelle de chaque tranche permet aux utilisateurs verticaux (OTT ou entreprise) de pouvoir configurer, superviser, contrôler leur tranche de réseau de manière indépendante.

L’isolation au niveau du réseau signifie que les clients verticaux ont des ressources dédiées. La description des slices permet à un utilisateur de profiter de fonctions réseaux dédiées et d’un accès radioélectrique partagé. Le client étant ici le demandeur de service auprès d’un opérateur, et l’utilisateur est celui qui utilise le service en bout de chaîne (terminal).

L’isolation opérationnelle permet donc de partager des ressources matérielles et logicielles comme des hébergeurs de cloud, en isolant les fonctions réseaux entre elles.

L’isolation au niveau réseau (figure 2) permet de proposer des ressources dédiées, à la fois au niveau du cœur de réseau, mais également au niveau de l’accès radioélectrique (RAN dédié). Des applications comme la sécurité civile ou le smart-grid peuvent nécessiter une isolation du réseau. Les réseaux PNI-NPN (Public Network Integrated Non-Public Network) sont des réseaux dédiés dont l’accès radioélectrique peuvent être partagés avec le réseau PLMN.

Figure 2 : Les ressources dédiées ou partagées du réseau de mobiles 5G

A l’instar des solutions portées par les hébergeurs cloud, il n’est pas nécessaire de déployer une tranche de réseau (slice) par client vertical, mais de partager le slice entre plusieurs clients.

II-2) Gestion d’une NSI (Network Slice Instance)

L’instance est mise en œuvre à partir d’un gabarit et la procédure de déploiement et d’activation d’un slice est défini par les étapes suivantes (figure 3, 3GPP SA5).

Figure 3 : Gestion d’un slice. De l’activation à la désactivation

La procédure (figure 3) met en œuvre les entités du réseau de mobiles 5G en gérant la durée de vie des instances à partir des fonctionnalités NFV décrites par l’organisme ETSI (se référer à l’article : http://blogs.univ-poitiers.fr/f-launay/tag/5g-nfv/).

Une tranche de réseau NSI peut contenir des fonctions réseaux physiques (PNF : Physical Network Function) ou virtuelles (VNF : Virtual Network Function).

Le réseau de transport n’est pas défini dans le cadre du travail de l’organisme 3GPP.

II-3) La virtualisation des fonctions du réseau

La figure 4 rappelle l’architecture système pour la mise en œuvre de fonctions virtuelles.

Figure 4 : L’architecture ETSI NFV

On identifie 3 groupes :

Le premier groupe est le système de gestion des réseaux de mobiles. Il est composé :

  • d’un support système OSS (Operation Support System). Le support OSS est une suite logicielle permettant d’administrer le réseau opérateur et de superviser les ressources. Le support OSS maintient un inventaire des entités réseaux, provisionne des services, configure les entités et récupère les éléments de supervision de chaque entité réseau ;
  • d’un support commercial (Business Support System). Le support BSS gère le déploiement de services à la demande des clients. Il offre ainsi les outils logiciels pour gérer les commandes jusqu’à la mise en paiement des services.
  • D’un support de gestion et de supervision (EM/DM). La gestion EM/DM permet de contrôler et de superviser les fonctions virtuelles et les ressources matérielles.

Le deuxième groupe est le système de gestion et d’orchestration des ressources matérielles et virtuelles (NVF – MANO : Management and Orchestration). Il a pour rôle :

  • sous l’ordre du support système OSS, l’orchestrateur MANO ordonne le déploiement ou la libération de fonctions virtuelles en respectant les contraintes matérielles inhérentes à chaque fonction ;
  • de superviser le bon fonctionnement des fonctions logicielles et des ressources matérielles allouées ;
  • de contrôler le déploiement de machines virtuelles ou de containeurs, de vérifier l’allocation de ressources et de libérer les ressources ;
  • de conserver des contextes sur les ressources utilisées, les ressources restantes, les images des fonctions virtuelles et les gabarits de chaque fonction virtuelle.

Le 3ème groupe correspond aux machines physiques et au déploiement des instances, ainsi que les fonction de routage.

II-4) Le système de gestion des réseaux de mobiles

II-4-1) OSS/BSS et NM

La phase de préparation est réalisée au niveau du support système OSS/BSS par la fonction Gestion de Réseau (NM : Network Management) via un contrôleur de slice. On peut trouver également l’acronyme NSMF (Network Slicing Management Function). Ce dernier soumet l’ordre à un orchestrateur (à travers le point de référence Os-Ma-nfvo) qui va pouvoir gérer l’infrastructure de virtualisation à partir du modèle de slice.

Le NSMF prend en charge le déploiement du end-to-end slice. On pourrait le nommer un end-to-end slice orchestrateur.

Le gestionnaire de réseau (NM) fourni les fonctions de gestion du réseau de mobiles, ce qui inclut les fonctions de virtualisation. Le NM supporte les fonctions de gestion FCAPS (fault, configuration, accounting, performance, security) du cœur de réseau 5GC et du réseau IMS. Il supervise le FCAPS spécifique pour maintenir et exposer le SLA.

Dans le cas de la gestion de slice, c’est le gestionnaire de réseau MN qui initie la gestion du cycle de vie de chaque fonction virtuelle (figure 3).

II-4-2) EM

Le gestionnaire d’élément (EM : Element Manager) est responsable de la gestion FCAPS au niveau d’un élément logiciel VNF (Virtual Network Function) ou d’un élément matériel (NE : Network Element). Les fonctions du gestionnaire d’entité correspondent à :

  • la gestion de fautes;
  • la gestion de la configuration ;
  • la gestion des éléments de facturation ;
  • la collection des mesures de performance à effectuer ;
  • la gestion des éléments de sécurité.

Un gestionnaire d’éléments peut gérer des fonctions virtuelles à travers des interfaces propriétaires. Un gestionnaire d’éléments peut aussi être une fonction réseau virtuelle.

 

II-4-3) NFV-MANO

II.4.3.1) NFVO

L’orchestrateur joue un rôle primordial :

  • Il gère l’orchestration de ressources : il coordonne l’attribution des ressources matérielles : l’orchestrateur autorise, met à l’échelle, libère les ressources physiques (NFVI : Network Function Virtualization Infrastructure) parmi l’ensemble des DataCenters (DC). Il ordonne les ordres au gestionnaire de ressource matérielle (VIM : Virtualized Infrastructure Manager) à travers le point de référence Or-Vi ;
  • Il gère l’orchestration de service : il contrôle l’établissement ou la libération d’une ou plusieurs fonctions virtuelles VNF en ordonnant l’ordre au gestionnaire VNFM via l’interface Or-Vnfm.
  • il gère la topologie des NSI (nommé VNF Forwarding Graph dans l’article : http://blogs.univ-poitiers.fr/f-launay/2018/02/04/network-functions-virtualisation-nfv-pour-le-reseau-4g5g/)

Pour gérer les services réseaux, l’orchestrateur s’appuie sur des catalogues de ressources définissant le gabarit souhaité :

  • Catalogue VNFD contient le descripteur de chaque instance VNF en terme de déploiement et de fonctionnement (pour la gestion FCAPS) ;
  • Catalogue de service permet de lister l’ensemble des fonctions VNF à cascader pour obtenir un sous réseau d’instances (SNI) ;
  • Catalogue NFVI contenant les ressources nécessaires pour mettre en œuvre un service NFV.

II.4.3.2) VNFM

Le gestionnaire VNFM (Virtual Network Function Manager) gère :

  • Le cycle de vie des fonctions virtuelles VNF : création, mise à l’échelle, maintenance et libération des instances VNF ;
  • Supervise et détecte les fautes (FCAPS) des fonctions virtuelles VNF.

Il expose :

  • une interface nord à l’orchestrateur à travers le point de référence Or-Vnfm ;
  • une interface sud pour injecter des règles au gestionnaire de ressource à travers le point de référence vi-Vnfm.

II.4.3) VIM

Une infrastructure matérielle est un serveur COTS hébergeant un hyperviseur. L’infrastructure est découpée en domaine, chaque domaine porte une VM ou un containeur.

Le gestionnaire VIM gère :

  • les ressources des infrastructures NFVI (stockage, CPU, carte réseau, …) d’un domaine ;
  • les ressources virtuelles (machines virtuelles et/ou containeur) du domaine ;
  • l’hyperviseur.

Ainsi, le gestionnaire VIM gère le cycle de vie des ressources virtuelles allouées à un domaine, conserve l’appairage entre la machine virtuelle et la machine physique, analyse via un agent les performances matérielles, logicielles et virtuelles et gère les performances et les fautes.

Il expose :

  • une interface nord à l’orchestrateur à travers le point de référence Or-Vi ;
  • une interface nord au gestionnaire de machine virtuelle VMF à travers le point de référence vi-Vnfm.

II.4.4) Pour aller plus loin

Il y a une différence entre le gestionnaire d’éléments (EM) et le gestionnaire de fonctions réseau virtuelles (VNFM) : Le gestionnaire d’éléments EM supervise la partie fonctionnelle du réseau de mobiles alors que le gestionnaire VNMF gère les entités virtuelles.

L’infrastructure NFVI est décomposée en plusieurs parties :

  • les ressources matérielles : CPU, mémoire RAM, carte réseau. Un commutateur (exemple TOR) et un élément de stockage fait également parti des ressources matérielles ;
  • la couche de virtualisation : Cette couche permet de faire abstraction des ressources matérielles en offrant des ressources logiques. Cette abstraction est réalisée par l’hyperviseur.

La suite dans un autre article.

 

 

 

 

IoT, BigData, IA : Un monde 100% connecté pour les systèmes cyber-physique (CPS)

Dans le précédent article, j’ai évoqué différentes technologies complémentaires, sans illustrer par des exemples concrets les applications attendues. Je vais présenter dans cet article la notion de système cyber-physique (CPS : Cyber Physical System).

Un système cyber-physique est un système bouclé qui intègre la remontée d’informations issues de capteurs physiques via des réseaux de connectivités vers un serveur de décision lequel par une boucle de rétroaction contrôle les processus physique.

(image issue du site suivant : https://smart-industries.fr/fr/challenges-et-opportunites-des-systemes-cyber-physiques)

Le serveur décisionnel permet de superviser les processus physiques, les commander et de faire de la détection de fautes afin de planifier une réparation avant l’apparition de défaut. On parle alors de reconfiguration ou de ré-organisation dynamique.

Un système de production CPPS (Cyber Physical Production System) concernent la coopération entre sous-systèmes autonomes afin de reconfigurer dynamiquement une chaîne de production. A titre d’exemple, une chaîne de fabrication est caractérisée par un ensemble de flux comme :

  • une prévision à la demande (flux poussée : on planifie les ressources dont on aura besoin lors de la conception d’un produit) ;
  • une prévision en temps réel (flux tirés : on commande à la demande pour satisfaire le besoin);
  • une prévision au plus juste de la demande (flux tendus)

L’objectif est donc de mesurer en temps réel le stock existant, de prévoir la commande en prenant en compte les délais d’approvisionnement et en fonction de la demande du produit, de reconfigurer la chaîne de production à la volée en cas de défaut d’un élément afin de maintenir l’activité de la chaîne de production. A cela, le système CPSS vise à prendre en compte d’autres paramètres comme :

  • le coût fluctuant de la matière première
  • le coût de l’énergie ou l’équilibrage de la consommation/production d’électricité

afin de réduire le coût énergétique (énergie verte).

C’est dans cette vision d’optimisation de la logistique, de la consommation énergétique que s’inscrit l’industrie 4.0 (e-usine ou smart-factory : les usines intelligentes).

Un autre exemple est le chargement/déchargement de cargo. Aujourd’hui, les opérateurs déploient des solutions de tracker sur les conteneurs. Ces solutions doivent fonctionner tout autour de la terre, ainsi on peut citer comme technologies qui nous intéressent ici le réseau d’accès LTE-M et NB-IoT. Ce dernier est plus adapté pour de faible quantité d’information. En dehors du blog, on peut aussi citer l’exemple MONARCH de Sigfox qui permet de réaliser le roaming vers les pays qui sont couverts par cet opérateur.

Rajoutons maintenant une connectivité sur les grues et les véhicules guidés (AGV : Automatic Guided Vehicule) et revenons à notre exemple : les ports de futur.

On peut ainsi imaginer une communication entre les grues, les véhicules, les conteneurs, et un serveur centralisé (fog) qui orchestre toute la logistique permet ainsi de réduire la durée d’attente de chargement ou déchargement.

Le déploiement d’antennes 4G et 5G à l’intérieur des entreprises (exemple de DAS : Distributed Antenna System) permettront de commander automatiquement les chariots élévateurs en fonction de toutes les informations recueillies et traitées (Big Data) comme les produits finis, les stocks en cours, …

A moins que … ce soient les machines qui commandent les hommes?

https://www.francetvinfo.fr/economie/emploi/video-cash-investigation-travail-vis-ma-vie-de-manutentionnaire-chez-lidl_2381539.html

Il faudra que je pense à écrire un article sur : Faut il avoir peur des nouvelles technologies?

IoT, Blockchain, IA, machine learning : Des technologies disruptives?

Les évolutions technologiques récentes vont apporter des changements profonds dans les domaines de la santé, de la logistique, le transport, l’énergie, l’agriculture, …

Si le déploiement de l’IoT (Internet of Things) destiné à collecter un ensemble d’informations constitue la première brique de cette évolution, la plus-value de cette transversalité numérique ne peut être obtenue qu’en garantissant la sécurisation des données collectées et le traitement efficace de ces données.

En cela, la technologie Blockchain s’insère dans l’écosystème de l’IoT en apportant un stockage des données, en assurant le transport sécurisé des données échangées et en permettant la traçabilité des données.

Quant aux traitements des données, l’intelligence artificielle (IA) permet de les valoriser et de les traduire en informations exploitables facilitant ainsi l’analyse décisionnelle des systèmes complexes. De surcroît, les méthodes d’apprentissages autonomes (Machine Learning) permettent également de classifier les données et d’apporter des outils de prédictions des pannes.

Les applications IA pourraient être mise en œuvre sur des lames de serveurs au plus proches des données collectées (MEC : Mobile Edge Computing).

Ainsi, les secteurs de la santé (capteurs et IA pour détecter l’évolution des maladies), du transport (véhicules autonomes), des chaînes d’approvisionnement (réparation des chaînes de production avant la cassure des pièces usées, l’approvisionnement en flux tendus), de l’énergie (délestages des sites industriels en assurant un transport de l’énergie au plus proche) seront impactés par la complémentarité de ces technologies disruptives.

Dans ces écosystèmes de plus en plus complexes, la donnée reste l’élément fondamental et le premier maillon d’une nouvelle ère économique. Les cabinets d’analystes estiment une évolution constante du marché des capteurs de l’IoT pour atteindre une centaine de milliards de dollars d’ici 2023 et une croissance du taux actuariel (CAGR – Compound annual growth rate) de 13%.

SigFox est le premier opérateur à s’être positionné sur le marché de la transmission sans fil des données issues des capteurs en déployant le réseau de transmission longue portée à basse consommation (LPWAN : LoW Power WAN).  Ce réseau LPWAN répond à la demande des compteurs intelligents (smart-meters, compteur d’eau, compteur de gaz), à la gestion des villes (smart-city) pour lesquels la communication est à latence élevée.

Aujourd’hui, l’opérateur Télécom SigFox est concurrencé par l’opérateur QoWiSio, l’opérateur Américain Ingénu, et l’alliance LoRaWAN avec le déploiement de LoRa par les opérateurs télécoms historiques.

Le réseau cellulaire 4G se positionne également sur ce secteur en étendant ses fonctionnalités pour répondre à l’émergence du marché de l’Internet des Objets. Ce réseau dédié aux communications Machine à Machine (MTC – Machine Type Communication) est destiné à devenir le premier réseau cellulaire LPWAN (Low Power WAN). Le premier avantage est de pouvoir rapidement apporter une couverture mondiale avec optionnellement une qualité de service.

L’IoT cellulaire (par son réseau d’accès NB-IoT, LTE-M et prochainement 5G NR) devrait connaître la plus forte croissance avec en point de mire, entre 10 000 et 100 000 objets connectés sous la couverture d’une seule station de base. Orange a ouvert son réseau LTE-M en novembre 2018, comme annoncé dans un précédent article traitant du cellular IoT.

Le réseau 5G quant à lui va permettre d’apporter de nouvelles solutions pour les communications M2M à temps réel (missions critiques URLLC : Ultra Reliable Low Latency Communication) pour répondre au besoin du secteur de l’automobile et de l’industrie (IIoT – Industrial IoT).

Le laboratoire LIAS s’intéresse à ces différentes technologies notamment comme application visée (de manière non exhaustive) le smart-grid, le secteur du transport,…

Dans les prochains articles je reviendrai plus particulièrement sur le MTC (réseau 4G).

Il est à rappeler que ces métiers s’adressent aux femmes et aux hommes, je vous invite à consulter le site femmes-numérique.fr

Blockchain, intelligence artificielle, big data, cyber sécurité, objets connectés, cloud…

 

L’initiative

 

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

Au cours de l’article précédent, nous avions évoqué les évolutions du réseau 4G vers le MTC. Cette évolution est une brique de base pour le réseau 5G et les fonctionnalités que nous avions décrites sont 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

(Je vais reprendre la notation de l’article précédent)
II-3-a) Control plane CIoT EPS optimisation
C-Plane CIoT EPS Optimization est une méthode destinée à encapsuler les données utilisateurs dans les messages du plan de contrôle. En évitant de mettre en place de la signalisation pour rétablir les bearer, cette méthode permet de réduire le nombre de message sur le plan de contrôle lorsque les données à transmettre sont de petites tailles et par conséquent, on réduit la bande utilisée et la consommation du dispositif.
Les fonctionnalités supportées par cette méthode sont :
• Transport de données utilisateurs (IP et Non IP)
• Point d’ancrage de la mobilité du dispositif
• Compression d’entête pour les flux IP
• Protection par intégrité et chiffrement de la Data transmise dans le plan de contrôle
• Interception légale.
Cette méthode s’appuie sur le MME, ce dernier est considéré comme un nœud de transfert de données et l’eNb est vu comme un relai :
• entre l’UE et le PGW (connectivité PDN : UE -> eNb -> MME -> SGW -> PGW) en utilisant les protocoles de signalisation (S1-AP et GTP-C)
• ou entre l’UE et l’entité SCEF (connectivité PDN : UE -> eNb -> MME -> SCEF).

Si l’UE a un stack IP, les données sont transmises en IP de l’UE vers le PGW.

Figure 5a : Control plane IP DATA

Si l’UE ne contient pas de stack IP (NIDD), les données sont transmises au MME via le protocole S1-AP et envoyées soit vers le PGW soit vers le SCEF. Lorsque l’UE fait une demande de connexion vers l’AS en non IP, l’UE indique l’APN  de passerelle. Le choix de la connectivité PDN entre le PGW et le SCEF est défini au niveau du HSS dans la donnée de souscription APN.

Le profil du device au niveau du HSS indique l’APN que doit utiliser le dispositif pour transmettre des données non IP. L’APN route les messages vers le PGW ou vers le SCEF.

On considère ici que l’APN renvoie vers le PGW.

Lorsque l’UE fait une demande d’attachement, il indique :

  • Qu’il souhaite une connection PDN non IP
  • Le réseau utilise l’APN fourni par l’UE ou l’APN contenu dans le profil de l’UE au niveau du HSS et transmis au MME
  • Le PGW donne à l’UE la taille maximale autorisée des paquets (qui peut etre de 128 octets)
  • Les paquets non IP sont transmis via le plan de contrôle par des messages NAS

 

Figure 5b : Control plane Non IP DATA vers le SGW

 

Connection non IP via le SCEF

Dans les deux cas, l’UE émet une demande de transmission de données via la procédure RRC SERVICE REQUEST en encapsulant le message ESM DATA TRANSPORT (message NAS entre l’UE et le MME via l’eNb en relais). Dans le cas précis ou l’UE ne contient pas de stack IP, il informe le MME qu’il souhaite établir une connexion PDN non IP.

Dans le cas de données entrantes :

  • Les données peuvent être bufferisées dans le SGW lequel transmet un message de notification « Downlink Data Notification Message » au C-SGN. Le C-SGN répond au SGW en indiquant le temps restant avant que le device soit joignable (PSM Mode). Cela permet au SGW d’étendre le temps pendant lequel le message sera conservé.
  • Les données peuvent être bufférisées dans le SCEF

 

II-3-b) User plane CIoT EPS optimisation

Dans le cas ou l’UE supporte l’optimisation sur le plan de données (User Plane CIoT EPS Optimization), il doit obligatoirement supporter la méthode S1-U Data transfer. Ainsi,  les données sont transmises via l’interface S1-U, c’est-à-dire entre l’eNb et le SGW.

L’optimisation User plane CIoT EPS optimisation est apportée par une amélioration du contrôle de bearer et par de nouveaux messages RRC ainsi que de nouveaux états RRC permettant un établissement de bearer plus rapide et plus efficace.

 

Les nouveaux états RRC sont : RRC-Suspend et RRC-Resume.

  • Procédure RRC Suspend. Cette procédure est activée par l’eNb permet de libérer le bearer radio entre l’eNb et le device, ainsi que le bearer S1 entre l’eNb et le SGW. Au niveau du SGW, cela supprime dans la table de contexte le numéro d’identifiant TEID du flux et l’adresse IP du eNb mais les autres informations sont conservées (QoS, clé de sécurité,…). Le MME conserve les informations de la connexion S1-AP et du bearer, place le device dans l’état ECM-Idle et répond à l’eNB de la libération du bearer par le message UE Context Suspend response. Le eNB conserve le contexte mais transmet à l’UE le message « RRC Connection Suspend ». Le device conserve les informations AS (clé de sécurité, information sur le flux de trafic) et se met en état ECM-Idle et RRC-Idle
  • Procédude RRC Resume permet de ré-activer les états qui ont été sauvegardés au niveau du device, de l’eNb et du MME. Dans un premier temps, le device récupère les informations de la couche AS et contacte l’eNB. Ce dernier accomplit une vérification de la sécurité pour ré-établir le bearer radio. L’eNB informe le MME par le message « UE Context Resume Request » de la ré-activation du bearer radio. Le MME récupère le profil du S1-AP et place le device dans l’état ECM-Connected. Il retourne vers l’eNb une confirmation « UE REsume Context Response » contenant l’adresse IP du SGW et le MME envoie l’adresse du eNb et le TEID du eNB (informations S1-AP conservées) vers le SGW.

Figure 6 : Messages RRC reprendre ou suspendre un contexte

 

Figure 7 : Call Flow

Pendant l’état RRC-Suspend, le device n’a plus de connexion radio. Il peut de plus être en mode eDRX, donc en cas de mobilité il ne détecte pas le changement d’eNB. Lorsque le device exécutera la procédure RRC Resume vers le nouvel eNb, celui-ci va demander à l’ancien eNb de lui transférer les informations AS. L’ancien eNb en profite pour supprimer le contexte (clé de sécurite, …). Le nouveau eNb crée un TEID, informe le MME lequel transfère le nouveau TEID et l’adresse du nouvel eNb vers le SGW.

De plus, cette méthode permet aussi de transférer des données non IP entre le SGW et le PGW

II-3-c) EMM-REGISTERED without PDN connection

Lors de la procédure d’attachement, l’UE informe le MME qu’il peut être dans l’état EMM-REGISTERED without PDN connection par le message “attachwithoutPDN Connectivity”. Classiquement, un smartphone (Human UE) émet dans la requête EMM d’attachement  un message ESM pour définir les caractéristiques du bearer par défaut. Dans le cas qui nous intéresse, le message ESM PDN CONNECTIVITY REQUEST est remplacé par le message ESM DUTY MESSAGE, l’UE reste connecté au réseau (EPS attached) même si toutes les connexions PDN ont été libérées. On se retrouve donc dans le cas 3G ou le contexte de l’UE n’existe pas au niveau des entités du réseau.

Remarque : « EMM-REGISTERED without PDN connection » à la même signification que « EPS attach without PDN connectivity

Lorsque le dispositif s’allume, avant d’émettre sa demande d’attachement, il lit le SIB2 transmis par l’eNb pour savoir vérifier la compatibilité de la cellule. Si le MME ne supporte pas l’état « EMM-REGISTERED without PDN connection » alors l’UE établie un bearer par défaut. Lorsque l’UE souhaitera émettre des données, un bearer EPS par défaut sera mis en place sauf si l’UE indique une méthode de transmission, par exemple SMS seulement, lors de son attachement.

II-3-d) S1-U data transfer and header compression

L’UE qui supporte le User Plane Optimisation EPS doit supporter le S1-U data transfer afin de transmettre les données sur le plan utilisateur.

On suppose maintenant que l’UE et le MME supporte à la fois la fonctionnalité S1-U data transfer et la fonctionnalité Control Plane EPS Optimization pour encapsuler la DATA entre le CN et l’UE dans des messages NAS

Lorsque le MME reçoit une requête de connexion PDN, le MME détermine la quantité de données à transmettre sur le lien UL et DL et décide ainsi si les données doivent être transmises sur le plan de contrôle ou sur le plan utilisateur. Il vérifie également si l’UE peut supporter

 

Figure 8 :  Etablissement du S1-U bearer pendant le transport de données dans le plan de Controle

1 – L’UE transmet/reçoit des données dans le plan de control (Control Plane CIoT EPS Optimisation).

2 –3 L’UE reçoit une réponse pour faire une demande d’établissement de bearer dans le plan utilisateur (User Plane Bearer). Dans ce cas, l’UE envoie un message NAS vers le MME. Le message est encapsulé dans un message RRC-Service Request émis au eNb, et un message S1-AP UL entre le eNb et MME. De manière classique, le message contient les informations suivantes :

  • NAS message
  • TAI+ECGI de la cellule sur laquelle l’UE est en communication
  • S-TMSI
  • CSG ID (si la cellule sur laquelle est connectée le mobile est une cellule CSG)
  • CSG access Mode

4 – Le MME fait le transfert des données transmises sur le plan de signalisation vers le bearer

Dans le prochain article, nous décrirons certaines procédures et protocoles