Files
banban/docs/architecture/02-device-bootstrap.md
T

3.6 KiB

Device Bootstrap And Binding Receipt

Purpose

The device-level bootstrap/binding handshake maps a factory IMEI to Banban's internal device_id and serial_number. Its successful msg_id=012 response is the device binding success receipt and includes the associated ICCID for downstream SIM/traffic binding. Devices do not need to know those IDs before the first handshake.

Flow

sequenceDiagram
  autonumber
  participant Factory as Factory Excel / import CSV
  participant Mapping as device_imei_mapping
  participant Device as TalkingQ device
  participant MQTT as MQTT broker
  participant Handler as TalkingQMQTTService
  participant Init as device_identity_initializer
  participant Auth as device_auth

  Factory->>Mapping: Insert imei, device_id, serial_number, status=pending
  Device->>MQTT: Publish device/{imei}/event msg_id=012 binding request
  MQTT->>Handler: Deliver identity init event
  Handler->>Init: initialize_by_imei(imei)
  Init->>Mapping: SELECT mapping by imei
  alt mapping missing or incomplete
    Init-->>Handler: DeviceIdentityInitializationError
    Handler-->>MQTT: device/{imei}/event_resp status=failed
  else mapping found
    Init->>Auth: SELECT device_auth by device_id
    alt no auth row
      Init->>Auth: INSERT device_id, serial_number, is_active=1
    else auth row exists and serial matches
      Init->>Auth: UPDATE is_active=1
    else serial mismatch
      Init-->>Handler: device_auth serial_number conflict
      Handler-->>MQTT: device/{imei}/event_resp status=failed
    end
    Init->>Mapping: UPDATE status=activated, activated_at=now
    Handler-->>MQTT: device/{imei}/event_resp binding success receipt
    MQTT-->>Device: Receive device_id, device_sn, and iccid
  end

Binding Success Receipt

When the IMEI mapping and its authoritative ICCID association are available, the handler returns the device binding success receipt on msg_id=012:

{
  "msg_id": "012",
  "params": {
    "device_id": "TalkingQ_ZHWK00002110",
    "device_sn": "TQ_ZHWK000000002110",
    "iccid": "898604E91123D1334901"
  }
}

The iccid value is the canonical, full ICCID used by the downstream SIM and traffic service. It must come from an authoritative IMEI-to-ICCID provisioning record or a validated device report; it must not be derived from the IMEI. Successful device binding requires a non-empty, valid ICCID. If the ICCID cannot be resolved or fails consistency validation, the handler must return the existing msg_id=012 failure response instead of returning a partial success.

Adding params.iccid is an additive response-field change. Devices that ignore unknown JSON fields remain compatible, while strict firmware parsers need a protocol/version capability check before this response is enabled for them.

Data Model

erDiagram
  device_imei_mapping {
    int id PK
    varchar imei UK
    varchar device_id UK
    varchar serial_number
    varchar status
    datetime activated_at
    datetime created_at
    datetime updated_at
  }

  device_auth {
    int id PK
    varchar device_id UK
    varchar serial_number
    varchar batch_id
    tinyint is_active
    datetime created_at
    datetime updated_at
  }

  device_imei_mapping ||--o| device_auth : activates

Current ID Style

device_id:     TalkingQ_ZHWK00002001
serial_number: TQ_ZHWK000000002001

Source Anchors

  • Bootstrap handler: talkingq-url/handlers/mqtt_handler.py
  • Identity initializer: talkingq-url/services/device_identity_initializer.py
  • Import script: talkingq-url/scripts/import_device_imei_mapping.py
  • Tables: database/talkingq_shared_schema.sql