IoT 101
COMP6733 looks like a course for 2nd year engineering students yet I’m doing it in my 4th year as an ‘advanced’ course. Nice. This whole 5 ‘advanced’ courses requirement for my degree is stupid but for this course I won’t complain. From the first impression, this course looks genuinely fun and is worth spending tuition fees for.
Arduino
We are given Nano 33 BLE Sense Rev2 to work with throughout the term. Nice. This thing isn’t that expensive but having mentors supervising us is always nice especially when the device is fragile.
Pins
Pins are the I/O of Arduino devices. They receive and send voltages.
Input pins with nothing connected to the other end are floating (or in high-impedance state). This means their reading is undefined due to noise.
Hence, input pins need to be pulled up or pulled down. It just means setting their idle value as high or low by adding a resistor.
Pins can be digital or analogue, and on my Arduino device they are represented as D2 ~ D12 and A0 ~ A7.
There are other unique pins. For example:
- Serial pins (TX1, RX0): Used to transmit and receive data, one byte at a time. The first letter essentially tells if it’s for
transmitorreceive, but on the board you can distinguish them by the arrow too. - Reset pin (RST): self-explanatory. Pull it to low to trigger reset.
- Power pin (VIN): Receive power from external device to power the arduino or send power to power other devices.
- Ground pin (GND)
In MicroPython, the Pin class can be imported from machine.
from machine import Pin
The class constructor:
machine.Pin(id, mode=-1, pull=-1, *, value=None, drive=0, alt=-1)
where id is either int (internal Pin number), str (Pin name) or tuple of [port, pin].
All other arguments, if not provided, will use information from the previous state.
mode=Pin.IN,Pin.OUT,Pin.ANALOG(for analogue pins)pull=Pin.PULL_UP,Pin.PULL_DOWN
Read or write to a pin using .value:
Pin.value(x?) where if not specified, reads 0 or 1 and if specified and evaluates to bool, outputs 1 on True and 0 otherwise.
Pin.on(), Pin.off() = Pin.high(), Pin.low() = Pin.value(True), Pin.value(False).
Pin.toggle()self-explanatory.
Functions to set pin properties:
Pin.mode(mode?)Pin.pull(pull?)
… etc
Bluetooth Low Energy
Bluetooth Low Energy (BLE) is a Bluetooth protocol introduced in 2010 (Bluetooth 4.0) with the aim of energy efficiency.
The protocol allows for low power consumption and high speed in exchange to low throughput.
Device Modes
Single mode only implements BLE whereas dual mode implements both classical Bluetooth and BLE.
2.4GHz
Bluetooth operates on the frequency of 2.4GHz because it’s free.
Connection Establishment
Advertising State
a device in this state sends out advertising packets at a fixed interval Advertising Interval. They do so in each of the three Primary Advertising Channels:

Each channel is separated by 2MHz. The primary channels are selected to avoid Wi-fi channels, minimising interference.
Generic Attribute Profile (GATT)
GATT is an abstraction of how data is exchanged in BLE.
GATT consists of Services and Characteristics.
Service
Service is uniquely identified by a UUID and contains one or many Characteristics. It’s basically a namespace for characteristics.
UUID is a numeric field that is either 16-bits or 128-bits. 16-bits for official services and 128-bits for custom.
Official UUIDs follow this format: XXX...-0000-1000-8000-00805F9B34FB.
Characteristics
They can send or receive data to/from central device.
GATT Coding
from ubluepy import Service, Characteristic, UUID, Peripheral, constants
# Initialise and advertise bluetooth device
peripheral = Peripheral()
peripheral.advertise(device_name= "str", services= [])
Advertise a bluetooth device without any services
To add a service, define UUID, service, and add it to the peripheral:
uuid = UUID("hex")
service = Service(uuid)
peripheral.advertise(device_name= "str", services= [service])
For custom services UUID must be (with x’s replaced to make it unique): 4A98xxxx-1CC4-E7C1-C757-
F1267DD021E8. I don’t know why it’s defined like that.
IEEE 802.15.4 (Zigbee)
IEEE 802.15.4 is a IEEE standard for low-rate wireless personal area network (WPAN). It is not the same as Zigbee. Zigbee is a protocol that is built upon 802.15.4.

It is similar to BLE in that it aims to provide a low-power and low-speed WPAN, typically covering 10 ~ 20m.
Physical Layer
802.15.4 can operate on one of the three possible frequencies and supports a total of 27 chanenels:
- 868MHz (one channel, 868 ~ 868.6 MHz)
- 915MHz (10 channels, 902 ~ 928 MHz)
- 2.4Ghz (16 channels, 2400 ~ 2480 MHz)

