Archives du mot-clef LTE-M

L’IoT – Evolutions R16 et R17

Posté le by - 397 vues
Répondre

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?

Posté le by - 886 vues
Répondre

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.

.

Internet des Objets

Posté le by - 1 868 vues
3

L’Internet Des Objets

Selon l’étude de marché menée par Statista en 2018 [1], plus de 75 milliards d’objets seront connectés à Internet en 2025, soit deux fois plus qu’en 2021 (35 milliards d’objets connectés).

Un grand nombre d’objets seront connectés via un réseau bas débit et faible coût, comme LoRaWAN, SIGFOX, ou à travers les réseaux cellulaires (LTE-M/NB-IoT).

En 2009, Christophe Fortet et Ludovic Le Moan ont créé la société SIGFOX pour le marché M2M.

Dans le secteur des objets connectés, SIGFOX est le premier à s’être positionné comme Opérateur IoT en déployant son propre réseau sur plusieurs continents (déploiement de l’accès radio-électrique et du cœur de réseau).

A la même année (2009) Nicolas Sornin et Olivier Seller travaillaient sur un module de transmission longue portée pour des télé-relevées (comptage eau-électricité). L’entreprise Cycleo fut rachetée par SEMTECH en 2012. Les puces SX1272 et SX1276 pour les modules LoRa et SX1301 pour la passerelle ont été produites en 2012.

En 2015, LoRaWAN est une alliance entre opérateurs (Orange, Bouygues …), équipementiers (SEMTECH, ST, …),  des sociétés qui déploient des solutions de connectivités (modules radio, cœur de réseau comme Actility, Sagemcom, Birdz, Cisco).

LTE-M et NB-IoT s’appuient sur les réseaux de mobiles 4G/5G permettant ainsi d’apporter rapidement une connectivité mondiale.

Les premiers marchés nécessitant des solutions de connectivités longue portée, faible cout et consommant peu d’énergie (LPWAN : Low Power WAN) ont été la collecte de données pour la gestion d’eau et d’Energie. A ce titre, VEOLIA a racheté l’activité Energie de la start-up Actility, complétant ainsi son activité de télé-relevé (Smart-City et environnement urbain) qu’elle réalise avec la société Birdz (exemple pour la gestion des déchets).

En 2020, l’IoT s’est positionné sur le marché de suivi de marchandise (tracker) afin d’améliorer les process logistique et afin de réduire la durée d’approvisionnement.

Ainsi, dans le cadre du suivi de la préservation des vaccins Covid réalisé par Pfizer et Moderna, nécessitant une congelation à -70°C pour Pfizer et -20°C pour Moderna, les laboratoires ont mis en place une procédure de suivi des vaccins pour suivre l’acheminement (GPS/NFC) avec un suivi de la température. Les solutions LoRaWAN et 5G ont été écartées (difficulté de roaming) pour retenir la solution NB-IoT.

L’Internet des Objets Industriel (IIoT), qui est la base de l’Industrie 4.0 (Smart Factory) fournit également une connectivité pour les usines intelligentes, aux machines, aux systèmes de gestion, et à la logistique/approvisionnement.

Ce blog étant consacré aux réseaux cellulaires, je n’aborderai que les solutions portées par les réseaux cellulaires. Néanmoins, pour ceux(celles) qui sont intéressé(e)s par le fonctionnement de LoRa et LoRaWAN, contactez moi

[1] https://www.statista.com/statistics/471264/iot-number-of-connected-devices-worldwide/

L’interface radio-électrique LTE-M : 2ème article

Posté le by - 2 545 vues
Répondre

Afin de réduire la signalisation, la procédure de mise à jour périodique de la localisation a été étendue et une nouvelle procédure de connexion radio a été proposée.

La procédure PTAU (Periodic Tracking Area Update) est périodiquement exécutée par un dispositif pour notifier auprès de l’entité MME de sa joignabilité sur le réseau d’accès radio 3GPP. Cette procédure est réalisée à l’expiration du Timer T.3412 lequel est ré-initialisé à chaque message NAS. Sa valeur par défaut est de 54 mn : la valeur du Timer T.3412 est transmise par le cœur réseau vers le mobile UE au cours de la procédure d’attachement ou lors de la mise à jour de la localisation en cas de changement d’indicateur de zone de tracking TAI.

