Why SigFox is Not a Good Option for Connected Street-Lighting

Connectivity is what makes connected street lighting smart. Connected streetlights can receive data from and send data to a central management system (CMS), typically in the cloud. By doing this, streetlights and/or cabinets can be monitored and controlled remotely. A street-lighting operator can create dimming schedules or generate overrides when needed and track operational data, such as asset information for maintenance, energy usage, and lamp burn hours.

A web-based street-lighting CMS (when deployed in the cloud) provides computing, storage, security, connectivity, and a graphical user interface. Therefore, the lighting operator is freed of any operational IT complexity and costs for maintaining such IT equipment.

In this context, the word “connectivity” becomes an important aspect. Although most of the connected street-lighting systems in the market work similarly, there are many different connectivity models of exchanging data between the streetlights and the CMS.

A low-power wide-area network (LPWAN) is a wireless telecommunication wide area network designed to allow long-range communications at low bit rates among various connected devices, such as luminaire controllers or sensors. Such implementations are commonly referred to as the Internet of Things (IoT); consequently, LPWAN technologies are used for making streetlights “smart”.

SigFox

SigFox was the first narrowband LPWAN (like NB-IoT) protocol proposed in the IoT market (developed in 2010 in France by https://www.sigfox.com/en). SigFox is a proprietary (closed) protocol that uses unlicensed bands for IoT connectivity.

SigFox is a patented and therefore proprietary technology. While SigFox hardware (HW) is open, the network is not and follows a subscriber business model (recurring fee). Customers must subscribe to it (like cellular carriers).

Sigfox recurring fees are based on the number of devices on a customer network subscription, the traffic profile per device, and the contract duration.

Earlier versions of SigFox were unidirectional because it was intended as a pure sensor network (only uplink). However, later versions support uplink (~100 bps) and downlink (~600 bps), although the system is optimised for uplink communications.

The payload size is 12 bytes for each uplink message and 8 bytes for the downlink, narrowing its utility a bit for connected street lighting. But IoT devices like alarms, simple power metres, environmental sensors, and devices sending small and infrequent bursts of data can be better candidates for this protocol.

SigFox protocol stack

The SigFox protocol stack is similar to other protocol stacks following the OSI (open systems interconnection) model:

Since SigFox is a proprietary protocol, minor comments can be made on security aspects. There is conflicting information in the literature. Certain sources indicate that messages are not encrypted anywhere in the SigFox protocol stack. However, the SigFox white paper states that it supports OPTIONAL AES-128 encryption based on a device key. It is up to the customer to provide an encryption scheme.

💡 Security is another important aspect to consider in public lighting, not addressed in detail in the SigFox protocol.

SigFox network architecture

SigFox is based on a star network topology since one IoT end device can be associated with more than one SigFox base station. The SigFox end-to-end high-level architecture is as follows:

The IoT end devices send their messages over the air (SigFox physical layer) to the closest SigFox base station, responsible for receiving the message and backhauling it to the SigFox Cloud support system over the public internet. The backhaul uses a virtual private network (VPN) tunneling based on digital subscriber line (DSL) connectivity and long-term evolution (LTE) as a backup. In addition, when one of the two is not available, satellite connectivity can be used as an alternative.

By default, SigFox base stations do not acknowledge message receipts and compensate for reduced reliability with time and frequency diversity schemes. In addition, a base station cannot send a message to an end device at any time.

If multiple base stations are in the range of an end device, all can receive and process the messages from it; all subsequent messages will be sent to the SigFox support system backend, and duplicates will be removed.

The SigFox support system is hosted in a cloud environment consisting of individual services that process most network functionalities. Back-end servers communicate directly with each base station over the backhaul network. These are responsible for monitoring and managing the base stations and processing incoming messages.

If multiple base stations receive a message, the back-end servers determine which copy to keep. This method of processing messages adds redundancy to the received data.

💡 When considering scaling your solutions, coverage and roaming is another key aspect of SigFox’s failure compared with other LPWAN technologies.

The network infrastructure also stores all messages retrieved from end devices in one database, and a second database stores the metadata from each device to allow customers to build services.

The front-end servers communicate with the storage’s metadata database, presenting a web interface for subscribers to manage devices and configure user or group permissions. The cloud service web interface and API (application programming interface) for subscribers allow for data retrieval and integration with third-party platforms (applications).

SigFox physical layer

The SigFox physical layer handles the modulation scheme and the medium access control (the bit rate and transmission power control and the radio resource occupation). The SigFox physical layer employs Ultra Narrow Band (UNB) wireless modulation. Narrowband signals occupy a tiny portion of the spectrum and require less transmission power for a given application than wideband signals.

Therefore, narrowband signals can carry less information than wideband signals, which need more transmission power. Narrowband signals are the preferred solution for applications that require the transmission of limited information.

SigFox bandwidth is very narrow, and therefore latency is low.

💡So, it is not suited for triggering manual overrides or third-party systems via APIs (street lighting). In addition, there is a need for daily reporting of switch points, energy consumption, faults and events, calendar updates, and future data uploads from connected sensors in street lighting control systems.

SigFox transmits over unlicensed ISM (industrial, scientific, and medical) bands using sub-GHz radio frequencies. Different regulatory bodies, like the European Telecommunications Standards Institute (ETSI) and the United States Federal Communications Commission (FCC), work to prevent interference and congestion on unlicensed spectra by imposing certain restrictions. Those restrictions are related to transmission power and duty cycle. The SigFox frequency bands per region are as follows, and the bit rate depends on the bandwidth for each:

• 863–870 MHz in Europe, regulated by ETSI 300–200 regulations
• 902–928 MHz in the Americas and Oceania, regulated by FCC part 15 regulations.

In Japan, the regulatory Association of Radio Industries and Businesses (ARIB) imposes strict spectral density limitations, making ultra-narrowband UNB challenging to deploy.

UNB employs an ultra-narrow spectrum channel (<1 kHz) to establish an ultra-long-distance link between transmitter and receiver. SigFox uses very narrow bandwidths, which are different for the uplink and the downlink channels:

The uplink ↗️ channel bandwidth is 100 Hz in the ETSI area, and 600 Hz is allowed in FCC regions. These bandwidths allow a data rate of 100 bps and 600 bps in ETSI and FCC regions, respectively. The modulation scheme for the uplink communication is DBPSK (Differential Binary Phase Shift Keying). In Europe, the uplink frequency maximum power is limited to 25 mW.

The ETSI limits the maximum duty cycle to a maximum mean transmission time of 1% to fairly share the spectrum usage between all users of this and other similar communication systems.

A 1% hourly duty cycle constraint applies to devices in Europe, resulting in a maximum of 6 messages per hour or 144 messages per day. Notice that the number of messages allowed depends on the selected subscription plan.

Downlink ↘️ communication is even more restrictive than uplink communication; data from the base stations to the end devices can only occur following an uplink communication. The downlink channel bandwidth is 600 Hz, and the modulation format used is GFSK (Gaussian Frequency Shift Keying).

Notice that the duty cycle for a base station is 10%, which guarantees only four downlink messages per device per day.

💡SigFox has notable data size limitations, limiting certain features needed for a street lighting management system. For instance, SigFox is not suited for firmware updates over the air, which is needed in long-term contracts for street lighting since firmware updates are needed to upgrade features and security upgrades incrementally.

SigFox MAC layer

Sigfox MAC layer relies on a legacy Aloha protocol-based medium access technique called Random Frequency and Time Division Multiple Access (RFTDMA).

It allows active nodes random access in time and frequency to the wireless medium without any collision-control method. To overcome this, the MAC layer header adds an ID field for IoT for each end device and base station for identification (unique SigFox ID) and error-detecting codes.

The transmission mode is fire and forget; the receiver does not acknowledge messages. Instead, a message is sent three times (time diversity) on three different frequencies (frequency diversity) to ensure its transmission.

💡 Since SigFox is designed for infrequent small data uploads over the air, it is not suited as a connectivity model for street lighting control and management.

SigFox frame layer

The frame layer aims to generate the radio frame from the application data (application layer) and deliver it to the MAC layer. The frame layer attaches a sequence number to the generated frames, allowing the MAC layer to identify and order the radio frames.

Main considerations for connected street lighting

In the IoT world, there are certain aspects to consider regarding the specific application at hand. The connectivity model does not determine the whole solution, are the features of the end-to-end solution. So if you are considering an LPWAN solution technology for your application, make sure that your choice provides the right performance.

SigFox can be a good connectivity model for other IoT applications but is not the ideal solution for connected street lighting.