Tests show the different sides of Sidewalk

This article originally appeared in the October'24 magazine issue of Electronic Specifier Design – see ES's Magazine Archives for more featured publications.

With Amazon Sidewalk, a common Cloud-communication layer sits on top of a network layer that works with up to three different RF physical layers (PHYs) supported by bridge devices, such as the Echo smart speaker or Ring video doorbell. IoT devices compatible with Sidewalk include smart appliances, consumer devices and wearables, as well as sensor nodes used by utilities and other organisations for campus and building management.

As the Sidewalk-compatible network grows, so do the useful applications. IoT devices are not constrained to interact with just the owner’s gateways but any of those subscribed to the network. Owners of these devices can opt-in to share a small portion of their Internet bandwidth, which the bridge uses to deliver wireless connectivity services to Sidewalk IoT devices. This mode of operation has massive utility for devices such as pet trackers. No matter how far a cat wanders, there is a strong probability a Sidewalk-enabled tracker in its collar will come into the range of a gateway somewhere in the neighbourhood.

Another key element of Sidewalk’s geographic coverage lies in its use of three complementary RF protocols that cover different geographical requirements to connect to the wider Internet through compatible gateways. For localised and higher-data rate coverage, Sidewalk uses Bluetooth Low Energy (BLE).

The second option is one that relies on sub-gigahertz frequency shift keying (FSK) as its PHY. This is the same approach as that taken by proprietary wireless systems that include applications as varied as wireless doorbells and sensors used to monitor railway equipment and pipelines. Tests in an urban environment have shown this PHY can achieve a range of approximately 160m. As a protocol that supports data rates up to 50kbit/s, FSK lends itself to applications such as level sensors for outdoor pools or garden lighting.

The third extends the potential range even further from a host gateway. Based on a chirp spread spectrum (CSS) PHY, a single gateway in an urban environment can communicate with devices up to a kilometre away. This extends the capabilities of Sidewalk into sectors such as commercial agriculture: Based on sensor data, farmers can derive better estimates for the optimal amounts of irrigation, fertilisers and pesticides for their crops.

Device manufacturers have a free choice which PHYs they include in their design. Each of the protocols has its own energy usage and latency profile that will influence other design decisions, such as battery capacity. There are also options for communications that help extend battery lifetime for highly constrained devices. For example, BLE is optimised for situations where devices are typically used indoors. It is highly flexible in how it can be configured in terms of power and latency.

A common technique used to manage communications lies in the use of timed window. For example, a gateway may broadcast initiator messages to establish communication and then waits for a negotiated period for any replies. Typically, with protocols such as BLE and FSK-based Sidewalk, a timeout period determines whether the gateway will keep the connection alive or treat the device as having left the area or shut down for a long period.

Remaining connected by sending acknowledgement packets, even if they contain no application data, will typically reduce response times, especially for messages sent from the cloud. If the devices allow a connection to time out, the client device will need to re-establish the connection when it has data to send or needs to provide a response. The result is higher response latency. However, by letting devices disconnect for longer periods, they can preserve battery life, which can be a major advantage if periods of minutes or more can be left between sensor updates.

CSS works in a subtly different way to FSK. The core protocol is fundamentally asynchronous, which means a device by default does not maintain a persistent logical connection with the gateway. However, Sidewalk implements a mode that resembles the persistent-connection behaviour of FSK. The standard power profile opens a limited number of listening windows, every five seconds, when the device initiates communication. Once the last window has passed, the gateway sends no further messages until the device connects again, at which point it needs to re-synchronise to the gateway’s transmission cycle. A second Sidewalk mode uses keepalive packets to maintain a constant chain of listening windows where the device has no data to send. This second mode allows for faster communication with the cloud where there are long gaps between messages. But this comes at the cost of higher energy consumption.

These modes imply different levels of device reachability. If the application calls for devices to be contacted quickly from the cloud, energy consumption will be higher. This type of operation relies on the device’s core processor and RF subsystem waking up at regular intervals to confirm it is still present on the network, even if it does not have any data to send. If the device can sleep for long periods, perhaps measured in minutes before attempting to contact a gateway that is in range, energy consumption can easily be much lower. However, with the Sidewalk modes, re-establishing contact will take longer and increase communications latency.

To explore how the different Sidewalk RF modes perform, Silicon Labs performed extensive tests to gauge the impact on energy consumption, latency and effective communications range.

In each case, the experiment involved the device sending 19-byte packets, analogous to sensor readings, in a relatively simple ping-pong transaction with servers in the cloud. This design helped ensure the energy results would be dominated by local RF consumption. To ensure an accurate assessment of range, Silicon Labs engineers conducted the tests in an urban environment with only one long-range FSK or CSS gateway in use at a time. To make sure results were not outliers when testing latency, the experiments averaged across sessions that involved the exchange of at least 500 messages.

Figure 1. Experiment involved sending 19-byte packets, analogous to sensor reading

Silicon Labs’ experiments showed that the longer range enabled by CSS leads to higher average power consumption. That consumption naturally increases with transmission frequency. Experiments showed the current draw reaches a minimum of around 200µA. FSK reduced the average current demand to just 44µA on the test hardware. BLE lay in the middle at around 100µA.

Where reachability is less important and the device can disconnect from the network after each message exchange, average current can fall to just 1µA, assuming highly irregular contact from the device to the gateway. In these measurements, the experiments had the device go into a deep sleep mode several minutes after transmission.

Round-trip latency to and from the Cloud can vary widely. If low latency is an essential part of the application, BLE provides the best performance. In the tests, it averaged to a little under half a second. The use of timing windows by the other two protocols generally leads to higher average latency when messages need to be sent from the Cloud to a device. Round-trip response latency is on the order of five seconds in the case of CSS and eight seconds for FSK. Potentially, round-trip time can be on the order of 20 seconds if it takes a long time to find an appropriate listening window. However, it is important to bear in mind that uplink messages from device to the cloud experience far lower latencies on average. And Sidewalk was optimised for applications where uplink messages dominate.

Figure 2. Network Latency Results on three PHYs available in Sidewalk

The experiments found FSK provides the most balanced mix of energy demand, latency and range. However, CSS remains the favoured option where applications need long-range access from the nearest gateway, such as in rural environments. A pet tracker could rely on FSK for long battery life and low weight. But CSS A may prove to be a better option for tracking livestock on a farm. Similarly, an agricultural irrigation system would probably benefit from using CSS, possibly combined with FSK to maximise coverage, whereas a garden sprinkler could use FSK on its own for its high-power efficiency.

Figure 3. Power Consumption Results on three PHYs available in Sidewalk without reachability

Figure 4. Power Consumption Results on three PHYs available in Sidewalk with reachability

This research demonstrates the usefulness of Amazon Sidewalk in its various modes of operation. The results of such tests also underpin the importance of working with IoT technology suppliers who have taken the time to understand the ramifications of these different modes and who are ready to help at every step of development, integration and early deployment.