Pour réduire ce message de signalisation, l’organisme de normalisation 3GPP propose d’étendre la temporisation périodique de localisation en augmentant la valeur du timer T.3412 (timer étendu).

Lorsque le terminal demande une connexion radio, la station de base eNB réalise une mise en sécurité des commandes NAS et une mise en sécurité de la transmission de données en échangeant. Ce contexte de mise en sécurité AS (Access Stratum) est sauvegardé au niveau du terminal UE et de la station de base eNB. L’établissement de ce lien permet au terminal de passer de l’état de veille à l’état connecté.

Pour éviter l’échange d’information AS chaque fois que le mobile souhaite passer du mode de veille au mode connecté, deux nouvelles requêtes RRC ont été introduites. Ces requêtes permettent de suspendre le lien radio et de passer en mode de veille tout en conservant le contexte AS au niveau du terminal et de la station de base. On dit alors que le terminal est à l’état Inactif (Inactive State) : Après une période d’inactivité, le terminal suspend sa transmission par le message RRC Suspend. La station de base eNB suspend alors la communication en relâchant le lien radio avec le terminal mais en conservant le contexte du terminal.

Le lien radio sera rétabli à l’initiative de la station de base (par une notification de paging) ou à l’initiative du terminal via la requête RRC Resume.

IV-1-c) La durée de vie de la batterie

Les terminaux IoT doivent pouvoir être connectés au cœur réseau sans la moindre recharge pendant plusieurs années. Cette autonomie s’obtient en apportant plusieurs mécanismes complémentaires au terminal comme le mode PSM (Power Saving Mode) défini dans la Release R.12 et l’évolution du DRX définie dans la Release R.13 (eDRX). Ces deux modes définissent une durée pendant laquelle le terminal éteint son interface radio dans le but de prolonger la durée de vie de sa batterie.

IV-2) L’interface radio LTE-M

Le réseau d’accès LTE-M hérite des canaux physiques du LTE-M. La bande totale du réseau LTE est divisée en bande étroite occupant chacune 6 PRB (soit 1.4 MHz) comme le montre la figure 3.

Figure 3 : La division de la bande LTE de 10 MHz en sous bandes étroites LTE-M de 1.4 MHz

Le nombre de sous bandes étroites dépendent de la bande LTE sur laquelle le réseau LTE-M s ‘adosse :

Table 1: La configuration des bandes étroites LTE-M

A l’instar de tous terminaux LTE, le terminal IoT écoute le centre de la bande du réseau d’accès LTE afin de récupérer les signaux de synchronisations et le message MIB transmis dans le canal de diffusion (PBCH)

Pour les terminaux IoT, les informations MIB sont transportées sur le canal physique MPBCH avec une périodicité de 10 ms. Un nouveau MIB est transmis toutes les 40 ms et par conséquent chaque MIB est répété 4 fois. Le nombre de répétitions peut être augmenté afin d’améliorer la couverture du canal MPBCH. Le nombre de répétitions est connu par le terminal via le paramètre CATMPR:mibRepEnabledCatM.

Figure 5 : La répétition du MPBCH

La station de base LTE-M transmet en plus des informations de signalisation SIB, lesquelles sont indiquées par le canal de diffusion MPBCH. Les informations SIB1-BR permet d’informer le terminal IoT du numéro de bande étroite exploité sur la bande LTE pour des communications sur le réseau d’accès LTE-M. Ainsi, en reprenant comme exemple le tableau 11.2, les communications sur l’accès radio LTE-M peuvent utiliser les 3 premières sous-bandes (NB1 à NB3) ou les trois dernières sous-bandes NB6 à NB8 : SIB1-BR indique les sous-bandes valides du lien descendant, et exclue automatiquement les 72 sous-porteuses centrales.

