Iot Network Edge Engineer

IoT Network & Edge Engineer

When to Use

• Design device connectivity—MQTT, CoAP, HTTP/REST device APIs; QoS, retain, and session semantics
• Plan LPWAN and mesh—LoRaWAN, Zigbee, Z-Wave, BLE transport roles and gateway backhaul
• Architect edge gateways and protocol bridges—northbound cloud, southbound field protocols
• Define MQTT topics, ACLs, and broker scale—namespace design, shared subscriptions, clustering
• Implement device identity, provisioning, and PKI—bootstrap, cert rotation, revocation
• Design OTA update architecture—staged rollouts, bandwidth-aware delivery, rollback at edge
• Engineer offline tolerance—store-and-forward, edge buffering, sync after reconnect
• Trade off bandwidth, latency, and battery—payload sizing, sleep schedules, edge aggregation
• Integrate cloud IoT platforms—AWS IoT Core, Azure IoT Hub, GCP IoT concepts; shadows and rules
• Deploy edge analytics and rules—Greengrass, IoT Edge modules, K3s edge workloads
• Segment IoT networks—dedicated VLANs/VRFs, zero-trust device access, broker isolation
• Operate fleet observability—metrics, last-will, desired/reported state, fleet health dashboards

When NOT to Use

• Enterprise Wi-Fi WLAN design, RF surveys, and 802.11 roaming (unless Wi-Fi is only one IoT transport) → wireless-wifi-mobility-specialist
• OT/ICS plant networks, Purdue model, and industrial control security → scada-ics-cyber-security-specialist
• Embedded firmware without connectivity, RTOS drivers, or bare-metal timing → embedded-real-time-software-engineer
• Carrier BGP/MPLS backbone, IX peering, and internet routing → network-backbone-architect
• SD-WAN overlay policy and branch breakout as primary deliverable → sd-wan-engineer
• Cloud landing zone, VPC foundation, and account guardrails → cloud-architect
• Implement cloud networking and managed services without IoT device plane → cloud-engineer
• Cloud security program, CSPM, and corporate IdP as primary deliverable → cloud-security-engineer
• Internal developer platform, golden paths, and portal roadmap → platform-engineer
• Geospatial pipelines, map matching, and fleet location APIs without connectivity layer → geospatial-telematics-developer
• ML training, feature stores, and model serving for telemetry analytics → data-scientist / ml-ops-engineer

Related skills

Core Workflows

1. Scope and boundaries

Clarify device classes, transports, scale targets, and compliance constraints.

See `references/iot_network_edge_scope.md`.

2. Connectivity and LPWAN

Select protocols, radio roles, and payload contracts per device class.

See `references/connectivity_protocols_and_lpwans.md`.

3. Edge gateways and bridges

Place gateways, map protocol translation, and define backhaul resilience.

See `references/edge_gateways_and_protocol_bridges.md`.

4. Identity, provisioning, and OTA

Bootstrap trust, rotate credentials, and stage firmware delivery safely.

See `references/device_identity_provisioning_ota.md`.

5. MQTT topics, brokers, and scale

Design namespaces, ACLs, HA brokers, and fleet-scale connection patterns.

See `references/mqtt_topics_brokers_and_scale.md`.

6. Cloud integration, operations, and security

Wire cloud IoT services, observability, segmentation, and runbooks.

See `references/cloud_integration_operations_security.md`.

Outputs

• Connectivity architecture — transports per tier, protocol matrix, QoS and retry policy
• Gateway and bridge spec — southbound/northbound maps, buffering, and failover behavior
• Topic and ACL catalog — hierarchy, shared subs, retained message policy, tenant isolation
• Provisioning and PKI runbook — bootstrap flows, cert templates, rotation and revocation
• OTA rollout plan — channels, rings, bandwidth budgets, rollback and attestation hooks
• Edge deployment model — modules/containers, offline sync, and cloud command path
• Fleet observability pack — metrics, shadows/state, alerts, and last-will semantics
• Segmentation diagram — VLANs/VRFs, firewall zones, broker tenancy, and zero-trust device access

Reference files

Cloud integration, operations, and security

Table of contents

1. Cloud IoT platform map 2. Device registry and shadows 3. Rules, jobs, and edge runtimes 4. Integration patterns 5. Network segmentation 6. Zero-trust device access 7. Fleet observability 8. Runbooks

Cloud IoT platform map

Handoff: Landing zone, VPC, and private endpoints → cloud-architect / cloud-engineer. Device-plane policy → this skill.

Device registry and shadows

Design rules:

• Keep shadow small (<4–8 KB); large configs in object storage with URL in shadow.
• Split telemetry (high rate) from shadow (low rate state).
• Use named shadows only when product domains are truly independent.

Rules, jobs, and edge runtimes

Cloud rules

• Route telemetry to time-series DB, data lake, and alerting with filtering at ingress.
• Avoid complex business logic in rules—push to stream processors for maintainability.

Jobs (OTA, reboot, cert rotate)

• Target thing groups with rollout configuration.
• Report job progress on dedicated topics; surface failures per device.

Edge runtimes

