Maintenant que vous avez un kit IoT PicoLTE, il est temps de le configurer.

Cette page contient toutes les informations nécessaires pour comprendre et configurer le démonstrateur de livraison de données NB-IoT de bout en bout avec le PicoLTE et la carte d’application C030. Elle doit être lue attentivement avant d’utiliser le système. Les fichiers de configuration et tous les outils et microprogrammes intégrés connexes doivent être stockés pour référence ultérieure. Cette page présente la procédure de démarrage de l’EPS LTE NB-IoT ou NIDD et du dispositif C030. L’objectif est d’effectuer une communication de bout en bout entre une application IoT typique utilisant différents capteurs sur la carte C030 et publiant ces mesures vers un service basé sur le cloud en utilisant un chemin de données non-IP entre l’eNodeB et le dispositif.

*Reportez-vous à votre manuel d’installation fourni par Nutaq pour plus de détails.

Vous n’avez pas encore votre propre PicoLTE ?

Configuration de votre PicoLTE.

Le PicoLTE est un réseau en boîte LTE fournissant un système de paquets évolué LTE (EPS). Il peut exécuter à la fois l’eNodeB pour fournir un accès radio E-UTRAN et l’EPC pour gérer les plans de contrôle et de données des équipements utilisateur LTE. L’objectif principal de cette note d’application est d’illustrer comment configurer un réseau NB-IoT LTE/4G pour publier les mesures des capteurs vers un service en nuage.

L’eNodeB fournira un accès radio NB-IoT E-UTRAN au modem NB-IoT de la carte d’application C030.

Le PicoLTE est utilisé pour assurer la connectivité NB-IoT (à la fois eNodeB et EPC) tandis que le C030 d’Ublox est utilisé en mode Non-IP pour échanger des données Non-IP avec des serveurs d’applications distants. Le C030 est connecté au PicoLTE par des câbles RF (figure 1).

Dans ce scénario NB-IoT End-to-End, seules les données MO NonIP sont prises en compte. Les données mesurées par les capteurs de la C030 – GPS, température, humidité, accélération – seront publiées par le modem NB-IoT N211 vers le cloud via le PicoLTE EPS.

Ce démonstrateur peut être reproduit pour réaliser des communications conduites ou aériennes. La figure 1 illustre une configuration conduite où le C030 est connecté au PicoLTE par des câbles RF. La configuration OTA doit être installée dans une chambre anéchoïque pour éviter toute interférence avec les opérateurs. La configuration OTA ne fait pas partie du champ d’application de cette note d’application.

Figure 1 – Configuration du PicoLTE et du C030 pour tester la livraison de données de bout en bout

La figure 2 illustre un montage typique comprenant des modules RF tels que le diviseur/combineur de puissance RF, le circulateur et l’atténuateur. Il est possible de tester plusieurs dispositifs simultanément en fonction du nombre de canaux du diviseur/combineur de puissance. Il convient de noter que les dispositifs RF dépendent de la fréquence et qu’il faut utiliser un diviseur/combineur de puissance, un circulateur et un atténuateur adaptés à la fréquence porteuse de fonctionnement. Le C030-N211 peut fonctionner sur la bande 8 ou 20. Par conséquent, les dispositifs RF sélectionnés doivent supporter ces bandes.

Figure 2 – Configuration du PicoLTE et du C030 conduit

Configuration du eNodeB PicoLTE.

À des fins de démonstration, le PicoLTE exécute une cellule NB-IoT en mode autonome à 801 MHz (bande LTE 20), comme le montre la figure 2. Les fichiers de configuration sont fournis dans le répertoire /opt/nutaq/picolte/examples/eps/ciot/nb-iot/nb1/standalone/enb.

Le fichier de configuration principal est enb.cfg situé dans le répertoire « ./enb ». Il comprend les fichiers de configuration suivants :

Fichier de configuration

