This article is designed to help those embarking on a new business venture or concept using LoRaWAN technology to understand the options and impact of the choice of LoRaWAN network server type.
This article assumes a basic level of knowledge of LoRa and LPWANs and offers the reader clarity on the possible architectures available by virtue of different LoRaWAN Network Server implementations.
LoRaWAN itself defines an end to end data delivery solution as illustrated in Figure 1.1 below.
End devices are predominately various types of sensor that communicate with LoRaWAN gateways using the LoRa physical layer protocol predominately on sub-GHz license-exempt bands such as 868MHz in EU, 915MHz in USA & 470MHz in China.
Figure 1.1 – Classic LoRaWAN solution Architecture
LoRaWAN requires a “LoRaWAN network server” as well as an Application server and this concept can initially cause a little confusion. One of the reasons a network server is required is because Gateways can be considered “dumb” – forwarding all sensor data with little or no intelligence applied to what is forwarded.
The definition of LoRaWAN Gateway(s) as “one distributed antenna, common to all networks” reinforces the Gateway as a physical layer device with a passive role in the overall network. Whilst this is not entirely technically correct, conceptually, this helps to make clear why a network server functioning as a network orchestrator/master is a key component of any LoRaWAN stack.
LoRaWAN Network Server (LNS) Options
There are two fundamental types of LNS that system integrators need to consider – ‘Cloud-hosted’ and ‘Integrated’
A Cloud-hosted server typically uses the Datacentre capabilities of companies like Microsoft, Amazon or Google to provide a highly “available” multi-tenanted service on the internet with multiple instances per geographical region.
An Integrated LNS is one that runs on the same hardware platform as the LoRaWAN Gateway itself, helping to realise some economies in individual deployments and reducing dependency on third-party LNS service providers.
For completeness, its important to note that an LNS can also be hosted locally on an Ethernet LAN using a separate device such as an embedded PC. Such a PC can be selected to have just the right compute/price ratio and to act as an LNS for multiple independent Gateways. Conceptually this is identical to the idea of an Integrated LNS but with a small change in network architecture.
For simplicity, this article focusses on just the two most extreme and distinct options – a cloud-based LNS versus a fully Integrated LNS.
When deciding between an integrated LNS or a cloud-hosted LNS (available from service providers such as TTN or Loriot), it is important to consider the relative strengths and weaknesses of each solution. Generally, if the application only requires a small number of sensors in a localised environment then an Integrated LNS can be a good solution. However, the management and scalability of such a solution will always be more limited than a network (or a network of networks) orchestrated from the cloud.
|Feature||Integrated LNS||Cloud-hosted LNS|
|4G Data cost absolute||Low||Higher|
|4G Data cost risk||Low||Higher|
|Centralised network management||Unavailable without ‘workarounds’||Very granular|
|Recurring cost||Generally free||Generally chargeable|
|Compute power||Generally low||Very high|
|Network roaming||Not available||Possible|
|Ability to ‘resell’ network services||Low||High|
A more detailed explanation of the Features highlighted in the table above follow:
4G Data – Cost & Risk
All too often, the detailed considerations of using a cellular network for backhaul instead of a “wired” or “broadband” connection are not fully thought through before deployment, nor clearly explained by solution providers.
Cellular wireless backhaul to the internet offers unrivalled deployment flexibility and is an essential tool for many networks but the fact that it is fundamentally less reliable and potentially much more expensive than a broadband internet connection is overlooked or not appreciated in many instances.
Having an integrated LNS in the Gateway is unlikely to be able to help with backhaul reliability but it can certainly reduce cost and risk. By whitelisting only allowed sensors locally and only transmitting application data (not all of the LoRa management data), the amount of cellular traffic can be significantly reduced compared with a Cloud-based implementation.
This becomes commercially very significant if roaming* (aka multi-network) SIMs are being used in the application whereby the cost per GB of data transferred can be relatively very high.
It is also important to consider that a LoRa Gateway or collection of Gateways act as a distributed antenna that will forward packets of data from sensors that are not anything to do with the primary application. There is nothing to stop one, one hundred or one thousand sensors being deployed within RF range of the Gateway(s) in subsequent months or years and more cellular data traffic will accrue as a consequence.
Some have considered this an “unbound risk” with only localised white-listing and integrated LNS a feasible option to remove the risk altogether. Good network monitoring tools and thorough proof of concept testing help to mitigate data usage risk in all cellular communication-based applications.
Redundancy can be readily achieved for a cloud-hosted LNS by using standard networking/computing techniques already widely employed for other types of online service. The quality of the redundancy can be readily assessed by asking for the specifics from your LNS provider. The extent of the SLA available from the provider is a good gauge for the confidence they have in their own system.
An integrated LNS will generally exist as a single instance of an LNS service on a relatively low powered compute engine in the LoRa Gateway itself. This means that the scope for “resilience” is very limited beyond making sure that the chosen hardware and software platform is as stable and reliable as possible. Extensive soak-testing is one of the few tangible ways to ascertain the reliability of LoRaWAN Gateways with integrated LNS.
Checking the anticipated number of firmware upgrades anticipated per year or asking for evidence of the number of firmware increments in the previous year may be a signpost to the type of device you are being offered.
Centralised Network Management
When using an integrated LNS, centralised management is significantly less achievable without
workarounds or additional software being written to effectively “reinvent the wheel”.
A cloud-based LNS can provide a clear network overview, comprehensive
meta-data, full radio verbosity and gateway insights and alerts. This is arguably the only way to manage significant or multi-tenanted networks at scale.
Some IoT business cases rely on reducing recurring monthly costs to the minimum possible level to provide a service that customers consider ‘value for money’ or ‘affordable’. In this instance, removing any fees payable to 3rd party LNS providers can be a way to reduce cost and consequently hit the required metrics for a venture to succeed. Ultimately, it boils down to a typical ‘make or buy’ argument with associated risks and upfront costs if you choose to ‘do it yourself’.
Modern Cloud-computing techniques mean that the compute power of an online LNS need never be limited by the processing capacity of the server hardware itself. However, it is a very important consideration when using a LoRaWAN Gateway with an integrated LNS as such platforms must be designed to a budget and will employ low-cost processors as a consequence. Available RAM and Flash memory may also be limited. This means that the performance of the LNS service can be limited with the practical upshot being a restricted LoRa packet-processing capability.
Gateway vendors often approximate the extent of their integrated LNS capability by specifying the number of sensors that the Gateway + LNS can effectively handle. A typical figure is in the low tens of sensors and whilst this represents a significant limitation, it still means that an integrated LNS can be applicable for a wide number of different LPWAN applications in private LoRaWAN networks.
By definition, Network Roaming can only be managed when the LNS exists in the cloud.
Ability to Resell Network services
One of the underlying ‘value-propositions’ of deploying LoRa networks is the ability to allow others to use a network that you have built for your own purposes.
For example, a network that has been deployed on campus for environmental monitoring purposes could be made available to a 3rd party responsible for other assets on the same campus such as streetlights or dustbins. This could save the 3rd party the cost of more expensive GSM or cabled solutions and/or realise efficiencies in how they operate.
The ‘shared network’ concept can be possible with an Integrated LNS but a cloud-based LNS is much more suited to this type of implementation making long-term management and scalability easier and more cost-effective, especially as the number of Gateways increases.
As this article has illustrated, there are a number of LoRaWAN implementation methodologies available and whilst quite a detailed subject, the location of the LNS is very important as it can significantly change the technical and commercial dynamics of a LoRa based IoT proposition.
For more information: Robustel
“David has 20 years of experience in technical sales and marketing with a focus in industrial and wireless automation. Much of this experience has been gained working on projects in the IoT / M2M space across a multitude of vertical markets.
A self-confessed geek at heart, David has excelled within his chosen roles due to a fundamental desire to understand the complex and find business benefits & opportunities where others don’t care to look.
An education in Physics as well as a comprehensive education in life at the University of Sussex in the late 90s provided David with the tools to understand technology and be able to present to and share with others in a meaningful way.”