9) Edge, IoT & 5G
Protocoles IoT (MQTT/CoAP/AMQP/LwM2M) · Sécurité/identité (TLS/mTLS/DTLS, TPM, Secure Boot) · Provisioning & OTA · Passerelles terrain & LPWAN · Edge compute (Greengrass, Azure IoT Edge, K3s/KubeEdge) · Pipelines (Kafka/NATS/Flink) · Timeseries DB · 5G privé (gNB/5GC/UPF), slicing (eMBB/mMTC/URLLC, 5QI), MEC/offload · Observabilité/tests.
MQTT/CoAP Sécurité Provisioning/OTA Gateways Edge compute Timeseries 5G privé MEC/Slicing
Protocoles IoT — MQTT, CoAP, AMQP, LwM2M (CBOR/COSE)
| Proto | Transp. | Modèle | QoS/Fiabilité | Payload | Cas d’usage |
|---|---|---|---|---|---|
| MQTT 3.1.1/5 | TCP/TLS (1883/8883) | Pub/Sub via broker | 0/1/2 • Retain • Will • Session Expiry (v5) | JSON/CBOR | Capteurs/gateways |
| CoAP | UDP/DTLS | REST (GET/PUT/POST/OBSERVE) | CON/NON • Observe • Block-Wise | CBOR | Objets contraints |
| AMQP 1.0 | TCP/TLS | Message-bus & transactions | Acks, liens, transactions | Binaire | Interop entreprise |
| LwM2M | UDP/DTLS ou TCP/TLS | Gestion Device (objets OMA) | — | TLV/CBOR | Inventaire/OTA |
Rappel énergie : UDP/DTLS & CoAP = échanges plus courts → meilleurs budgets batterie que TCP/TLS sur liaisons instables.
Diagramme : Pub/Sub MQTT (v5)
capteur ──► broker ──► analytics
▲ │ ▲
└──── retain ─┴─ LWT ──────┘
QoS 0 : non garanti
QoS 1 : au moins une fois (dup possibles)
QoS 2 : exactement une fois (handshake 4 étapes)Design topics
- Convention :
site/{line}/device/{id}/sensor/{name} - Unités SI (°C, Pa, m/s) • normalisation via JSON-Schema
- Limiter wildcards côté publish, privilégier côté subscribe
- Compression CBOR (+40–60 % vs JSON)
Chiffres de charge (ordre de grandeur)
| Scénario | Nb. devices | Msg/s | Débit utile | Back-pressure |
|---|---|---|---|---|
| Usine | 5 000 | 1 k | ~3–5 Mb/s | Retain config, QoS1 télém. |
| Ville | 50 k | 10 k | ~30–50 Mb/s | Partitionnement topics |
# Mosquitto : conf sécurité + perf
listener 8883
cafile /etc/ssl/ca.crt
certfile /etc/ssl/broker.crt
keyfile /etc/ssl/broker.key
require_certificate true
persistence true
max_inflight_messages 50
message_size_limit 1048576
MQTT 5 : properties (expiry, response-topic), shared-subscriptions (
$share/{grp}/topic), session expiry.# Test rapide
mosquitto_sub -h broker -t 'site/+/device/+/sensor/#' -v
mosquitto_pub -h broker -t 'site/a/device/42/sensor/temp' \
-m '{"v":22.4,"u":"C","ts":1737480000}'Astuce : grouper champs fréquents (tags) et mesures (fields) → ingestion facile vers Influx/Timescale.
CoAP/DTLS
- Observe (RFC 7641) pour flux • Block-Wise (RFC 7959)
- Codes 2.xx/4.xx/5.xx • retransmissions (CON)
- DTLS PSK/ECDSA • OSCORE (end-to-end)
| Op | Latence typ. | Overhead | Énergie |
|---|---|---|---|
| GET NON | ~10–30 ms LAN | Faible | Très basse |
| GET CON | ~20–60 ms | Moyen | Basse |
| OBSERVE | ~10–50 ms/event | Faible | Très basse |
# Client CoAP
coap-client -m get coaps://node/.well-known/core
coap-client -m get -s 5 coap://node/sensor/temp # observe
# DTLS PSK
coap-client -m get -u 'id' -k 'secret' coaps://node/rLwM2M (gestion)
- Objets : identité, connectivité, app, firmware
- Bootstrap → endpoints + credentials
- Observation/notify, Create/Write/Execute
Flux typique (LwM2M)
Device ── bootstrap → Serveur BS
Device ← objets/acl ─ Serveur LwM2M
Device ⇄ observe/notify ⇄ ServeurFormats
| Format | Taille msg (ex.) | Gain vs JSON | Note |
|---|---|---|---|
| JSON | ~150 B | — | Lisible |
| CBOR | ~80–90 B | ~40% | Binaire compact |
| ProtoBuf | ~70–85 B | ~45% | Schéma fort |
Exemple CBOR (pseudo)
{ t: 1737480000, dev: 42, temp: 22.4, u: "C" }Brokers & Messaging — Mosquitto, EMQX, HiveMQ • Bridge Kafka/NATS • Perf/Tuning
# /etc/mosquitto/conf.d/secure.conf
listener 8883
cafile /etc/ssl/ca.crt
certfile /etc/ssl/broker.crt
keyfile /etc/ssl/broker.key
require_certificate true
use_identity_as_username true
persistence true
max_inflight_messages 50
message_size_limit 1048576
# EMQX ACL (exemple)
{allow, {user, "dev-42"}, subscribe, ["site/a/#"]}.
{allow, all, publish, ["telemetry/#"]}.
{deny, all}.
# Bridge EMQX -> Kafka (concept)
bridges.kafka.servers = kafka-1:9092,kafka-2:9092
bridges.kafka.topics = site/+/device/+/sensor/# -> topic=iot.telemetry
# NATS connector (pseudo)
nats.request "broker.bridge" "sub=iot.telemetry"
Ordres de grandeur
| Infra | Sub/MSGS | Débit | Remarques |
|---|---|---|---|
| 1 broker VM 4vCPU | ~50k/5k | ~30–60 Mb/s | QoS1, TLS |
| Cluster 3 brokers | ~200k/20k | ~150–250 Mb/s | Sharded topics |
- Retain = config; éviter sur télémétrie continue
- Limiter QoS2; préférer QoS1 + idempotence
- Store-and-forward en gateway
Sécurité & Identité — TLS/mTLS/DTLS, TPM, Secure Boot, ACE-OAuth, SBOM
Identité & secrets
- X.509, mTLS (client cert), rotation
- TPM/ATECC — stockage clé (PKCS#11)
- JITP/JITR (just-in-time provisioning)
Journalisation
- Connexions TLS, échecs mTLS, refus ACL
- SBOM + CVE feed → alerting
AuthN/AuthZ
- JWT/ACE-OAuth • scopes par topic/ressource
- DTLS pour CoAP (PSK/ECDSA) • OSCORE
- Zero-Trust : micro-segmentation, PEP sur gateway
Secure lifecycle
- Secure/Measured Boot, anti-rollback
- Firmware signé, canary OTA, A/B slots
- Chiffrement au repos (LUKS/eMMC)
# Sanity TLS
openssl s_client -connect broker:8883 -showcerts
# CoAP DTLS (PSK)
coap-client -m get -u 'dev42' -k 'PSK...' coaps://gw/infoProvisioning & OTA — Certificats, eSIM/eUICC, Manifests, Canaries
- Pré-provision CA & empreintes usine
- CSR + challenge online → délivrance court-terme
- Rotations planifiées (90/180 jours)
- Canary %, reprise sur échec, delta OTA
- Signature & vérification, anti-rollback
# Azure IoT Edge deployment.json (extrait)
{
"modulesContent":{
"$edgeAgent":{"properties.desired":{"modules":{
"telemetry":{"settings":{"image":"repo/telemetry:1.2"}}
}}}}
}
Hypothèses
| État | Courant | Durée/j | Charge |
|---|---|---|---|
| Sleep | 10 µA | 23.9 h | 0.239 mAh |
| Wake+Tx | 120 mA | 20 s | 0.667 mAh |
| Total | — | — | ~0.906 mAh/j |
Batterie 2 000 mAh → ~2 210 jours (~6.0 ans) hors vieillissement/Temp.
Diagramme simplifié
[Sleep 99.9%] ─┬─► [Wake] ─► [Tx MQTT QoS1] ─► [Sleep]
└─► [OTA (rare, gros budget)]Passerelles & réseaux terrain — Fieldbus, Mesh, LPWAN (LoRaWAN/NB-IoT/LTE-M)
| Techno | Débit plafond | Latence | Énergie | Couverture | Taille msg typ. | Coût/mo |
|---|---|---|---|---|---|---|
| LoRaWAN | 0.3–50 kb/s | sec | Très basse | Très large | 51–222 B | 0 |
| NB-IoT | ~250 kb/s | sec | Très basse | Cellulaire | ~1 kB | ~0.2–0.8 € |
| LTE-M | 0.3–1.0 Mb/s | ~100 ms | Basse | Cellulaire | ~10 kB+ | ~0.5–1.5 € |
- OPC-UA PubSub via MQTT (interop cloud)
- Temps réel → réseau dédié, QoS, isolation VLAN
Architecture type (industrie)
PLC ── OPC-UA ──► Gateway Edge ── MQTT ─► Broker
▲ │
Modbus/TCP └─ Kafka/S3- Zigbee, Thread (IPv6/6LoWPAN), BLE Mesh
- Border-router Thread → IP routable
Edge Computing — Greengrass, Azure IoT Edge, K3s/KubeEdge, WebAssembly/Node-RED
# Déploiement K3s (edge)
curl -sfL https://get.k3s.io | sh -
# KubeEdge (conceptuel)
keadm init --advertise-address <cloud-ip>
keadm join --cloudcore-ipport <cloud-ip:10000> --edgenode-name node-1# Greengrass v2 (recipe simplifiée)
{
"RecipeFormatVersion":"2020-01-25",
"ComponentName":"com.example.telemetry",
"Manifests":[{"Platform":{"os":"linux"},
"Artifacts":[{"URI":"s3://bucket/telemetry.zip"}]}]
}# Edge deployment (extrait)
{
"modulesContent":{
"$edgeAgent":{"properties.desired":{"modules":{
"nodered":{"settings":{"image":"nodered/node-red:latest"}},
"mqtt":{"settings":{"image":"eclipse-mosquitto:2"}}
}}}}
}
- WebAssembly (Wasm) pour filtres à faible empreinte
- Node-RED pour pipelines visuels
Flux Edge typique
Modbus → Normalise → (Wasm) Filtre → MQTT pub → Broker/KafkaPipelines & Timeseries — Kafka/NATS/Flink • InfluxDB/Timescale • S3/Parquet
Ingestion
- MQTT→Kafka Connect→S3/TSDB
- Schema Registry (Avro/JSON-Schema)
- Compression zstd/parquet
Timeseries
- Influx (line protocol), Timescale hypertables
- Downsampling & retention par bucket
# Influx line
telemetry,site=a,dev=42 temp=22.4,hum=48 1737480000000
# NATS sub
nats sub iot.telemetryCoûts & stockage (ex. ordre de grandeur)
| Flux/j | S3 (Parquet, zstd) | Coût ~ | Notes |
|---|---|---|---|
| 10 M messages | ~2.5–3.5 GB | ~0.07–0.10 € | Objets journaliers |
| 100 M messages | ~25–35 GB | ~0.7–1.0 € | Partitionnement heure |
Diagramme pipeline
Broker MQTT → Kafka → (Flink) enrichit → Timeseries + S3
└──► Alerts (Prometheus/Grafana)Observabilité & Tests — SLO, bench MQTT/CoAP, traces, capture réseau
- Latence p95 pub→sub, perte, retries
- Backlog broker, inflight, dropped
- Uptime 5G/Edge, jitter RAN
- Erreur OTA, % devices outdated
SLO exemple
p95 latency < 150 ms ; loss < 0.1% ;
availability > 99.9%# emqtt_bench (ex.)
emqtt_bench sub -t 'load/#' -q 1 -n 1000
emqtt_bench pub -t 'load/x' -q 1 -s 200 -n 100000 -r 1000# Observe 10s
coap-client -m get -s 10 coap://node/sensor/temptcpdump -ni any 'port 1883 or port 8883 or udp port 5683'
tshark -Y "mqtt or coap" -T fields -e frame.time -e mqtt.topic5G Privée — gNB, 5GC (AMF/SMF/UPF), SIM/eSIM, DNN/APN, RAN split (CU/DU)
5GC
- AMF (NAS), SMF (PDU sessions), UPF (data plane)
- AUSF/UDM (auth/abonnés), PCF (policy)
SIM/eSIM
- IMSI/K • eUICC profils • DNN (ex-APN)
UE ⇄ gNB (NR) ⇄ 5GC(AMF/SMF/UPF) ─► LAN/MEC/Internet
▲ ▲
RAN Policy/ChargingNumerology (ordre de grandeur)
| SCS (kHz) | Slot | Utilisation |
|---|---|---|
| 15/30 | 1/0.5 ms | Couverture |
| 60 | 0.25 ms | Faible latence |
Bandes locales (ex. 3.7 GHz EU) & CBRS (US).
gNB split
RU (radio) ⇄ DU (MAC) ⇄ CU (PDCP)
│ └─ 5GC# Open5GS (extrait UPF)
upf:
pfcp: { addr: 10.0.5.10 }
gtpu: { addr: 10.0.5.10 }
subnet:
- addr: 10.200.0.0/16
Local breakout = trafic IoT vers LAN/Edge sans transiter par le core central → latence < 10–20 ms possible.
Network Slicing & QoS — eMBB/URLLC/mMTC • 5QI • Mapping L3
5QI (exemples)
| 5QI | Type | Latence cible | Perte | Mapping DSCP |
|---|---|---|---|---|
| 1 | GBR (VoIP) | <100 ms | 1e-2 | EF(46) |
| 9 | Non-GBR (Data) | — | 1e-6 | BE(0) |
| 75 | URLLC | <10 ms | 1e-5 | CS5/EF |
# free5GC Policy (pseudo)
qos:
- slice: "1-010203" # S-NSSAI
dnn: "iot"
5qi: 75
gbr: {ul: "1M", dl:"1M"}
arp: "high"MEC & Offload — UPF local breakout • Traffic steering • APIs ETSI MEC
Local Breakout
UPF sur site → flux IoT vers LAN/Edge, sans cœur central
Placement fonctions
AMF/SMF centralisés; UPF/CDN/IA au MEC
# Steering (concept)
if slice == "URLLC": route via UPF-MEC
else: route via UPF-centralPatterns & Conformité — Zero-Trust IoT • IEC 62443 • ETSI EN 303 645 • 3GPP/ETSI MEC
Zero-Trust IoT
- Identité forte par device
- AuthZ par sujet/topic/ressource
- Monitoring continu
Conformité
- IEC 62443, ISO 27001, ETSI EN 303 645
- 3GPP TS 23.x / ETSI MEC
# Checklist déploiement
[ ] Inventaire devices & certificats
[ ] Journalisation (broker/RAN/5GC)
[ ] SLO & alertes
[ ] Plan de clé/rotation/OTA