Description
enb.cfg C’est le fichier de configuration principal. Il s’agit d’une syntaxe basée sur JASON.
sib1.asn Fichier de configuration du System Information Block 1 (SIB1). Il s’agit d’une syntaxe basée sur l’ASN.
sib2_nb.asn Fichier de configuration du bloc d’informations système 2 (SIB2) pour le scénario de bande étroite LTE. Il s’agit d’une syntaxe basée sur l’ASN.
drb_nb.asn Fichier de configuration de Data Radio Bearer (DRB) pour le scénario LTE Narrow Band. Il s’agit d’une syntaxe basée sur JSON.
rf_driver.cfg Il s’agit du fichier de configuration de la tête radio et de la logique DUC/DDC implémentée sur le FPGA. Il s’agit d’une syntaxe basée sur JSON.
rf_front_end.cfg Tableau de consultation des gains des amplificateurs. Les gains appropriés sont sélectionnés en fonction de la puissance de sortie requise définie dans le fichier de configuration rf_driver.cfg.

NB : Ne pas modifier le fichier de configuration rf_front_end.cfg. 

Tableau 1 – Fichiers de configuration de l’eNodeB

L’eNodeB est connecté à l’EPC et prend en charge différents PDN, notamment le PDN non-IP pour gérer la connectivité non-IP et le NIDD pour les cas MO et MT.

Réglage des fréquences centrales DL/UL

Comme les fréquences centrales DL et UL dans le LTE sont liées, on peut utiliser le DL EARFCN pour configurer les fréquences porteuses d’exploitation à la fois pour la liaison montante et la liaison descendante. Le DL EARFCN pour les bandes LTE standard peut être configuré dans le fichier de configuration enb.cfg situé dans le dossier ./enb. Le nom du paramètre est dl_earfcn.

Paramètre

Description
dl_earfcn Liaison descendante EARFCN

Exemple :

dl_earfcn: 6250,/*DL: 801 MHz et UL: 842 MHz (Band 20) */

Tableau 2 – Réglage de DL EARFCN

Figure 3 – Spectre de la cellule NB-IoT à 801 MHz (Bande 20 du LTE)

Il existe de nombreux outils web qui peuvent être utilisés pour trouver le EARFCN approprié en fonction de votre configuration. Le suivant propose de calculer à la fois la fréquence porteuse et les EARFCN :http://niviuk.free.fr/lte_band.php.

Réglage de la puissance de sortie

La puissance de sortie peut être configurée dans le fichier de configuration rf_driver.cfg situé dans le dossier ./enb . Le nom du paramètre est power_output.

Paramètre

Description
power_output Puissance de sortie [dBm]. Pour la radio640, la plage est comprise entre -39 (valeur minimale) et -8 (valeur maximale).

Exemple :

power_output:-10,/*La puissance de sortie [dBm] est fixée à -10 dBm*/

Tableau 3 – Réglage de la puissance de sortie RF

Réglage du gain RX

Le gain de réception peut être configuré dans le fichier de configuration rf_driver.cfg situé dans le dossier ./enb . Le nom du paramètre est rx_front_end_gain.

Paramètre

Description
power_output Amplificateur à gain variable Rx en dB. Les valeurs pour la radio640 dépendent des bandes utilisées. 0dB est la valeur maximale et 70 dB est la valeur minimale.

Exemple :

rx_front_end_gain: 30,/*Régler le gain total de la réception à 30 dB*/

Tableau 4 – Réglage du gain de réception

Réglage du port RF

Le port RF peut être configuré dans le fichier de configuration rf_driver.cfg situé dans le dossier ./enb. Les noms des paramètres sont downlink_rf_port_x et upink_rf_port_x, où x est l’index de la cellule. Le tableau suivant indique les ports RF appropriés pour le scénario d’une cellule. Dans le cas de cellules multiples, veuillez vous reporter au Guide de l’utilisateur du PicoLTE pour plus de détails sur la configuration de cellules multiples.

Paramètre

Description
downlink_rf_port_0 Les cellules indexent l’affectation aux ports RF physiques.

Exemple :

downlink_rf_port_0: 1,/*Une cellule transmettant sur le port RF TRX1*/
uplink_rf_port_0 Les cellules indexent l’affectation aux ports RF physiques.