L’information DCI portée par le canal MPDCCH permet de transmettre :

  • les informations de séquencement DL (DCI Format 6-1A/6-1B dans le mode CE A/B ;
  • les commandes de contrôle de puissance du lien montant (DCI Format 3/3A) ;
  • les informations d’allocation de ressource pour le lien montant (DCI Format 6-0A/6-0B pour les modes CE A/B) ;
  • un indicateur de paging ou une mise à jour des informations de SI (DCI Format 6-2).

Les terminaux de catégorie CAT-M1 répondent aux spécifications proposées par le réseau d’accès LTE-M et les évolutions du cœur réseau.

  • Conclusion

Le marché du Wireless IoT est très concurrentiel : les opérateurs Orange et Bouygues ont déployé la solution LoRa pour ne pas laisser aux opérateurs Sigfox ou QoWiSio le marché du M2M en France. Orange a récemment ouvert un deuxième réseau d’objet connecté via l’accès radio 4G/LTE-M. Cela permet de répondre à des cas d’usage différents puisque le réseau d’accès LTE-M permet :

  • des débits de transmission plus important ;
  • des appels téléphonique via le mécanisme VoLTE ;
  • des accords de roaming avec les opérateurs pour le trafic
  • des accords de roaming avec les opérateurs ayant déployé l’entité d’interfonctionnement IWK-SCEF pour les notifications

Les solutions LoRa propose des accords de roaming entre opérateurs (LoRAWAN 1.1) cependant, le dispositif doit pouvoir se caler sur le plan de fréquence du pays visité. Cette solution a été mise en œuvre par Sigfox par le mécanisme MONARCH.

L’opérateur SFR est aussi présent sur le marché via un accord commercial avec SIGFOX mais SFR ouvre le réseau d’accès NB-IoT.

Ces informations ont été recueillies à partir de la formation SE26 de la société NEXCOM Systems (https://www.nexcom.fr/formation/comprendre-le-deploiement-de-la-4g-m2m-lte-m-mtc-pour-liot/). Cette formation présente les évolutions de l’interface radio et les canaux logiques/physiques, notamment les impacts sur les canaux physiques (MPBCH, MPRACH, MPDCCH/MPUCCH, MPDSCH/MPUSCH) et de synchronisation (PSS, SSS). Vous pouvez contacter formation@nexcom.fr pour obtenir des informations sur le contenu des formations qu’ils proposent, en indiquant que vous avez découvert leur formation à travers ce blog.

L’interface radio LTE-M – 1er article

Posté le by - 2 509 vues
2

L’accès radio LTE a initialement été conçu pour optimiser les communications à haut débit (MBB : Mobile BroadBand, mobiles larges bandes) en prenant en compte une mobilité élevée et une latence faible pour le transport des données (10 ms). Les exigences en termes de performances 4G sont encore mesurées à ce jour par le débit maximum et la réduction de la latence sur le plan de transport (UP : User Plane).

Le marché de l’Internet des Objets a longtemps été supporté par le réseau GPRS. Cela s’explique par le faible coût des modems GPRS comparé aux modems 4G. Toutefois, les performances de l’accès radio LTE sont attractives :

  • meilleure efficacité spectrale ;
  • disponibilité de l’interface radio pour du long terme ;
  • couverture globale.

De par ses atouts, une optimisation du lien radio LTE et du cœur réseau (MTC : Machine Type Communication) sont mises en œuvre pour répondre aux spécificités du marché de l’IoT.

Les optimisations portent sur :

  • le contrôle de la congestion et la maximisation de la capacité de la cellule ;
  • la réduction de la signalisation 4G ;
  • l’augmentation de la durée de vie de la batterie ;
  • l’augmentation de la Couverture.

De surcroît, pour devenir compétitif sur le marché de l’IoT, une réduction importante du prix des modems LTE est nécessaire. Dans la Release R.13, l’organisme 3GPP propose une simplification des terminaux en définissant deux nouvelles catégories de terminaux sous l’appellation cat-M1 et cat-NB1.

IV-1) Les améliorations sur l’interface radio

Le réseau d’accès doit pouvoir supporter un très grand nombre de terminaux (mMTC massive MTC) tout en conservant une QoS (Quality Of Service) pour les communications humaines. Pour répondre à cet impératif :

  • des procédures de contrôle de congestion et le paramétrage d’objets tolérants au délai permet d’optimiser le fonctionnement du réseau tout en différenciant la requête de service émise par le terminal UE ;
  • des procédures de réduction de la signalisation permet d’optimiser le plan de signalisation.

De plus, les terminaux IoT doivent obligatoirement avoir une autonomie de plusieurs années, ce qui nécessite de mettre en œuvre des mécanismes de gestion d’énergie (DRX – Discontinuous Reception et PSM – Power Saving Mode) en contrepartie d’une latence élevée (HL Com High Latency Communication).

IV-1-a) Le contrôle de la congestion