Classes of Devices
802.15.4 defines two classes: Full Function Devices (FFD) and Reduced Function Device (RFD).
RFDs only implement the standards partially. As a result, they can only talk to FFDs (one at a time), acting as leaf nodes in a network topolgy.
FFDs can communicate to other FFDs and RFDs. The biggest difference is that FFDs can act as a PAN coordinator.
PAN coordinators and normal coordinators are different: In a PAN (Personal Area Network), there can only be one PAN coordinator (a.k.a principal controller of PAN). PAN coordinator governs the PAN it belongs in. Their roles include:
- Assigning PAN ID
- Finding network frequency
- Short address assignment to itself
- Whatever a normal coordinator does
On the other hand, a normal coordinator is responsible for intra-PAN communication and join requests from foreign devices.
Network Topology
Start Topology
PAN coordinator as centralised device. Other devices talk to each other through the PAN coordinator. Simple as that.
P2P Topology
Nodes can talk to each other provided that they are within the communication range. Note that RFDs can talk to one FFD at a time, and therefore act as leaf nodes.
Frame Format
Jim Kurose said that studying frame format is like eating veggies. It’s good for you, but it’s the least enjoyable part.
MAC Protocol Data Unit (MPDU)
MAC frame is largely divided into three parts:
- MAC Header (MHR) that includes
frame control,sequence number, andaddress info. - MAC Payload
- MAC Footer (MFR) that contains
frame check sequence.

Frame control is like an enum field defining the message type.

The frame type field can be one of beacon, data, ack, or MAC command.
Notably, the content of MAC Payload differ depending on the frame type. (If it’s ack, payload is empty)
Medium Access Control
802.15.4 can operate in beacon mode or non-beacon mode. In beacon mode, nodes are synchronised.
Non-beacon Mode
It’s unsynchronised and uses CSMA/CA for access control.
Beacon Mode
Access Control
Communication is done in accordance to a superframe published by a PAN coordinator. Superframe is a time period where nodes perform synchronised communication over beacon internal (15ms ~ 245s).
Superframe is further divided into an active and inactive portion, where during the inactive portion the coordinator may sleep.
The active portion is divided into 16 segments and further categorised into a contention free period (CFP) and contention access period (CAP).
Contention Access Period
CAP is the early portion of active duration (It’s not necessarily the early half). During CAP, nodes transmit data using CSMA/CA (is it slotted?).
Contention Free Period
CFP is followed instantly after CAP. During CFP, nodes explicitly ask for permission to transmit, therefore no interference occurs during communication. Timeslot in which a node is permitted to transmit data is called guaranteed time slot (GTS).
Taming the underlying challenges of reliable multihop routing in sensor networks
“This study has shown that link quality estimation and neighborhood management are essential to and tightly coupled with reliable routing in sensor networks”
Hardware
Berkeley Mica mote running on TinyOS.
Link Quality Observation
Experiment is conducted with sensor nodes placed linearly with a spacing of 2 feet. Of those, one is selected as transmitter and tranmits 8 packets per second, 200 packets in total at a given power level.
Loss Rate Over Distance

There is a distance Effective Region within which essentially all nodes suceed communication. This distance increases with transmit power.
There is also a distance Clear Region over which essentially all nodes fail communication.
In between, Transitional Region, nodes exhibit expected behaviour, failing to communicate successfully with increasing distance.
However, individual nodes exhibit high variation, some failing to transmit over relatively close distance and some successfully transmitting over a large distance.
Loss Rate on Immobile Device

A node is configured to transmit 8 packets per second in an indoor setting at a distance of 15 feet for 20 minutes. Then, it is moved closer and remains stationary for the rest.
The mean quality for each distance is stable, but instantaneous quality fluctuates heavily.
Applying these concepts, we expect irregular shape of region in which nodes share similar connectivity:

Link Estimation
Each node assesses the quality of the link by observing packets (success and loss). protocols in the upper layers can use this metric to build routing structure.
An ideal algorithm for link estimation should be simple, stable, memory efficient yet reactive to changes.
link can be assessed passively by snooping (inferred by observing packets in the network) on the channel, since communication is done in a broadcasting manner. The downside is that it can’t distinguish between silent nodes and nodes that fail to transmit every packet.
The nature of low-power communication makes it difficult to choose a good link estimation algorithm; it must be simple as to minimise power consumption.
The authors suggest an algorithm that is based on Exponentially Weighted Moving Average (EWMA), namely Window Mean With Exponentially Weighted Moving Average (WMEWMA) with t and a for adjustable parameters.

Where S_t is the ratio between successful packets to all packets (successful + failed) within a timeframe t.