Exemple :

uplink_rf_port_0: 1,/*Une cellule recevant sur le port RF RX1*/

Tableau 5 – Réglage des ports RF

Activer ou désactiver l’embrouillage

Le brouillage fait ici référence aux changements NPBCH/BCCH tels que spécifiés dans la version 13.5 de 3GPP. Le nom du paramètre est rel13_5 et peut être configuré dans le fichier de configuration enb.cfg.

Paramètre

Description
rel13_5 Version 13.5 Modifications du brouillage NPBCH/BCCH.

Exemple :

rel13_5: true,/* modifications du brouillage NPBCH/BCCH de la version 13.5 */

Tableau 6 – Réglage de l’embrouillage NPBCH/BCCH

Pour régler tout autre paramètre non répertorié sur cette page, veuillez lire la description de ce paramètre dans le Guide de l’utilisateur des paramètres de configuration et contacter support@nutaq.com pour toute aide.

Configuration de l’EPC PicoLTE

À des fins de démonstration, le PicoLTE exécute une configuration EPC permettant la gestion des appareils NB-IoT. Les fichiers de configuration sont fournis dans le répertoire /opt/nutaq/picolte/examples/eps/ciot/nb-iot/nb1/standalone/epc.

Le fichier de configuration principal est mme.cfg situé dans le répertoire « ./epc ». Il peut inclure la base de données de l’UE si elle n’y est pas déjà définie en utilisant la liste d’objets JSON : ue_db. Chaque objet de cette liste définit un abonné qui est défini par les informations USIM.

Fichier de configuration

Description
mme.cfg C’est le fichier de configuration principal. Il s’agit d’une syntaxe basée sur JASON.
ue_db-ims.cfg Base de données des équipements de l’utilisateur. Il s’agit d’une syntaxe basée sur JASON.

Tableau 7 – Fichiers de configuration de l’EPC

Activer ou désactiver l’optimisation CIoT du plan de contrôle

L’optimisation du plan de contrôle cellulaire IoT EPS est une fonctionnalité du CIoT. Elle peut être activée à l’aide du paramètre cp_ciot_opt dans le fichier de configuration imme.cfg. Notez que les modems NB-IoT actuels, y compris le N211 sur les cartes d’application C030, ne prennent en charge que l’optimisation CP-CIoT EPS et non l’optimisation DRB. Par conséquent, le paramètre cp_ciot_opt doit être défini sur true.

Paramètre

Description
cp_ciot_opt Prise en charge de l’optimisation EPS de l’IoT cellulaire dans le plan de contrôle

Exemple :

cp_ciot_opt: true,/*Activer l’optimisation EPS Cellular IoT du plan de contrôle */

Tableau 8 – Réglage de l’optimisation CIoT du plan de contrôle

Définition du PDN

Un ou plusieurs PDN peuvent être définis dans le fichier de configuration mme.cfg à l’aide de la pdn_list. Il s’agit d’une liste JSON d’un ou plusieurs objets PDN. Le tableau suivant résume les paramètres clés d’un objet PDN.

Paramètre

Description
pdn_type Sélectionnez le type de PDN.

