Wi‑Fi Provisioning Methods and Principles for IoT Devices

In recent years the IoT market has become highly competitive. By 2020 the number of connected devices worldwide is expected to reach 26 billion, with a CAGR of 20 %. The data generated by these devices will amount to 44 ZB, 22 times the 2012 level, with a CAGR of 48 %.

The IoT system is typically divided into three layers: the perception layer (sensors and gateways), the network layer (data transmission), and the application layer (data processing and user interaction). The perception layer handles data acquisition from the physical world and includes technologies such as RFID, various sensors, cameras, GPS, and low‑power short‑range communication. The network layer provides both wired (WAN, fieldbus) and wireless (Wi‑Fi, LoRa, NB‑IoT, 5G, etc.) transmission, and must meet higher QoS requirements due to massive data volumes. The application layer consists of middleware, management platforms, storage, analytics, and security components.

IoT communication protocols are split into two categories: access protocols (used within a subnet, not part of the TCP/IP suite) and transport protocols (standard TCP/IP‑based protocols). Access protocols such as Wi‑Fi, RFID, NFC, ZigBee, Bluetooth, LoRa, NB‑IoT, GSM, GPRS, Ethernet, RS232/485, USB enable low‑power, low‑cost networking inside a local subnet. Transport protocols such as HTTP, CoAP, MQTT, XMPP, AMQP, JMS operate over the Internet and provide end‑to‑end data exchange.

Common IoT access protocols include:

Wi‑Fi

RFID

NFC

ZigBee

Bluetooth

LoRa

NB‑IoT

GSM / GPRS / 3‑5G

Ethernet

RS232 / RS485 / USB

These protocols differ mainly in transmission range, required gateway, and OSI layer placement (access protocols sit in the physical/data‑link layer, transport protocols in the application layer).

Typical IoT provisioning ("配网") involves providing an SSID and password to a Wi‑Fi module so that it can join a target network. Because many Wi‑Fi modules lack rich UI, various provisioning methods have been developed.

3.1 Direct Provisioning

SSID and password are sent to the module via host interfaces such as UART (AT commands), SPI, SDIO, or I²C. The module then connects to the AP and reports the result back to the host. This method is simple but requires an additional physical interface.

3.2 WPS Provisioning

WPS (Wi‑Fi Protected Setup) simplifies Wi‑Fi security configuration via PIN or push‑button (PBC) modes. Although convenient, it is increasingly disabled on routers due to security concerns.

3.3 WEB Provisioning

A Wi‑Fi module that supports AP mode hosts a lightweight web server. Users connect their phone/computer to the module’s AP, open the web page, and configure the target SSID/password. This method works on any device with a browser.

3.4 SoftAP Provisioning

The module starts in AP mode, runs a TCP server, and waits for a mobile device to connect. The mobile app sends the SSID/password over TCP, after which the module switches to station mode and joins the target network.

3.5 Smart Provisioning (SmartConfig / SmartConnection)

SSID and password are encoded into Wi‑Fi MAC‑layer frames (often using UDP broadcast or multicast) and sent from a smartphone. The IoT device listens in promiscuous mode, extracts the encoded data, and connects to the target AP. Various chip vendors use different encoding schemes (e.g., TI‑CC3200 SmartConfig, Qualcomm SmartConnection, MTK SmartConnection, Espressif SmartConfig, WeChat Airkiss).

Vendor

Chip

Technology

Packet Method

TI

CC3200

SmartConfig

UDP broadcast to fixed IP

Qualcomm

QCA4004/QCA4002

SmartConnection

Multicast address encoding

MTK

MTK7681

SmartConnection

Multicast address encoding

Marvell

MC200+8801/MW300

EasyConnect

Multicast address encoding

Reltek

AMEBA

SimpleConfig

Multicast address encoding

Espressif

ESP8266

SmartConfig

Multicast with length encoding

WeChat

Multiple

Airkiss

Full‑network broadcast with length encoding

3.6 Sound‑Wave Provisioning

SSID and password are converted into PCM audio signals (e.g., 700 Hz → ‘a’, 800 Hz → ‘b’) and played by the phone. The IoT device records the sound, decodes the frequencies back to the original string, and uses it to join the Wi‑Fi network. This method works for devices with a microphone but is sensitive to ambient noise.

Comparison of Provisioning Methods

Method

Advantages

Limitations

Direct

Simple, high success rate

Requires extra physical interface (UART/SPI)

WPS

Reduces configuration steps

Security concerns; many routers disable it

SoftAP

Stable, no extra hardware

Needs phone involvement, slightly complex

WEB

Works with any Wi‑Fi + browser device

Requires module to host a web server

Smart Config

No extra UI, uses existing MCU resources

Requires a companion app, lower reliability

Sound‑Wave

Fast, audible feedback

Costly, environment‑dependent

Wi‑Fi remains the most suitable technology for IoT connectivity, acting as the “glue” that binds devices together. The choice of provisioning method should be based on product requirements, cost, user experience, and environmental constraints.