La saturation du réseau peut se produire :

  • Au niveau de l’interface radio lorsque de nombreux terminaux se connectent ou tentent de se connecter simultanément vers la même station de base eNB ;
  • Au niveau du cœur réseau EPC (Evolved Packet Network) : la congestion peut se produire au niveau de l’entité MME pour la signalisation ou au niveau des entités SGW/PGW pour le trafic. L’entité MME peut être fortement sollicitée lorsque le nombre de terminaux établissant une communication NAS est élevé. Pour réduire sa charge, l’entité MME contrôle principalement la congestion avec les entités eNB.

Pour gérer de manière sélective la congestion sur l’interface radio, la Release R.10 introduit un indicateur de faible priorité (LAPI : Low Access Priority Indicator) destiné aux terminaux IoT. Cet indicateur est implémenté dans les dispositifs soit au cours de leur fabrication, soit lors du provisionnement via l’interface radio par le mécanisme OTA (Over The Air). Lorsque le terminal fait sa demande de connexion radio, il transmet au cours de la requête RRC_Connection_Request la cause de sa demande (delay tolerant). En cas de saturation de la station de base eNB, celle-ci rejette la demande de connexion en demandant au terminal, dans le message RRC_Connexion_Reject, d’attendre jusqu’à 30 mn avant de refaire une nouvelle demande de connexion radio (Extended Wait Time).

Dans la Release 11 l’entité eNB contrôle la congestion via l’interface LTE-Uu en diffusant un message d’information SIB 14.

Le message diffusé par le SIB14 transporte une information de restriction de cellule (EAB : Extended Access Barring). Ce message est destiné à interdire aux terminaux de faible latence (LAPI) toute demande de requête de service. Afin de prendre connaissance de la modification du SIB14, les terminaux configurés avec l’identifiant LAPI reçoivent une notification par la procédure de paging les informant d’écouter le message d’information SIB14 diffusé par la station de base eNB. La procédure EAB ne concerne donc qu’une partie des terminaux.

Ce nouveau mécanisme offre deux avantages : Le premier avantage est la réduction de la signalisation au niveau de la station de base eNB, le deuxième avantage est une réduction de la puissance consommée par le mobile UE.

Evolution de l’architecture du réseau 4G pour le M2M : AESE – Part 2

Posté le by - 1 877 vues
Répondre

(Suite de l’article précédent)

2) La procédure de déclenchement

La procédure de déclenchement a été proposée dans la recommandation technique de la release R.10 afin de permettre à un dispositif IoT de répondre à une sollicitation du portail client (SCS). La procédure de déclenchement de dispositif est normalisée dans la release R.11 et nécessite une première phase d’enregistrement de la part du serveur SCS auprès de l’entité SCEF ou MTC-IWF avec comme droit d’émettre des requêtes de réveil (Trigger Request). La phase d’enregistrement a pour but de créer un identifiant de transaction et les droits de requêtes formant ainsi une entrée dans la table de contexte de l’entité MTC-IWF/SCEF à laquelle se rajoute l’identifiant du ou des dispositifs à réveiller. Le dispositif peut s’identifier à partir de son numéro MSISDN, d’un identifiant externe sauvegardé sur le serveur MTC AAA de l’opérateur ou d’un identifiant de groupe.

Dans les spécifications 3GPP de la Release 11, l’entité SCS contacte l’entité MTC-IWF via une requête DIAMETER afin que ce dernier puisse réveiller le dispositif. Lorsque l’entité MTC-IWF reçoit une demande de réveil, il contacte d’abord la base de données HSS (ou le HLR) afin de convertir l’identité publique en une identité interne au réseau opérateur (identifiant IMSI). L’entité HSS/HLR peut éventuellement contacter un serveur d’authentification MTC-AAA pour convertir une identité externe en un numéro IMSI. Si l’identité de l’UE MTC est reconnue, l’entité MTC-IWF récupère les informations de souscription du afin de mettre en relation le portail client SCS avec le dispositif.