Les types de PDN disponibles sont ipv4, ipv6, ipv4v6, non-ip (par défaut = ipv4).
access_point_name Définir le nom du point d’accès
first_ip_addr Première adresse IPv4 disponible.
last_ip_addr Dernière adresse IPv4 disponible.
ip_addr_shift Les adresses IPv4 allouées le sont à partir de first_ip_addr avec une différence de 2^ip_addr_shift. Par conséquent, last_ip_addr – first_ip_addr doit être un multiple de 2^ip_addr_shift. Cette option est utile en cas de communication inter-UE pour s’assurer que l’adresse IPv4 d’un UE donné est la seule dans son masque de réseau.
p_cscf_addr Adresses IPv4 ou IPv6 des serveurs PCSCF (VoLTE).
dns_addr Les adresses IPv4 ou IPv6 des serveurs DNS.
first_ipv6_prefix Premier préfixe IPv6 global disponible utilisé dans le message d’annonce de routeur envoyé à l’UE (seuls les 8 octets supérieurs de l’adresse IPv6 sont significatifs). Notez que le préfixe sélectionné sera également utilisé comme identifiant d’interface envoyé dans la signalisation NAS.
last_ipv6_prefix Dernier préfixe IPv6 global disponible utilisé dans le message d’annonce de routeur envoyé à l’UE (seuls les 8 octets supérieurs de l’adresse IPv6 sont significatifs). Notez que le préfixe sélectionné sera également utilisé comme identifiant d’interface envoyé dans la signalisation NAS.
erabs Tableau d’objets. Chaque élément définit un E-RAB (E-UTRAN Radio Access Bearer) associé au PDN. Le premier E-RAB est le support radio par défaut et doit toujours être présent. Les E-RAB supplémentaires sont des supports radio dédiés et doivent inclure un modèle de flux de trafic (TFT), sauf s’ils sont définis comme étant initiés par l’UE.

qci – QoS Class Identifier of the E-RAB.

priority_level – Niveau de priorité.

pre_emption_capability – Enumération: shall_not_trigger_pre_emption ou may_trigger_pre_emption.

pre_emption_vulnerability – Enumération: not_pre_emptable ou pre_emptable.
Exemple

NonIP

{   pdn_type: « non-ip », 

     // access_point_name: « internet », 

     //first_ip_addr: « 192.168.3.2 », 

    //last_ip_addr: « 192.168.3.254 », 

    //ip_addr_shift: 2, /* difference between allocated IP addresses is 4 */ 

    //p_cscf_addr: [« 192.168.3.1 »], //dns_addr: « 8.8.8.8 », /* Google DNS address */ 

    //erabs: [{ qci: 9, 

          //priority_level: 15, 

         //pre_emption_capability: « shall_not_trigger_pre_emption », 

        //pre_emption_vulnerability: « not_pre_emptable », 

    //},], 

},

Table 9 — Public Data Network parameters

PDN non IP

L’EPC peut s’en charger :

  • Établissement d’une connexion PDN non IP
  • Données MO non-IP
  • MT Données non IP
  • Événements non-IP

L’EPC fournit une API qui peut être utilisée par un service externe pour s’inscrire à des événements non IP et transmettre des données non IP à la fois sur la liaison montante et descendante entre le serveur d’application distant et l’EPC. L’EPC gère le trafic non IP vers et depuis les appareils NB-IoT.

Un PDN Non-IP doit être configuré pour permettre la livraison de données Non-IP. Il suffit de définir le paramètre pdn_type d’un objet PDN sur « non-ip« .

Base de données de l’UE

La base de données de l’UE peut être définie dans le fichier de configuration mme.cfg ou elle peut être définie dans un fichier séparé et incluse dans le fichier de configuration mme.cfg à l’aide de la directive include (include « ue_db-ims.cfg« ,). Le paramètre ue_db est un tableau JSON d’objets qui doivent être utilisés pour configurer la base de données utilisateur. Chaque élément de ce tableau est une entrée pour un utilisateur. Les propriétés suivantes sont disponibles :

Parameter

Description
sim_algo Enumération facultative, xor, milenage ou tuak (par défaut = xor). Définit l’algorithme d’authentification de la carte SIM. Remarque : les cartes USIM de test utilisent l’algorithme XOR.
imsi Définissez l’IMSI.
amf Définissez le champ Gestion de l’authentification.
sqn Définir le numéro de séquence initial. Pour l’algorithme XOR, la valeur réelle n’a pas d’importance. Pour l’algorithme Milenage ou TUAK, une resynchronisation du numéro de séquence est lancée si le numéro de séquence ne correspond pas à celui stocké dans l’USIM.
K Définissez la clé secrète de l’utilisateur (sous forme de chaîne hexadécimale de 16 octets).
multi_sim S’il est défini à true, permet à plusieurs UE d’avoir la même IMSI (utile lors de l’utilisation simultanée de plusieurs cartes SIM de test identiques dans différents UE). Ils se distinguent par leur IMEI. Remarque : cette option n’est autorisée qu’avec l’algorithme d’authentification XOR.
Exemple