Offline: Edge rules continue; queue upstream sync; document conflict resolution when cloud desired changes during outage.

Integration patterns

Devices → Gateway/Bridge → MQTT Broker → Cloud IoT → Rules → Stream/TSDB
                              ↓
                         Edge runtime (filter/ML/actuate)

Coordinate downstream analytics with data-scientist / warehouse teams—define schema registry at MQTT boundary.

Network segmentation

IoT segmentation checklist:

• [ ] Dedicated VLAN/VRF per site or per tenant
• [ ] East-west denied except required gateway paths
• [ ] DNS filtering on gateway egress
• [ ] No flat /16 with cameras and PLCs shared

For plant floors, align with scada-ics-cyber-security-specialist before opening paths.

Zero-trust device access

Broker hardening: Disable anonymous; disable $SYS for non-admins; TLS 1.2+; cipher suites reviewed annually.

Engage cloud-security-engineer for org-wide KMS, SIEM forwarding, and detective controls.

Fleet observability

SLO examples:

• 99% devices report telemetry within 2× expected interval
• Command delivery P95 < 30s for online devices
• OTA success > 98% per ring before promotion

Runbooks

Maintain connection simulator in CI that mirrors production keepalive and payload sizes.

Cross-link: MQTT specifics in mqtt_topics_brokers_and_scale.md; provisioning in device_identity_provisioning_ota.md.

Connectivity protocols and LPWANs

Table of contents

1. Protocol selection 2. MQTT essentials 3. CoAP and HTTP device APIs 4. LoRaWAN 5. Mesh and short-range radios 6. Payload and quality contracts 7. Tradeoffs

Protocol selection

Default pattern: MQTT from device or gateway to cloud broker; CoAP on constrained UDP links; HTTP for provisioning portals, OTA manifests, and occasional configuration.

MQTT essentials

Session hygiene: One logical client id per device; reject duplicate connects; document reconnect backoff (exponential cap).

CoAP and HTTP device APIs

CoAP

• Use CON/NON appropriately; confirmable for commands, non-confirmable for high-rate telemetry when loss is acceptable.
• Observe for server-push analog to MQTT subscriptions—watch resource expiry and renewal.
• DTLS mandatory on untrusted networks; pin certs or use EST-like bootstrap aligned with provisioning skill.

HTTP/REST device APIs

• Idempotent PUT/PATCH for desired configuration; ETags for conflict detection.
• Short-lived tokens (OAuth client credentials or device certs) rather than long-lived API keys in firmware.
• Prefer async command pattern: POST /commands → 202 + command id → device polls or uses separate notify channel.

LoRaWAN

Architecture notes:

• Treat LoRaWAN as high-latency, low-bitrate—aggregate at gateway/application server before cloud burst.
• Plan for partial uplinks and duplicate frames; idempotent ingest keys (devEUI, fCnt, port).
• Backhaul from gateway is often Ethernet/LTE/Wi-Fi—coordinate with wireless-wifi-mobility-specialist when Wi-Fi is backhaul.

Mesh and short-range radios

Do not design full mesh RF plans here when WLAN/OT specialists own the physical layer—define integration contracts (pairing, trust center, channel plans) and northbound topic mapping.

Payload and quality contracts

Standardize envelopes across transports:

{
  "deviceId": "string",
  "ts": "ISO-8601 or unix_ms",
  "seq": 12345,
  "schema": "telemetry.v2",
  "data": { },
  "meta": { "rssi": -90, "fw": "1.2.3" }
}

Tradeoffs

When users ask for maximum devices per dollar, optimize payload size and connection schedule before broker SKU upgrades.

Device identity, provisioning, and OTA

Table of contents

1. Identity model 2. Provisioning flows 3. Certificate lifecycle 4. Secrets and key storage 5. OTA architecture 6. Rollout and rollback 7. Compliance hooks

Identity model

Principle: Separate immutable hardware identity from rotatable operational credentials.

Provisioning flows

Factory provisioning

• Inject initial trust anchor or factory cert in secure element.
• Record device in manufacturing DB; export allow-list to cloud registry.
• Seal debug interfaces per product policy.

Field bootstrap (claim)

Zero-touch / bulk

• EST (RFC 7030) or vendor equivalent from gateway.
• CSV allow-list imports for pilots—automate before production scale.

Wi-Fi onboarding: BLE SoftAP or DPP may involve phone apps—coordinate UX with mobile teams; network skill owns resulting MQTT credentials.

Certificate lifecycle

AWS IoT Core: Register CA, use JITR/JITP templates, attach policies per thing group.

Azure IoT Hub: DPS enrollment groups (symmetric key for dev only), X.509 attestation for production.

Secrets and key storage

Never embed long-lived cloud API keys in firmware. Prefer per-device certs or STS-style short tokens brokered by gateway.

Coordinate with embedded-real-time-software-engineer for where keys live in MCU memory and boot chain.

OTA architecture

[Build pipeline] → [Signed artifact in object store]
        ↓
[Cloud job / IoT Jobs] → [MQTT command or HTTPS manifest URL]
        ↓
[Device or gateway agent] → verify signature → staged slot → reboot

