Smart Water Metering & LoRaWAN
What is LoRaWAN?
LoRaWAN is a wireless technology enabling the connectivity of a wide range of sensors, meters, and other devices that make up the Internet of Things (IoT). It enables the wireless connectivity of devices where there is a need to send relatively small amounts of data over distances up to 10 or more kilometres while consuming very little power. This includes devices such as GPS trackers, parking sensors, street lights, water meters, and many more. LoRaWAN fits into the rapidly growing category of technologies known as Low Power Wide Area Networks (LPWAN).
The name LoRaWAN comes from Long Range Wide Area Network. It was first released as a version 1.0 specification in 2015. LoRaWAN continues to be developed and promoted by the LoRa Alliance which is a global non-profit group of over 500 organisations including Bosch, Cisco, IBM, and Orange.
As LoRaWAN is an open framework on which solutions can be built. There are many providers of the components and end-to-end solutions, and it is possible for anyone to build their own LoRaWAN devices, gateways, and networks. This is a key differentiator when comparing LoRaWAN to other technologies for smart water metering. It also means that there are various business models which can be used to offer solutions including low cost annual connectivity fees per device, through to completely free to use public networks.
Smart water metering solutions have a few basic requirements and then more advanced features. LoRaWAN is a highly capable and flexible wireless solution capable of handling the basic requirements for secure wireless delivery of water meter data and also addresses many of the more complex technical and commercial challenges faced in the industry.
How does it work?
Smart water metering solutions utilising LoRaWAN are comprised of metering devices, gateways, network servers, application servers, software, and people.
There are a wide range of LoRaWAN devices available now and more being released around the world on an almost daily basis. Most of these devices are for commercial or industrial applications and tend to look like plain beige plastic boxes with an external sensor of some sort.
LoRaWAN Devices on Display at TTN Event
LoRaWAN Transmitter Connected to Water Meter
Gateways are the radio transceivers which are the link between the wireless devices in the physical world and the server infrastructure which manages the data of those devices.
LoRaWAN gateways are typically similar in size to Wi-Fi modems and have antennas <1 metre in length to communicate with the LoRaWAN devices. They also have interfaces such as Ethernet and 3G/4G for communicating to the internet. Gateway antennas are typically mounted on top of buildings or masts to ensure they achieve the best range possible.
There are many vendors of gateways such as Multitech, Cisco, and Kerlink. Most gateways are compatible with most network servers and require varying degrees of configuration to achieve interoperability.
Various LoRaWAN Gateways
A key part of the LoRaWAN technology stack is the network server. These are servers which receive data from gateways and pass this data through to the application servers which require that data to enable visualisation, analytics, and other software applications. They also provide device management tools such as device registration, device status, and provisions for downlink messages for configuration changes and firmware updates.
There are a range of network servers available and it is possible for anyone to build their own. Of those available, some popular options are Actility, The Things Network, and Loriot. It is also possible for anyone to create their own unique LoRaWAN network server, however the time and resources required to achieve a fully functioning server should not be underestimated. The vast majority of LoRaWAN projects and solutions utilise existing network servers, almost always from only a few of the largest vendors.
System Architecture Overview
Devices and gateways send LoRaWAN messages between each other using LoRa wireless communications. The gateways and the network servers send LoRaWAN messages between each other using common TCP/IP methods. The network servers communicate with the application servers using common IoT protocols such as MQTT. The application servers then provide visualisation and data analytics software to people such as operators, analysts, and end-customers to gain insights into network operations and water use. These insights drive actions towards efficiency improvements such as understanding the effects of population growth on a water supply network, identifying leaks, or how much water is used to top up a home swimming pool.
Difference between LoRa and LoRaWAN
Put simply, LoRa is the technology for the physical wireless communications between the device and the gateway while LoRaWAN is the protocol by which data is composed to be sent from the transmitter, such as a digital water meter, and read by the receiver, such as a LoRaWAN network server.
All LoRaWAN devices and solutions use LoRa, however, a device can use LoRa technology but not also use the LoRaWAN standards for the data it sends and receives. When exploring these technologies, it is important to understand the differences between LoRa and LoRaWAN.
LoRa is the standard of the physical layer which defines the way by which messages are sent over the air between devices and gateways. You can think of this in the same way that Wi-Fi is the standard your phone and laptop use to connect to the internet in your home through your Wi-Fi gateway.
LoRa was originally developed by Cycleo, inspired by military radio technologies, and first patented in 2008. It was then acquired by Semtech, a Californian chip manufacturer, in 2012. Semtech owns the intellectual property of LoRa and receives revenue from sales of LoRa radio chips and in this sense, there is a proprietary aspect to LoRa and therefor LoRaWAN solutions. While this may be a contentious issue for some, it is important to keep in perspective that Semtech receives a very small portion of revenue from LoRaWAN solutions. For example, in a $100,000 smart water metering project, it’s likely that <1% of that sum would go to Semtech through the sale of the chips inside the meters and gateways which are generally only a few dollars each. Semtech manufacture these LoRa chips in-house and have also licenced the technology to other manufacturers such as STMicro since 2015.
Example of LoRaWAN Modulation Profile (Image Credit: Link-labs.com)
LoRaWAN offers bi-directional communication so that messages can be sent both as an uplink from a device to a gateway to a server, and also as a downlink from a server to a gateway to a device.
In smart water metering, devices are generally configured with their required functionality determined prior to deployment. In some cases however, it is useful to be able to modify the functionality of the device, such as meter reading intervals, later on without having to physically travel to the device to reconfigure or update it. This is why downlink ability is useful for the on-going operation of smart water metering devices.
Another benefit of bi-directional communications is the ability to have messages from devices acknowledged by the server. This enables the device to ‘know’ if a message was received or not. If a message is received, the device can power down the radio until it is needed again, or if the message is not received, the device can retransmit the message until it is received and acknowledged.
Bi-directional communications also enables firmware over the air (FOTA) where new software with new features and bug fixes can be sent to the device over the air via downlink. In practicality this functionality is challenging to implement due to the low data packet sizes, especially in lower coverage areas. Depending on the firmware structure, it may be possible to make only minor updates to specific components of firmware or could require multiple FOTA packets to be sent which may start to impact the total time that the battery will last.
Over land transmissions in excess of 200kms are often reported, with what might be the current world record standing at 446kms achieved by a device transmitting from the Manchester area in the UK to Netherlands.
There have been other long distance records achieved with transmitters attached to weather balloons to achieve greater range and line of sight. A distance of 702.7 kilometres was achieved from a transmitter attached to a weather balloon at 38.7 kilometres altitude by The Things Network in August 2017.
Records aside, messages are commonly being sent and received successfully by gateways from devices between 2 and 10 kilometres apart in urban areas and even further in rural areas. The actual range that can be achieved in any given location is dependent on geography, positioning, and other factors such as interference and noise on the spectrum.
Through use of relatively low frequencies, high link budget, and low path loss, LoRaWAN is well suited to transmitting messages through obstructions such as concrete walls and metal pit lids. This makes it excellent for smart water metering where meters are often located in challenging locations such as underground car parks, basements, and underground pits.
It’s common for LoRaWAN water metering systems to achieve link margins in the realm of -150dBm which is a similar performance level to other common LPWANs. These figures are superior to 3G and 4G which consume significantly more energy to deliver the same relatively small data packets. To put these figures into a real world example, if a LoRaWAN device and gateway were compared side by side with a equivalent 3G/4G device and gateway, the LoRaWAN device-to-gateway link would be able to successfully transmit through one or two more brick or concrete walls than the 3G/4G system. This is of high importance for smart water metering applications where meters are often in basements and pits and can’t easily be moved to different locations.
Despite this strong performance out-of-the-box, it is common for meters in metal pits and basements to require additional work to achieve reliable connectivity. This can be addressed with the use of external antennas which are connected to the device by a cable and mounted away from the obstruction.
Spreading Factor and Adaptive Data Rate
As many remote sensors and almost all water meters are deployed in fixed locations, it is critical that wireless networks can not only reach far and obscured locations, but also can adapt to suit changing surrounding environments such as parked vehicles or growing trees appearing between devices and gateways. LoRaWAN has two key features that address these challenges. These are Adaptive Data Rate (ADR) and adaptive Spreading Factors (SF). This allows devices to manually or autonomously change wireless communication parameters to suit a changing environment.
You can think of this as being similar to when you are talking to a friend in a loud room full of people. When you’re right next to each other it’s easy to speak to and hear one another. When you are further apart, it becomes harder to communicate over the distance and the noise of the other people in the room.
One way to make it easier to communicate with your friend is simply to speak louder. The issue with this is that then everyone else around you also starts speaking louder and then at some point it becomes tiring and impractical to communicate inside the room. Speaking louder is similar to increasing the transmit power of a radio device. By increasing the output power of a radio it becomes easier to successfully deliver messages, but not necessarily if there are many other devices trying to communicate in the same space. Regulatory bodies place limits on maximum transmit power of wireless devices to manage this issue. Increasing transmit power also increases energy consumption and therefor battery depletion, much like how speaking louder tires your vocal chords and eventually you need to stop.
An effective way to communicate with your friend across a noisy room is to say your words more slowly and clearly. This is exactly what LoRaWAN devices do to communicate with gateways by changing their spreading factor. When the spreading factor increases, each bit is transmit more slowly and clearly.
When transmitting data at slower rate, less data can be sent in a single transmission. This is called decreasing the data rate. Much like the conversation in the loud room, this also requires more energy than talking at a normal pace, but not necessarily as much energy as much as having to shout.
When LoRaWAN devices are further from a gateway, they can increase their spreading factor and therefor also decrease their data rate. They can do this autonomously using a feature called Adaptive Data Rate (ADR). The lowest spreading factor (SF7) uses the highest data rate (DR5) and the highest spreading factor (SF12) uses the lowest data rate (DR0).
LoRaWAN Spreading Factor and Data-rate Overview (Image Credit: Prof. Antonio Grilo, Tecnico Lisboa)
By using adaptive data rate, LoRaWAN devices and gateways are able to increase the success rate of transmissions being received over the air.
LoRaWAN is designed specifically for applications where only small volumes of data are required to be sent, with lower energy consumption, and also where long range is required. To this extent LoRaWAN is not intended to compete with cellular technologies such as 3G and 4G which are intended for high data volume applications.
In low link quality scenarios where a LoRaWAN device is operating on SF12 and DR0, a maximum of 59 bytes can be sent in a single uplink packet. These 59 bytes typically include general device data such as battery voltage and any sensor data such as meter readings. In total, a typical LoRaWAN device can send up to around 10 meter reading related values in a single transmission, depending on how the data is encoded and what other data is being sent such as device identifiers, battery voltage, and additional sensor values, etc.
At SF7 and DR5, a maximum of 230 bytes can be sent in a single transmission. Relevant to digital water metering, devices will most often not operate at SF7 due the distances between water meters and gateways and the fact that many meters are installed below ground or indoors where there are many obstructions to the signal path. Keep in mind too that the larger the data packet, the higher the chance of packet loss.
It is worth noting at this point that LoRa is a physical wireless communication type and is not an internet or application protocol. Due to the low power and simple nature of LoRa, it is not suitable for direct internet communications, for example an IPv6 message requires a 40 byte packet header and a 128 byte address. These are simply too large to be used efficiently with most LPWAN solutions. Instead, the LoRaWAN protocol is employed for delivering messages between devices and the wider internet via a network server.
Device Battery Life
As with all smart water metering systems, battery life is dependent on the functionality of the device. For example, if a device needs to report meter readings every 5 minutes, it will consume more energy than a device that reports readings only hourly or daily.
With LoRaWAN and many other wireless technologies, energy consumption is effected by signal quality. The lower the signal quality, the harder the device must work to deliver its’ message to the receiver. The main reason the energy consumption increases is that the devices radio must be powered and operating for longer to transmit the message i.e. the data rate. For LoRaWAN, this is directly related to the spreading factor.
The below graph shows an example of calculated battery life by spreading factor for a LoRaWAN device with a modest battery capacity. It includes separate lines for three different configurations; transmit one water use value once every half-hour, transmit once every hour, and transmit once every 3 hours.
There is a significant decline in battery life depending on what spreading factor is used, as well as a decline when the device must transmit more frequently. Both of these phenomena are dependent on the amount of time that the radio is transmitting and consuming energy.
Note that battery life is capped at a maximum of 15 years as the single-use Lithium LiSOCl2 batteries used in many metering and IoT devices have a shelf life which is essentially an upper limit of how long the battery can be expected to last regardless of the energy consumption of the device. Keep in mind that battery life is also dependent on the operating environment where extreme temperatures can lead to increased degradation of the cells.
LoRaWAN requires a relatively low amount of power to propagate (turn on) the radio module so the power budget, i.e. how much battery capacity is required, is more related to the volume of data transmitted rather than the quantity of separate transmissions. Other wireless technologies for example have higher energy consumption requirements to make each transmission yet are less affected by the volume of data sent.
Smart water metering systems using LoRaWAN can be tuned to prioritise either battery or reliability of successful transmissions. For example, if a use case required a 7 year battery life and receiving only 1 reading a day was essential while hourly readings only considered as optional or nice to have, then the device could transmit hourly but be locked to use only SF7 through to SF10. This configuration may lead to some acceptable level of data loss if signal quality was low, but would still achieve the required 7 year battery life. As long as at least 1 out of the 24 transmissions sent each day is received, then the system fulfils its’ requirements. These parameters can be tuned to suit specific use cases and are best developed upon through testing and on-going analysis.
Many smart metering projects expect 10 year battery life to be similar to the life of a mechanical water meter and to keep site visits to a minimum. This is certainly achievable with LoRaWAN however you may need to select a device with a larger battery to improve longevity in low coverage scenarios.
Reliability of Data Delivery While LoRaWAN is designed with high reliability in mind and is generally on par with similar or competing LPWAN technologies however it must be acknowledged that it is not perfect and some degree of data loss will occur. Aside from improper set-up and operation, most data loss occurs as a result of the changing environment affecting the wireless link between devices and gateways, interference from other wireless devices, or congestion on the LoRaWAN network. These issues are often referred to as packet loss where all or part of a transmitted payload is not successfully received.
Many of the above issues can be resolved by deploying additional gateways to enhance the network and wireless coverage, however this is not always practical or cost effective. A lower cost solution to greatly reduce packet loss for digital metering is to add redundancy into each packet. For example, a metering device delivering hourly water use information without redundancy would send one transmission every hour containing the water use data for that hour only. To add redundancy to this system, the device could send one transmission every hour with that packet containing the water use data of the current hour, plus each of the previous 2 hours for a total of 3 hourly values in one packet. With this redundancy functionality, only 1 out of every 3 packets is required to successfully deliver all hourly water use values. The repeated values can then be merged together by software applications to create one clean and complete dataset.
Network Operators Network operators are organisations that ensure that LoRaWAN networks are deployed, maintained, and provide the level of service required for the users. Being an open framework, LoRaWAN enables operators to choose how they offer the technology. There are many operators and business models available to support smart water metering projects.
Internationally major telcos such as Orange in France and Spark in New Zealand operate LoRaWAN networks in much the same way that they operate cellular networks like 3G and 4G. Users or partners pay connectivity subscription fees, usually on a data volume per year per device basis with significant economies of scale for thousands of devices or more on one account.
In Australia, there are multiple national network operators, each with their own specialisations. For example NNNCo focuses on building a nation-wide network through utility and industrial partners while Meshed focuses on smart cities, education, and open community networks.
Another interesting LoRaWAN network operator from Australia is Fleet. Rather than using Ethernet or 3G/4G for connecting the gateway to the network server, Fleet use a unique satellite network. This enables connectivity anywhere that the gateway can be powered by mains or solar and battery.
Coverage As LoRaWAN networks are operated by many different parties under different arrangements, it is difficult to determine the total number of gateways or area of coverage of the technology in any given region. The network providers typically do not integrate their respective networks with each other and many network providers do not currently offer publically available coverage maps.
As these networks are in their early stages in terms of deployment, it is likely that additional gateways will be required to provide coverage for your region, especially if you are outside of major metropolitan areas. If you are looking to use an existing network, check with the network providers for advice on their current coverage and how to expand coverage in your region.
One network which does publically share coverage information is The Things Network which has just over 270 gateways deployed in Australia as of March 2019, which is around 2.5x more than this time last year. These include professional grade gateways capable of supporting thousands of devices through to hobbyist grade gateways built on top of developer kits such as Raspberry Pi.
TTN Coverage Maps as of March 2019
In other parts of the world such as France and New Zealand, national networks are deployed by more traditional telecommunication providers such as Orange and Spark.
As each well positioned gateway typically provides a 2 to 10km radius of coverage in metro areas, and potentially more in rural areas, LoRaWAN networks can be deployed to cover large areas with relative speed and ease.
In addition to standard gateways, there are also smaller gateways, often referred to as pico-cells. These miniature gateways are intended to enhance coverage in tighter physical areas such as within an apartment building or factory. These pico-cells offer most of the functionality of larger gateways and enable densification of coverage at relatively low cost.
Where no existing coverage is available on any given LoRaWAN network, it is usually easy to establish new gateways to increase coverage. As gateways are physically small, require minimal power and minimal bandwidth, they can readily be installed on rooftops, water towers, or any structure with a view over a wide area.
Regions Unlicensed frequencies are designated by regulatory bodies around the world for free use without the need to pay large fees for licences. LoRaWAN is used on a number of different frequencies around the world to suit the different national regulations covering unlicensed spectrum. In Australia the most common frequency band for LoRaWAN has been AU915 which operates in 915 to 928MHz band.
There is an increasingly popular initiative across the LoRaWAN community for greater adoption of the AS923 band as this frequency is permissible across many countries in Asia such as Indonesia, India, Japan, and more, as well as Australia and New Zealand. This enables cross-sharing of technology and enhances the LoRaWAN ecosystem in these regions. The benefit of uniting multiple regions under a common frequency band is that it reduces the local customisation required for any project and becomes easier to work with and support products that can reach a larger market. This in turn leads to products that scale and mature much faster for an over-all stronger ecosystem.
The regional frequency bands around the world are summarised in the table below.
Security Due to the open standard nature of LoRaWAN, sufficient security is not necessarily guaranteed to come ‘out of the box’. It is therefore important to understand the principals of how LoRaWAN security works.
There are a range of features in the LoRaWAN standard and best practices used by the LoRaWAN community to ensure solutions are appropriately secure. Security is a highly technical topic and to cover it in depth would require a dedicated article so here I will give a high level overview covering the basic principles and features specific to LoRaWAN.
Firstly, devices must securely register to networks in order to start sending data. There are two methods for provisioning (i.e. initially connecting) LoRaWAN devices onto networks. These processes are explained in basic terms as follows:
Over the Air Activation (OTAA): This is the recommended and generally preferred method. Devices and the Network ‘handshake’ over the air to execute the registration, first by the device introducing itself to the network by uplink, and secondly by the network acknowledging and confirming the registration to the device by downlink. Both the device and the network must share the same Application Key (AppKey).
Activation by Personalisation (ABP): Credentials are preloaded into the network server so that when the device is activated, it is already known to the network. This requires more effort to orchestrate as each device needs to be registered by a person before it can start working. The benefit is that the device does not require a downlink message from the network to confirm the registration.
When the device and the network connect to deliver data, this is called a session. Each session contains a Device Address (DevAddr) and two AES-128 encrypted session keys; the Network Session Key (NwkSKey) which is for identification and is known to the network, and the Application Session Key (AppSKey) which is known to the application or the system which is accessing data from the network server and is for payload encryption. There is also a frame counter which identifies each individual message between the device and the network.
The Network Session Key and the Application Session Key are unique to the each session of each device. If using the recommended OTAA method to register devices to the network, the NwkSKey and AppSKey are dynamically regenerated with each new session.
These features can be expanded on in much greater detail to explain the inner workings, but can be summarised at a high level through the following diagram:
Frame Counter The frame counter is a unique sequential number that is contained in every data packet that a device sends. The frame counter increases by 1 with every message: 1, 2, 3, 4, etc. This means that not only does every device have a unique identifier, but also every message that’s sent has a unique identifier. If a packet is ‘sniffed’ (received by an unauthorised party) and then replayed in an attempt to confuse or interfere with the network or device owner, that message could then be rejected by network as it would be out of sequence with the frame counter associated with the original device.
The frame counter can also be useful for determining if messages have been lost over the air. The data from a particular device would have gaps in the frame counter sequence, suggesting data has been lost. This is especially useful for applications where devices transmit upon an unscheduled event occurring e.g. an alert for a water leak, rather than transmitting on a constant time-based schedule.
Like all smart water metering solutions, the cost of LoRaWAN based solutions are heavily dependent on specification and scale and will differ from one project to the next. Therefor to get a clear picture of how LoRaWAN stacks up against other technologies such as Sigfox, NB-IoT, or other water metering communications, we can focusing specifically on the devices, the gateways, and the network operating costs and put aside all costs of planning, project management, installation, implementation, management, user interface software, and data analysis, etc.
At the device level, LoRaWAN radio modules can cost as little as just a few dollars at moderate scale. To achieve a high level of performance, an off-the-shelf antenna is typically used which along with the required supporting components is also only a few dollars. At the sum of materials level, there is usually only around $10 of radio components in a device. LoRaWAN retro-fit smart water metering devices are typically between $600 for advanced units with higher cost sensors at lower quantities to $100 for simple units with lower cost sensors at much higher quantities. This is factoring in the varying pulse sensor, the enclosure, PCB, memory, CPU, cabling, sensors, battery, assembly, and all other components.
Gateways also vary significantly in cost, ranging from <$100 for indoor-grade units to around $5,000 for high-end outdoor rated units. As each gateway will support hundreds of devices, there is typically less of an economy of scale factor in gateway costs. Proper installation of an outdoor gateway may also be up to a few thousand dollars depending on location and secure mounting requirements.
Due to the open nature of LoRaWAN, network operating costs can vary significantly. For example, over the air connectivity and access to data from a network server can be completely free of cost if using a public open network such as The Things Network (TTN). Free solutions typically come with no guarantees of service and support must be self-managed or sourced through the generosity of the LoRaWAN community. This model may be fine for a proof of concept project but does not lend well to critical infrastructure projects or where high reliability is required.
At the more robust end of the service range, fully managed LoRaWAN network services typically have a fee per connected device and often factor in the volume of data being sent. They may also have a fee per gateway for management, as well as general administrative charges. Most costs are charged on a yearly basis, in part to reduce the administrative effort of processing small value invoices monthly or more frequently. For a smart water metering project of around 1,000 devices, expect costs to be in the range of $2 to $20 per unit per year.
On-going operational costs are often bundled in with software applications such as user interfaces, data visualisation, and data analytics. They may also include operation and maintenance services for the whole solution.
What to Watch Out For LoRaWAN has many benefits and advantages due to it being an open standard, however there are a few pitfalls to watch out for.
You Get What You Pay For: LoRaWAN networks can be relatively cheap to build and can be extremely cheap to operate. Keep in mind that low cost gateways and network servers that do not come with any service level agreement are to be used at your own risk. Generally the “free” options should only be used for early stage proof of concept projects. To deploy any respectable digital water metering project, especially if you are a water authority, you will need to engage experts to ensure quality and reliability and should expect to pay for their services accordingly. That said, even commercial LoRaWAN services can still achieve attractive price points.
As a relatively young technology with low cost as a major selling point, there are many low cost devices on the market but few that have been successfully scaled up and refined. Seek mature solutions that have been deployed successfully at scale or at least allow additional time to assess and vet less mature solutions and plan to mitigate risk before deploying in larger scales.
Avoid Vendor Lock-in: The intent of the LoRaWAN standard is to create a frame work on which standardised and interoperable solutions can be built upon. Some device, gateway, and network server suppliers have taken an alternative approach and have made various of what they offer proprietary. Some vendors may alter the way their solutions function in order to achieve slight performance improvements and or simply to make it difficult for users to change vendors in the future. There may (or may not) be a minor benefit to these design changes that deviate from the standards but at the same time you may lose the ability to use alternative standard compliant devices from other vendors. Where there are open standard options available, it is generally best to make use of them to avoid compatibility issues or vendor lock-in.
More Gateways: Deploying more gateways to achieve overlapping or redundant coverage can actually save you a lot of money and hassle in the long run. LoRaWAN device battery life is directly related to the spreading factor and data rate, which are in turn directly related to the quality of wireless coverage. This means that by deploying more gateways to improve the quality of coverage, your devices can operate for much longer periods of time between battery or whole device replacements. Like most wireless networks, LoRaWAN is susceptible to packet loss which can also be reduced by enhancing the quality of coverage.
LoRaWAN is bringing new opportunities for smart water metering by providing an open and flexible framework to support low cost, low power, long range, and long life solutions.
Original article by Rian Sullings www.rian.tv ©