L’entité MTC-IWF définit la méthode de réveil la plus adéquate sur le plan de contrôle pour déclencher une mesure au niveau du dispositif à partir des informations suivantes :

  • Les informations actuelles d’accessibilités de l’UE (sur quel réseau l’UE est situé, et sur quel zone) ;
  • Les méthodes de déclenchement de service supporté par le réseau HPLMN ou VPLMN ;
  • Les méthodes de déclenchement supportées par l’UE ;
  • Les politiques de déclenchement de réveil de l’opérateur ;
  • Autres informations reçues de la part du serveur SCS dont potentiellement la localisation du dispositif si celle-ci est connue. La localisation permet d’optimiser le paging à la cellule et non à la zone de localisation TAI (Tracking Area Identifier).

Les méthodes de réveil possible sont :

  • MT SMS. L’UE doit pouvoir reconnaître dans le message un MT SMS provenant du SCS ;
  • Cell Broadcast : La procédure Cell Broadcast permet de réveiller un dispositif UE en émettant des informations sur les SIB portés par le canal balise ;
  • Signalisation NAS ;
  • Messages IMS.

De manière plus explicite, la figure 3 présente le call flow de la procédure de déclenchement. On suppose que le serveur SCS s’est préalablement enregistrée auprès de l’entité MTC-IWF et au cours de la procédure d’enregistrement, le portail client SCS a associé le dispositif UE à réveiller. L’entité SCS connait l’adresse IP de l’entité MTC-IWF, dans le cas contraire, le portail client SCS fait une requête DNS.

La demande de réveil est initialement déclenchée par une API provenant du serveur d’application Client vers l’entité SCS (non présente sur le call-flow). L’entité SCS transmet le message Request Device trigger à l’entité MTC-IWF (éventuellement après une requête DNS) dans la commande DIAMETER DAR (Device Action Request) à travers l’interface Tsp.

Le message DAR contient les informations suivantes (AVP) :

  • Le type de message : Device Trigger Request
  • Le MSISDN ou une identité externe correspondant à l’UE MTC à réveiller
  • L’identité du SCS qui émet la requête.
  • Un numéro de référence de la demande de requête de réveil
  • Les données de Trigger contenant données à transmettre à l’UE MTC lors de la demande de réveil comme :
  • Priorité du trigger
  • L’identification du port de l’application à exécuter au niveau du dispositif
  • Une durée de validité du message de réveil. Un temporisateur est déclenché au niveau du MTC-IWF qui reçoit le message DAR.

Figure 2. Call Flow d’un réveil de dispositif par SMS

L’entité MTC-IWF peut interdire ou autoriser la requête de réveil à partir de l’identité du serveur SCS si le serveur SCS n’est pas reconnu ou si le serveur SCS a dépassé le nombre de requêtes autorisées.

La durée de validité permettra à l’entité MTC-IWF de savoir si le dispositif sera joignable avant la fin du temporisateur. L’entité MTC-IWF aura besoin de connaitre la durée pendant laquelle le dispositif est soit à l’état dormant, soit en mode de veille avant la prochaine écoute de paging (Paging Occasion). Si le dispositif ne peut pas être réveillé pendant la durée de validité du message de réveil, alors l’entité MTC-IWF retourne un rapport d’erreur dans le message DAA.

L’entité MTC-IWF contacte l’entité HSS (éventuellement après une résolution HSS via la fonction de localisation SLF). A la réception de la requête DIAMETER SIR, l’entité HSS réalise les opérations suivantes :

  • Correspondance entre le numéro publique (MSISDN ou identité MTC externe) avec l’identité privée IMSI du dispositif ;
  • Récupère -si le dispositif est enregistré- le nœud de service actuel du dispositif (soit l’entité MME, l’entité SGSN, ou l’entité MSC) ;
  • Vérifie les droits de souscriptions du dispositif en correspondance avec l’identification du serveur SCS pour valider ou non la requête de réveil.

L’entité HSS répond à l’entité MTC-IWF par la requête SIA avec les éléments suivants :

  • Le nœud de service (MSC, SGSN, SGW) actuel du dispositif ;
  • Renvoie le statut du dispositif (UE State Information) permettant de savoir si le dispositif est à l’état connecté, de veille, ou non enregistré (absent). Cette information est apportée par le HSS ;
  • Le ou les mécanismes supportés par le dispositif (information apportée par le HSS) ;
  • Les capacités de services offertes par le réseau de l’opérateur Home (framework implémenté dans le MTC-IWF) et éventuellement par l’opérateur visité en cas de roaming ;
  • Autres informations transmises par le SCS (localisation du dispositif, demande de réveil groupé, …).