Edge-assisted OTA: Gateway caches firmware for bandwidth-constrained southbound devices (LoRa, serial).

Rollout and rollback

Rollback triggers:

• Boot loop detection (failed boots counter)
• Connectivity loss threshold post-update
• Safety interlock trips (plant devices—engage OT)

Mechanisms: A/B partitions, signed previous version retained, cloud command to pin version.

Compliance hooks

• Maintain SBOM per firmware line; map CVE response to OTA rings.
• Audit log: who approved ring promotion, artifact hash, device list.
• Data residency: OTA blobs and job APIs in correct region.
• For regulated environments, dual control on production ring promotion.

When legal/compliance owns policy interpretation, implement technical controls only and document evidence artifacts.

Edge gateways and protocol bridges

Table of contents

1. Gateway roles 2. Placement and sizing 3. Protocol bridges 4. Store-and-forward 5. Multi-tenant and isolation 6. Resilience patterns 7. Operations checklist

Gateway roles

Separation of concerns:

• Radio/PHY — often vendor or WLAN/OT specialist input.
• Bridge/translate — map addresses, scales, and alarms to canonical topics.
• Edge compute — filtering, aggregation, OTA proxy, local actuation with safety interlocks.

Placement and sizing

Sizing heuristics:

• Reserve 2–5× headroom on connection and msg/s peaks for firmware bugs and burst alarms.
• Disk buffer: avg_bytes_per_msg × msg_rate × max_outage_hours × safety_factor.
• Co-locate gateway one routing hop from southbound segments when latency-sensitive.

Protocol bridges

Common southbound → northbound maps:

Bridge design rules:

1. Single source of truth for tag/register → topic mapping (versioned YAML/JSON). 2. Normalize timestamps at bridge ingress (gateway UTC + optional device offset). 3. Alarm vs telemetry separate topics or severity fields—avoid mixing on same QoS0 firehose. 4. Command path authenticated and auditable; reject unsigned writes in plant contexts. 5. Backpressure — when northbound down, shed lowest-priority telemetry first.

Store-and-forward

Anti-patterns:

• Unbounded RAM queues — OOM during multi-hour outage.
• Publishing entire history at QoS2 — broker meltdown on reconnect storm.
• No timestamp of record — analytics cannot reconstruct event order.

Multi-tenant and isolation

Enforce:

• Separate client certs or username/password per tenant on northbound.
• Filesystem and container namespaces for bridge configs.
• Rate limits per tenant at gateway export.

Resilience patterns

Document fail static vs fail safe for command paths with OT stakeholders.

Operations checklist

• [ ] Bridge mapping versioned in Git; CI validates topic collisions
• [ ] Gateway clock synced (NTP/PTP); drift alerts
• [ ] Disk and queue depth metrics with paging thresholds
• [ ] Canary site before fleet config push
• [ ] Runbook for broker cert rotation without mass disconnect
• [ ] Integration test: southbound simulator + northbound mock broker

IoT network and edge scope

Table of contents

1. Purpose 2. Terminology 3. In scope 4. Out of scope 5. Roles and RACI 6. Handoffs

Purpose

Define boundaries for designing and operating IoT connectivity and edge compute layers—from field devices and gateways through brokers, edge runtimes, and cloud IoT control planes.

This skill covers architecture, protocols, provisioning, scale, and operations—not enterprise WLAN RF design, OT plant control security, or pure firmware development without a network story.

Terminology

In scope

Out of scope

Roles and RACI

Handoffs

MQTT topics, brokers, and scale

Table of contents

1. Topic namespace design 2. ACLs and authorization 3. Broker topology 4. Scale patterns 5. Performance and tuning 6. Failure modes 7. Observability

Topic namespace design

Recommended hierarchy:

{tenant}/{env}/{site}/{deviceId}/{stream}/{name}

Rules:

• Avoid high-cardinality dynamic segments in shared subscriptions consumers cannot filter.
• Use single-level wildcards (+) in ACLs; limit # to admin tooling.
• Document retained topic allow-list (e.g. .../config/desired only).
• Command topics: .../command/{action} with response on .../command/{action}/response.

Anti-patterns

ACLs and authorization

Implementation:

• Prefer certificate CN/SAN → ACL template mapping.
• Use role templates per thing group (AWS policy; Azure hub routes).
• Deny by default; explicit allow per topic subtree.

Broker topology

Managed options: AWS IoT Core (MQTT endpoint), Azure IoT Hub MQTT, GCP (historical patterns via partners). Self-hosted: EMQX, Mosquitto cluster (limited), HiveMQ.

Scale patterns

Sharding dimensions:

• By tenant (SaaS)
• By region (data residency)
• By device class (telemetry rate profiles)

Document maximum connections per node from vendor benchmarks with your payload profile.

Performance and tuning

Payload efficiency: Move to CBOR/Protobuf at scale; keep JSON for debug tenants.

Failure modes

Observability

Tracing: Correlate deviceId, clientId, and cloud messageId where available.

Pair with cloud IoT metrics (see cloud_integration_operations_security.md) for end-to-end SLOs.