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 ( ) is a wireless telecommunication wide area network designed to allow long-range communications at low bit rates among various connected devices, such as . Such implementations are commonly referred to as the Internet of Things (IoT); consequently, LPWAN technologies are used for making streetlights “smart”. LPWAN luminaire controllers or sensors SigFox SigFox was the first narrowband LPWAN (like NB-IoT) protocol proposed in the IoT market (developed in in France by . SigFox is a proprietary (closed) protocol that uses unlicensed bands for IoT connectivity. 2010 https://www.sigfox.com/en) 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 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. Since SigFox is a proprietary protocol, minor comments can be made on security aspects. 💡 not addressed in detail in the SigFox protocol. Security is another important aspect to consider in public lighting, SigFox network architecture SigFox is based on a 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: star network topology The 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. IoT end devices By default, 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. SigFox base stations 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 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. SigFox support system is hosted in a cloud environment 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 wireless modulation. Narrowband signals occupy a tiny portion of the spectrum and require less transmission power for a given application than wideband signals. employs Ultra Narrow Band (UNB) 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. Different regulatory bodies, like the (ETSI) and the United States (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: SigFox transmits over unlicensed ISM (industrial, scientific, and medical) bands using sub-GHz radio frequencies. European Telecommunications Standards Institute Federal Communications Commission 863–870 MHz regulated by ETSI 300–200 regulations in Europe, 902–928 MHz regulated by FCC part 15 regulations. in the Americas and Oceania, 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 ↗️ 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 (Differential Binary Phase Shift Keying). In Europe, the uplink frequency maximum power is limited to 25 mW. uplink DBPSK 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. ↘️ 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 ( ). Downlink communication is even more restrictive than uplink communication; 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. 💡 certain features needed for a street lighting management system. For instance , which is needed in long-term contracts for street lighting since firmware updates are needed to upgrade features and security upgrades incrementally. SigFox has notable data size limitations, limiting , SigFox is not suited for firmware updates over the air SigFox MAC layer Sigfox MAC layer relies on a legacy -based medium access technique called (RFTDMA). Aloha protocol Random Frequency and Time Division Multiple Access 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 ; 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. fire and forget 💡 Since it is not suited as a connectivity model for street lighting control and management. SigFox is designed for infrequent small data uploads over the air, SigFox frame layer The 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. frame layer 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.

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

Too Long; Didn't Read

Companies Mentioned

Coin Mentioned

@marisamartinez

RELATED STORIES