HCIP-IoT cheat sheet

Four-layer reference architecture: perception/device layer (sensors, actuators, MCUs) → network/transport layer (NB-IoT, ZigBee, Ethernet) → platform layer (device management, data storage, APIs) → application layer (vertical apps).

OneNET/OceanConnect-style three-tier split aligns with ITU-T IoT: device domain, network domain, application domain; the platform is the boundary between network and application domains.

MQTT is a publish/subscribe protocol over TCP; brokers decouple devices from apps via topics. QoS 0 = at most once, QoS 1 = at least once, QoS 2 = exactly once.

CoAP runs over UDP, uses request/response with GET/POST/PUT/DELETE, and supports observe for push; suited to constrained devices and lossy networks (RFC 7252).

LwM2M is a device-management protocol layered on CoAP; object 3 = Device, object 4 = Connectivity Monitoring, object 5 = Firmware Update, object 1 = Server.

CAP theorem: a distributed IoT platform cannot simultaneously guarantee consistency, availability, and partition tolerance; most IoT data planes choose AP with eventual consistency.

Edge–cloud continuum: latency-critical control stays at the edge; aggregation, analytics, and long-term storage move to the cloud.

Scalability rule: connection count drives session/broker capacity, message rate drives throughput, payload size × rate drives bandwidth and storage.

Gateway functions: protocol translation (ZigBee/Modbus/BLE → MQTT/HTTP), local buffering, edge pre-processing, device access authentication, and NAT traversal for downstream devices.

Southbound interfaces face devices (ZigBee, Z-Wave, RS-485/Modbus, BLE); northbound interfaces face the platform (MQTT, HTTPS, CoAP).

Transparent transmission (passthrough) mode: the gateway forwards raw payloads and the platform parses them; non-transparent mode: the gateway parses and normalizes to a defined model.

Device identity: each device needs a unique deviceId and secret/certificate; gateway-proxied devices carry a sub-device ID so the platform can address them individually.

Connection decision rule: battery-powered, low-rate, wide-area → NB-IoT/LoRa; mains-powered, high-rate, local → Wi-Fi/Ethernet; mesh with many nodes → ZigBee/Thread.

Offline caching: gateways store telemetry when the uplink is down and replay on reconnect; ordering must be preserved and duplicates de-duplicated by message ID.

NAT and firewall traversal for downstream devices rely on the gateway maintaining persistent outbound connections to the platform rather than inbound connections.

ZigBee is IEEE 802.15.4-based, 2.4 GHz (also 868/915 MHz), 250 kbps at 2.4 GHz, supports star/tree/mesh; three device roles: coordinator, router, end device.

ZigBee uses 16-bit short or 64-bit IEEE MAC addresses; the coordinator forms the PAN and assigns the PAN ID and network address.

Wi-Fi 802.11n: 2.4/5 GHz, up to 600 Mbps with 4 spatial streams and 40 MHz channels; 802.11ac is 5 GHz only; 802.11ax is Wi-Fi 6.

Wi-Fi power save (PS-Poll, WMM U-APSD) trades latency for battery life; Wi-Fi is unsuitable for multi-year coin-cell devices because of association and beacon overhead.

Bluetooth Classic (BR/EDR) suits streaming audio; BLE (4.0+) targets low-power periodic data. BLE GATT structure: Service → Characteristic → Value/Descriptor.

BLE roles: broadcaster, observer, peripheral, central. Advertising interval and connection interval directly set latency and power consumption.

RFID bands: LF 125/134 kHz (short range), HF 13.56 MHz (NFC, ~10 cm), UHF 860–960 MHz (passive tags up to several meters). Passive tags harvest energy from the reader field.

Anti-collision: RFID uses slotted ALOHA or binary-tree schemes; ZigBee CSMA/CA with optional GTS for deterministic slots.

NB-IoT occupies 180 kHz (1 PRB); deployment modes: stand-alone, in-band LTE, guard-band. Uplink 3.75/15 kHz subcarrier spacing, single-tone and multi-tone.

NB-IoT peak rates roughly 250 kbps downlink / 250 kbps uplink (multi-tone); coverage gain ~20 dB over GSM; supports PSM and eDRX for battery life up to ~10 years.

NB-IoT has no handover and no connected-mode mobility - suited to stationary devices; eMTC (LTE Cat-M1, 1.4 MHz) supports mobility and voice (VoLTE).