Neighbourhood Management Policy
With limited neighbourhood table to record adjacent nodes, it is crucial to develop an algorithm that makes best use of this limited space to maintain an efficient neighbourhood set.
Neighbourhood management is essentially comprised of insertion, eviction, and reinforcement.
Metric for Routing
When it comes to wireless transmission, link quality must be taken into account. As such, routing is not as simple as choosing the fewest number of hops to reach the destination. The best-performing metric for routing in the context of wireless transmission prioritises the number of retransmissions, with each link evaluated as the inverse of forward link quality multiplied by the inverse of the backward link quality:
1/fwd * 1/bwd. This is found to be superior than routing metrics that prioritise the shortest path.
6LoWPAN
6LoWPAN is the acronym for IPv6 over Low-Power Personal Area Networks and is a protocol for using IPv6 in low-power networks like IEEE 802.15.4.
IPv6 header is compressed by using information present in t802.15.4 MAC header, and or using information known in the network, such as common prefix.
RPL
RPI is the IP Routing Protocol designed for Low-power and lossy networks.
RPL requires nodes to form Destination Oriented Directed Acyclic Graph (DODAG), which is built with ICMPv6 control messages DIS (DODAG Info Solicitation), DIO (DODAG Info Object), and DAO (Destination Advertisement Object)
the DIO message is broadcast by routers (or root for a single-node graph) of the graph. Any nodes that receive this message can opt-in to participate in the graph, selecting a parent node based on an objective function. Nodes rank themslves when they join so that a node with a higher rank points at a node with a rank one below, thus selecting a parent.
The resulting topology is a tree-like structure with each node pointing up, eventually reaching the root.
This makes it impossible for a downward traversal, from root to leaves. DAO messages are sent by leaf nodes when they first join (or when they are requested by DIO), informing parents about reachability (they call it prefix reachability and I don’t know if there’s a significant difference). This process terminates once the root is aware of the hierarchy. Nodes can relay DAO from children to its parent by aggregating its information in the DAO they send to the parent.
Trickler Time
in RPL, graph-building is considered a persistent issue. As such, coordinators send DIO messages periodically at trickler time to populate the graph. This time increases as the graph becomes stable, reducing the number of DIO messages sent over time, saving energy in turn. Graph is considered stable if there is no inconsistency. Inconsistency is an error or change in the graph, such as loops, or joining or modifying the graph. In the case of inconsistency, trickler time resets to quickly stablise the graph.
Storing, Non-storing mode
Storing mode is the conventional table-driven forwarding method. Each node builds forwarding table with DAO and DIO messages. When a packet needs to be forwarded, nodes look at the table to determine the next hop, sending it up (towards the root) or down (towards the nodes).
In Non-storing node, only the root is responsible for forwarding. Children nodes of the root do not store anything in the forwarding table, minimising memory usage. Root builds downward forwarding table by receiving DAO messages propagating from the leaves to the root. It adds extra message in the packet so that intermediate nodes can forward it to the destination eventually.
There is no blend between storing or non-storing mode; Either they are all storing, or only the root is storing.
LPWAN
Short for Low Power Wide Area Networks. As the name suggests, it provides a wide range of cover in low-power at the cost of low-throughput.
LPWAN itself is not a protocol. It is a categorisation of protocols that specialises in low-power operation and wide-range.
LPWAN typically adopts one of star, star-of-stars, or mesh topology.
For example, LoRaWAN adopts star-of-stars topology where end-devices are connected to gateways, which then are connected to the servers via IP.
LPWAN maintains low-powered network by severely imposing bandwidth and duty cycle restrictions. Duty cycle is the percentage of a device’s transmission time compared to when it is idle in a specific time-frame (usually a day). Duty cycle in unlicensed frequencies is regulated to ensure fair usage of shared frequencies.
LoRaWAN
LoRaWAN is a LPWAN protocol developed by LoRa Alliance. Devices in LoRaWAN are classified as A, B, or C.
All devices are, by default, class A. They can optionally choose to implement features in B or C (not both). Any devices implementing features other than A are called higher Class end-devices.
Class A: Bi-directional end-devices
Devices in class A can communicate in bi-direction by first carrying out an uplink transmission and then waiting for any down-link transmission (two short windows for this). It is therefore the most power-efficient.
Downlink transmission cannot happen randomly; It only happens following an uplink transmission from device to server.
Class B: … with scheduled receive slots
In addition to class A features, class B devices listen for downstream communication at scheduled times. To do so, they receive time synchronisation beacon from the gateway.
Class C: … with maximal receive slots
They receive downlink transmission almost continuously, only closing when transmitting. Obviously spends more power but offers far less latency.
End-Device Activation
Over the Air Activation (OTAA) is a secure way to join a network by exchanging security data between devices and the network.
Each device needs to configure AppEUI, DevEUI, and AppKey (AES-128), and store them.
Both EUIs are public whereas the Appkey should not be exposed.
Upon joining a network, both the network and the device generates AppSKey and NwkSKey that each uses to encrypt, decrypt, and verify messages.
A device in the network is assigned DevAddr to uniquely identify it in the network.
Activation by Personalisation skips the join process entirely and manually generates NwkSKey, AppSKey, and DevAddr (and forwards them to the network).
CoAP
CoAP stands for Constrained Application Protocol and as the name suggests, it is an application layer protocol.
Unlike HTTP, it operates on top of UDP. This decision choice is to enable web transfer protocol under battery and resource constrained environments.
CoAP defines CON and NON messages.
CON messages are confirmable, meaning that receiver needs to acknowledge the message, with either ACK for positive and RST for negative acknowledgement.
CON messages are retransmitted until response arrives.
Acknowledgement for NON messages is optional.
CoAP supports GET, POST, PUT, and DELETE methods.
MQTT
MQTT stands for Message Queueing Telemetry Transport. Unlike the name suggests, there is no message queueing mechanism.
MQTT is to publish/subscribe sensor data using TCP/IP protocol. It is a lot similar to ROS.
Subscriber can subscribe to more than one topic by using wildcard + (one level) or # (all level)