HCIP-IoT common mistakes

Before answering any technology-selection item, write down four axes: mobility (stationary vs. moving), data rate, latency tolerance, and whether voice or handover is needed. Then map NB-IoT to stationary/low-rate/delay-tolerant, eMTC to moderate rate plus mobility and voice-capable use, and LoRa to private, self-built, low-cost wide-area networks. Practise with 10 scenario stems and justify each rejection, not just the choice.

Draw the pipeline once from memory: define product and model attributes and services, upload/deploy the codec plug-in, register the device to obtain credentials, bind the device, then subscribe to data and issue commands. For each step, note what exists before it and what fails if it is skipped. Answer lifecycle questions by locating the named artefact in that pipeline.

Build a table with columns: role, can it route, must it be mains-powered, does it hold the network together, which address is used for what. Add the rule that the 64-bit address is the permanent identity and the 16-bit address is local and may change after rejoin. Then answer topology and addressing questions by reading off the table.

Use a four-layer map: device identity (unique per-device credentials, secure storage, no shared keys), transport (DTLS/TLS, certificate validation, no fallback to plaintext), platform access (per-device authorization, least-privilege application tokens), and lifecycle (secure boot, signed OTA updates, key rotation and revocation). For each practice threat, name the layer and the control before choosing an answer.

Describe the gateway with four verbs: terminate (short-range radio), translate (to the northbound protocol), buffer (store-and-forward during outages), and decide (local rules/edge analytics). For every design scenario, state which of the four is being exercised. This also clarifies the boundary between gateway and platform responsibilities.

Anchor three facts: LiteOS is an ultra-lightweight kernel aimed at constrained MCU-class devices with a sensor abstraction and connectivity components; edge computing places processing near the data source to cut latency and bandwidth; and edge and cloud are complementary, with the cloud handling aggregation, model training, and long-term storage. Re-read your notes and mark every place you substituted a general-purpose assumption.

Make a comparison grid for passive, semi-passive, and active tags across: power source, who initiates transmission, typical range, cost, and lifetime. Add the reader/antenna dependence for passive tags. Answer by locating the scenario's range and maintenance constraints in the grid.

Contrast the two explicitly: Classic for continuous higher-throughput links such as audio; BLE for intermittent small-payload transfers with long sleep periods. Learn the BLE sequence advertising, scan, connect, discover services via GATT, then exchange data, and note that longer connection intervals and smaller payloads reduce energy. Use this to answer power and topology items.

Adopt a fixed design checklist: endpoints and density, payload size and reporting interval, resulting daily uplink volume per device and in aggregate, power budget and expected battery life, coverage and mobility, then security and management. Do a rough calculation for every design stem before writing the architecture, and state the assumption behind each number.

Redraw the model from memory with a concrete example at each layer, then annotate two arrows: telemetry flowing upward and commands/configuration flowing downward. Practise by taking any component name and stating its layer, its neighbour above and below, and one interface it exposes. Repeat until this is automatic.