LoRa physical layer uses chirp spread spectrum; spreading factors SF7–SF12 trade data rate for range. SF increases → longer airtime, lower rate, better sensitivity.

LoRaWAN classes: A (uplink-triggered receive windows), B (beacon-scheduled receive slots), C (continuously listening). Class A is the lowest power.

LoRaWAN device classes and ADR: adaptive data rate adjusts SF and transmit power under network control; confirmed vs unconfirmed messages affect capacity.

Link budget rule: every 6 dB gain doubles range in free space (20 dB/decade path loss exponent 2); SF increase of 1 roughly adds ~2.5 dB sensitivity.

Technology choice: NB-IoT for licensed-spectrum, high-reliability, moderate-rate metering; LoRa for private networks and low-cost unlicensed deployments.

OceanConnect/IoTDA onboarding flow: create product (with profile/model) → define service capabilities and properties/commands → register device → device authenticates and reports.

Product model defines serviceId, properties (read/write), commands with parameters, and enum ranges; it enables platform-side payload parsing and app-side abstraction.

Device authentication: deviceId + secret or X.509 certificate; the platform issues an access token after authentication; bootstrap services provision credentials at scale.

Device shadow / twin stores last reported state and desired state, letting apps read state without waking sleeping devices.

Firmware Over the Air (FOTA) and Software Over the Air (SOTA): the platform manages version campaigns, chunked download, and integrity verification.

Rule engine / subscription: apps subscribe to device data change, device online/offline, and command-response events; data can be forwarded to OBS, MQS/Kafka, or functions.

Device lifecycle states: register → online → offline → deregister; abnormal states include authentication failure, subscription failure, and message congestion.

Huawei LiteOS is a lightweight real-time OS for IoT terminals; components include task scheduling, memory management, IPC, and the sensor/network abstraction frameworks.

LiteOS kernel features: preemptive multitasking, priority-based scheduling, dynamic and static memory pools, and a configurable footprint (KB-scale).

LiteOS supports multiple connectivity stacks (NB-IoT, Wi-Fi, BLE, Ethernet) and provides the AgentTiny/OC-MQTT adaptation layer for OceanConnect.

Edge computing (e.g. Edge Computing/IEF) runs containers or functions near devices to filter data, run local inference, and enforce local control loops.

Edge–cloud split rule: sub-100 ms control and bandwidth reduction → edge; cross-site analytics, model training, and long-term storage → cloud.

Edge nodes must handle intermittent connectivity: local persistence, store-and-forward, and eventual synchronization with conflict resolution.

OTA at the edge updates application containers independently of device firmware; rollback must be supported to avoid bricking edge nodes.

CIA triad applied to IoT: confidentiality (encryption), integrity (MAC/signature), availability (anti-DoS, rate limiting).

Transport security: DTLS for CoAP/UDP, TLS for MQTT/TCP, HTTPS for REST; mutual authentication uses client certificates.

Key hierarchy: device unique key → session key derivation; hardware root of trust (TPM/secure element) protects the device key from extraction.

Common attacks: replay, man-in-the-middle, firmware tampering, side-channel, and botnet recruitment (e.g. default-credential scanning on Telnet/SSH ports).

Mitigations: disable default accounts, rotate credentials, sign firmware images, verify boot chain (secure boot), and apply least-privilege access tokens.

Data privacy: minimize collected PII, encrypt at rest, and enforce retention policies; GDPR-style rules require purpose limitation and the right to erasure.

Network segmentation: isolate IoT VLANs from IT networks; gateways should only allow necessary egress to platform endpoints.

Smart metering: NB-IoT or PLC uplink, daily/hourly reads, low bandwidth, high device density, 10-year battery target - prioritize coverage and PSM/eDRX tuning.

Smart home: Wi-Fi for high-bandwidth devices (cameras), ZigBee/BLE for sensors and locks; local hub provides automation when the WAN is down.

Smart agriculture: LoRa or NB-IoT for soil/temperature sensors over wide areas; solar power and deep sleep dominate the power budget.

Industrial IoT: deterministic low-latency loops at the edge, OPC-UA/Modbus southbound, MQTT northbound; prioritize reliability and time synchronization.

Solution sizing: estimate devices × messages/day × payload bytes = daily volume; then size broker connections, storage, and platform message quotas.

Design checklist: coverage survey → power budget → protocol selection → security model → platform model definition → OTA and operations plan.