Network and architectures for smart parking

The main communication protocols used by our sensors and possible applications in a smart parking project

The LoRa (Long Range) protocol is an “expanded spectrum” modulation technique purchased by Semtech (USA) in 2012.



Features

The LoRa protocol uses the so-called free-use frequencies, called ISM (Industrial, Scientific, Medical), reserved mainly for industrial, medical and scientific use, but which are employed by all radio devices on the market that can be purchased and used freely, such as gate remote controls, Wi-Fi devices, radio alarms, etc.

Operators using these devices are not subject to authorizations or the payment of fees. In every country it is possible to find some public operators and dozens or hundreds of private companies that “sell” the connection for the devices.



Speed

The data transmission speed is called Spreading Factor (SF). The range of SFs used goes from SF12, the slowest, which allows communication of about 250 bps (bits per second), up to SF7, the fastest, with about 11,000 bps.

Therefore, if a smart parking sensor has to send its free/busy status packet and this is composed, for example, of 60 bytes (1 byte = 8 bits), it means that the total length of the packet to be sent (called Payload) is 480 bits. At SF12 are needed at least 1.92 s (480 bits/250 bps = 1.92 s), on the other hand about 44 ms is enough for SF7 (480 bits/11,000 bps = 0.044 s approximately).



Battery

The battery consumption at SF7 is considerably lower compared to an SF12 but the slower the SF, the more it can penetrate obstacles and communicate long distance. Imagine yourself in a crowded square, at 20 meters from a person that can take 20 seconds or 200 seconds to communicate with you. If he wants to communicate clearly and at a greater distance it can take longer and it is necessary that he speaks very loudly, getting tired first (the equivalent of the battery that is consumed faster), or he can get closer and therefore speak faster and at a lower volume (equivalent to using more gateways).

This is the reason why Intercomp always tries to use the SF7 in its installations: it is better to have few more gateways than having to replace the sensor batteries every 2 years instead of every 8/10 years.

The Intercomp sensor is compatible and certified by the LoRa Alliance™ with the EU863-870 channel plan and base transmission and reception frequency at 868 MHz. It can be used throughout Europe, the Middle East and in some African countries.



Configuration

Three different configurations are available for our devices.

LoRaWAN®

It is built according to the specifications of the LoRa Alliance™, which includes devices, gateways, a network server and a management platform (for example our POLIS). Gateway and network server are the devices that the public or private LoRaWAN® operator must make available. The problem of saturation arises for very large numbers of sensors but generally the manufacturers of gateways and network servers declare the possibility of connecting several thousands of devices (even up to 20,000), even though much depends on the traffic generated.

LoRaWAN® SPN (Small Private Network)

LoRaWAN® SPN is a variation to the LoRaWAN® which uses gateways with an integrated network server with reduced features, compared to a real network server. Each SPN gateway allows to manage a few hundred devices. It is useful to create private LoRaWAN® networks very quickly, saving the cost of a network server (a few tens of thousands of euros).

LoRa Intercomp

It is a proprietary LoRa protocol developed by Intercomp that exploits the penetration and distance potential typical of the LoRa protocol but uses only one channel for communication and the data rate (the communication speed) is normally fixed on SF7.

The components of this architecture are the LoRa Intercomp sensors, the R3000 Intercomp gateways (that can be powered in high or low voltage) and the POLIS management platform.

Each gateway can manage up to 150/200 sensors. Beyond this number, the gateway can work, but two factors may arise which must be taken into consideration:

type of connected devices, that are not all the same. For example, a smart parking sensor can transmit over 50 messages per day, so the radio traffic generated on free and busy events, can be very high;
Duty Cycle, the transmission time which must not exceed 1% calculated on an hourly basis (not more than 36 seconds in an hour). This is not a problem for a sensor, but for a gateway, if it is configured to respond to connected devices and if these are thousands, it could become a problem. The Confirmed Packet for LoRaWAN® networks or the Acknowledge (ACK) for LoRa Intercomp network (the confirmation that the sensor packet has been delivered) is a configurable option on LoRaWAN® gateways and set as standard on the LoRa Intercomp network. So, if a gateway has to confirm the reception to a large number of sensors, it is possible that the limit of the Duty Cycle is reached and from that moment the gateway will no longer be able to respond to the devices, unless you break the law. In a smart parking system, especially if payments are also managed (as occurs in the Intercomp system), the confirmation of receipt of the packets is a very important information. But as battery life is equally important, in the LoRa Intercomp protocol the sensors can be configured to stop communication after 6 attempts, if the ACK is not received by the gateway.

NB-IoT (Narrow Band – Internet of Things) technology uses frequencies and LTE (Long Term Evolution) band devices.



Features

The frequencies dedicated to NB-IoT (the so-called 4G in use by telephone operators) are not for public use, but an operator must purchase licenses from the various countries where it wants to work in order to use those frequencies, which generally cost several hundreds or thousands millions of euros or dollars (for example, in Italy, auctions for the use of frequencies reserved for 5G were awarded for 6.55 billion euros). In each country there are generally from 2 to 4 operators capable to offer the connection.

NB-IoT operates in the same way as telephone data communications, but unlike the phones (to which it is necessary to recharge the battery practically every day) for devices such as our sensor, operators must apply a particular configuration which guarantees the sensor a lot of autonomy about when to close the communication and remain in stand-by.

NB-IoT network, unlike LoRa, can control the connected devices, awake them and make them remain online for the desired time. However, it is possible for operators to adopt a configuration to allow NB-IoT devices some freedom to close connections once the packet has been transmitted.



Efficiency

The communication speed is not significant for consumption while network configuration and transmission power are very relevant.

With NB-IoT there are no bandwidth occupation limits and therefore a device can remain in transmission for an unlimited period. Obviously if the device is battery powered and an underground installation is chosen (as for Intercomp sensors), the less time and power the device uses to communicate, the longer the battery lasts.

The frequencies employed by NB-IoT are called bands and are wider than LoRa. The B20 (800 MHz) and the B8 (900 MHz) are present in 67.8% of the market worldwide. Indeed, for the same power, they guarantee good penetration and communication distance (the higher the frequency, the more it is filtered by walls and other obstacles).



Configuration

With NB-IoT networks there are not many architecture variables: the only possible variable is the operator (and therefore the SIM) to be used. In the case of a sensor, communication with the telephone cell is direct after configuration of the network parameters.

The device configuration is established by the settings of the parameters of the telephone operator (PLMN and APN). The standard configuration parameters communicated by the manufacturers of the NB-IoT radio modules are instead introduced in the device firmware.

Regarding the problem of saturation, operators guarantee tens thousands of devices that can be connected to the same cell.

Conclusions

In smart parking projects all architectures can be used, evaluating the strengths and weaknesses of each. Regarding LoRaWAN®, even if manufacturers declare thousands of manageable devices, it always depends on the quantity of packets that the devices send. In the case of smart parking sensors, it is preferable not to exceed the number of a few hundred per gateway, not to overload the network and to be able to use the Confirmed Packet.

The exact sizing calculations of a LoRaWAN® network can be performed using specific software which are able to calculate, based on the area to be covered, the number of devices, the daily or hourly quantity of packets to be received and the desired signal quality, position and number of gateways required.

Below is a comparison between networks and architectures for smart parking.