A partir des informations reçues, l’entité MTC-IWF sélectionne le mécanisme pour transmettre la requête de réveil au dispositif le plus efficace (SMS, Cell Broadcast, …) et génère un ticket de taxation.

L’entité MTC-IWF sélectionne la méthode SMS pour réveiller le dispositif. Il émet au serveur SMC-SC (SMS Service Center) la requête DTR.

Le message DTR contient :

  • le numéro IMSI du dispositif et éventuellement le MSISDN si le MTC-IWF le connait (si le SCS a donné l’identité MSISDN au MTC-IWF et non un identifiant MTC externe) ;
  • l’identité de l’entité SCS ;
  • l’identité du nœud de service (SGSN, MSC ou MME) si connu ;
  • le statut du dispositif ;
  • le numéro de référence de la demande de requête de réveil ;
  • la durée de validité du message de réveil ;
  • la Priorité du trigger ;
  • l’identification du port d’application du SMS.

Une fois le message DTR reçu, si le dispositif est joignable le centre de service SMS (SMS-SC) n’a pas besoin de contacter l’entité HSS. Il doit néanmoins :

  • vérifier l’identité du dispositif (IMSI ou MSISDN). Si l’UE n’est pas reconnu (DIAMETER_ERROR_USER_UNKNOWN) ;
  • vérifier l’identité du SCS. Si l’identité du SCS n’est pas reconnu (DIAMETER_ERROR_INVALID_SME_ADDRESS) ;
  • Router l’information vers le nœud de service (SGSN, MSC ou MME). Il renvoie alors l’information DIAMETER_SUCCESS à l’entité MTC-IWF.

Si le dispositif est non enregistré (absent), le centre SMS-SC va stocker le message et envoyer une notification à l’entité HSS (SM Message Delivery Status Report) afin que l’entité HSS rajoute l’adresse du centre SMS-SC dans la liste des messages d’attentes. Ainsi, lorsque le terminal MTC UE fera une demande d’attachement, il prendra connaissance du trigger.

Le centre SMS-SC renvoi le résultat de la demande DTR dans le message DTA. Le code de résultat AVP indique si la requête est acceptée (SUCCESS) ou refusée (FAILURE) avec le code d’erreur correspondant :

  • congestion du SMS-SC ;
  • adresse SME non valide ;
  • erreur de protocole SM.

A ce stade, l’entité MCT-IWF acquitte le message DAR par la réponse DAA, ce qui confirme que la demande de réveil a bien été transmise au SMS-SC.

Le message DAA contient :

  • le numéro de référence de la demande de requête de réveil ;
  • l’état du statut de la requête de réveil.

Si la requête est acceptée, le centre SMS-SC envoie le SMS vers le MTC UE et attend la notification de SMS. Cette notification est transférée du SMS-SC vers l’entité MTC-IWF dans le message DIAMETER DRR (Delivery Report Request) et l’entité MTC-IWF répondra au SMS-SC par la réponse DRA (Delivery Report Answer).

Le message DRR transmet le rapport de succès ou d’échec de transfert su Trigger par SMS, il contient les informations suivantes :

  • l’identité IMSI de l’UE et éventuellement le MSISDN ;
  • l’identité du SCS ;
  • le résultat de la requête :
  • Client Absent
  • Mémoire de l’UE remplie
  • Transfert réussi.

L’entité MTC IWF informe l’entité SCS de la réception du SMS de la part de l’UE. L’entité MTC-IWF envoie le message DIAMETER DNR (Device Notification Request) au serveur SCS et attend la réponse DNA (Device Notification Accept)

Le DNR contient les informations suivantes :

  • le MSISDN ou l’identité externe du dispositif ;
  • l’identité du SCS qui a fait la demande de réveil ;
  • le numéro de référence de la demande de requête de réveil ;
  • la réponse à la demande de réveil.

L’entité SCS acquitte la réception de cette requête en répondant par le message DIAMETER DNA.

Enfin, l’entité MTC-IWF répond à la requête DRR émis par le SMS-SC par la réponse DRA, informant ainsi le SMS-SC d’un succès ou d’une erreur sur l’interface T4.

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

Posté le by - 3 693 vues
Répondre

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?

Posté le by - 4 914 vues
2

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