ue_db: [ { 

     sim_algo: « xor », /* USIM authentication algorithm: xor, milenage or tuak */ 

     imsi: « 001010123456789 », /* Anritsu Test USIM */

     amf: 0x9001, /* Authentication Management Field */ sqn: « 000000000000 », /* Sequence Number */ 

     K: « 00112233445566778899aabbccddeeff », /* Anritsu Test USIM */ 

     multi_sim: true, 

     }, 

     /* Add new entries for each IMSI/K */ 

     ],

Tableau 10 – Configuration de la base de données de l’UE

Chemin de données de bout en bout non-IP versus IP

L’eNodeB est connecté à l’EPC et supporte différents PDN dont un PDN de type IPv4. Ce PDN permet d’apporter la connectivité internet aux dispositifs enregistrés en utilisant l’APN « internet ». Il permet essentiellement une connectivité de bout en bout et la livraison de données dans les deux sens, c’est-à-dire dans les cas de Mobile Originating et Mobile Terminating.

Une fois que les appareils se sont enregistrés sur le réseau et ont établi un support EPS vers le PDN NonIP, ils peuvent se connecter à des serveurs distants sur le nuage. Tout le trafic NonIP dans les deux sens (MO ou MT) circule sur le chemin de données de couleur rouge.

Figure 4 – Chemin de données IP pour les cas d’utilisation IoT de bout en bout

Le serveur NIDD gère la livraison de données non IP vers et depuis l’appareil NB-IoT C030. Il s’inscrit aux événements non IP gérés par l’EPC et traite les données non IP transmises par les UE au serveur d’application distant. Si un événement non-IP est généré par l’EPC, le serveur NIDD acquiert les données transmises par les UE et les transmet immédiatement au serveur d’applications distant. Pour les données MT Non-IP, le serveur NIDD transmet les données envoyées par l’AS à l’EPC en paquets Non-IP à l’appareil NB-IoT C030 identifié par un ID unique qui est l’IMSI de sa carte USIM.

C030 Carte d’application NB-IoT

La carte d’application u-blox C030 est une solution de prototypage rapide prête à l’emploi pour les applications IoT prenant en charge les nouvelles technologies cellulaires LPWA (low power wide area), telles que NB-IoT, et les réseaux 2G/3G existants. La carte est alimentée par un processeur hôte Cortex-M4 intégré, compatible ARM Mbed, doté d’une mémoire FLASH de 1 Mo et d’une mémoire vive de 256 Ko, ce qui laisse beaucoup d’espace pour le développement et le débogage de logiciels.

La carte d’application C030-N211 est un kit de démarrage NB-IoT compatible Mbed avec la SARA-N211 (NB-IoT), le MAX-M8C et le CPU Cortex M4. Elle permet :

  • Prototypage rapide avec Arm Mbed sur le CPU hôte intégré
  • Test simple des applications de positionnement avec GNSS intégré
  • Idéal pour les conceptions à très faible consommation et les facteurs de forme compacts
  • Capturez facilement les données des capteurs avec les shields Arduino

Micrologiciel du modem N211

Le N211 a actuellement deux versions de firmware utilisées essentiellement pour tester les applications suivantes :

  • LWM2M/CoAP de bout en bout
  • Livraison de données non IP
  • Echo UDP

Le tableau 11 résume les micrologiciels disponibles pour le modem N211 et la liste des applications que nous avons testées jusqu’à présent avec la carte d’application C030.

C030 N211-FWPKG

C030 STM32-Mbed

Capteurs
LWM2M/CoAP 06.57, A01.02 Programme Mbed généré par uArgus (chaîne d’outils Mbed de Windows) Température
Livraison de données non IP 06.57, A01.02 c030-3LED_ModemAccess_ProductionFirmware.bin Données générées sur le PC hôte STM32 By-pass (3LED ModemAccess Production FW)
Echo UDP 06.57, A07.03 c030-3LED_ModemAccess_ProductionFirmware.bin Données générées sur le PC hôte STM32 By-pass (3LED ModemAccess Production FW)

Figure 11 – Micrologiciel N211 par rapport aux applications testées

Pour mettre à jour ou rétrograder le firmware du modem N211, contactez Ublox pour obtenir le logiciel correspondant.

Ubidots Cloud Service

Pour la démonstration, nous proposons d’utiliser le serveur cloud d’Ubidots car il est simple et facile à configurer. Pour cela, vous devez charger le firmware de contournement sur l’application MCU, créer votre compte sur le portail Ubidots, obtenir votre jeton, puis vous devriez être en mesure de reproduire le démonstrateur Non-IP et de tester la livraison de données Non-IP UL et DL.

Enregistrement du dispositif

Enregistrer un nouveau dispositif

Ubidots fournit un portail Web pour enregistrer et gérer les appareils IoT. Il est possible d’enregistrer un nouvel appareil en utilisant l’IMEI du modem NB-IoT du C030 et d’attribuer un nom à ce nouvel appareil.

Gestion de la livraison des données non IP

Sur le C030, nous générons des données aléatoires variant entre 34 et 45 pour simuler la température du corps. Les données sont transmises en mode Non-IP à l’EPC sur NAS. Un serveur de type websocket est exécuté sur le PicoLTE pour gérer le NIDD. Lorsqu’un événement Non-IP est généré par l’EPC, le serveur NIDD capture les paquets Non-IP et les transmet à un serveur d’application distant. Nous avons utilisé Ubidots à des fins de démonstration. L’utilisateur peut se connecter à Ubidots et afficher de manière conviviale l’évolution de la température transmise en temps réel comme illustré dans la Figure 5.

Figure 5 – Données publiées sur le serveur cloud d’Ubidots

La liste des appareils enregistrés peut être affichée sur cette page Web. L’état de l’appareil est indiqué. Si l’appareil est enregistré et actif, un bouton est disponible pour ouvrir sa page web et afficher les mesures rapportées et publiées sur ce serveur cloud.

Les scripts python suivants sont fournis à la fois pour le dispositif et le réseau afin de générer et de gérer la livraison de données non IP vers le nuage :

  • Dispositif C030-N211: /opt/nutaq/picolte/utilities/ue/ublox/n2xx/N211-Ubidots.py
    • Ce script python configure le modem NB-IoT N211 en mode Non-IP, génère des données et les transmet au réseau. Nous utilisons la commande AT +CGDCONT pour définir le contexte du Packet Data Protocol. Voici un exemple d’utilisation de cette commande AT PDP : AT+CGDCONT=1, » »NONIP » », » »nonip » ».
      • « NONIP » spécifie le contexte PDP Non-IP
      • « nonip » est l’APN défini dans le PDN Non-IP dans le fichier de configuration du MME.
    • Nous utilisons la commande AT « AT+CSODCP » pour envoyer les données générées. L’envoi des données non-IP est géré par la fonction « sendNIPData ».
  • Réseau :
    • Livraison de données MO NonIP : /opt/nutaq/picolte/utilities/ue/ublox/n2xx/dl-nidd.py
      • Ce script s’enregistre aux événements non-IP. Dès que les données non-IP sont disponibles sur le MME, nous les extrayons du message et nous transmettons les données au serveur cloud distant Ubidots.
    • Livraison de données MT NonIP : /opt/nutaq/picolte/utilities/ue/ublox/n2xx/ul-nidd.py
      • Ce script génère des données et les envoie à l’appareil en utilisant le mode Non-IP. Les données Non-IP sont affichées sur l’appareil dès qu’elles sont reçues. Ce script sera mis à jour pour gérer de bout en bout des données MT Non-IP. Les données seront essentiellement envoyées depuis un service distant sur le cloud et cet utilitaire les transmettra en mode Non-IP au dispositif approprié.