#lora vs lorawan | Explore Tumblr posts and blogs

iotagger · 7 years ago

Text

Hardware solutions for Eclipse IOT Challenge: Exploring LoRa/LoRaWAN

The Eclipse IOT challenge lead me to research more in depth different technologies both from the hardware and the software aspect. As part of product development and delivery one has to come up with the solution for a problem. In this case the problem is parking in urban areas, or the lack of smarter parking solutions. Such implementation would not only allow end users to have a better parking experience while saving time in finding an adequate spots but also provides the city with valuable data to be used for city planning and city improvement projects.

Once the issue is identified, it was important to find a technical solution that would align with our needs. For city implementations, given the broad area that needs to be covered, we would need a type of communication that is long range and low cost, both in cost of sending data and power consumption. I first tackled the hardware needs once the design was evaluated. The prototype for a smart city solution needs to also be scalable while adding the least overhead in cost and infrastructure needed.

In this article I will go more in depth on the research done to identify one of the key components of the project. I will share a summary of my findings in hopes of helping others that are also exploring similar solutions.

Evaluating communication solutions:

I evaluated BLE, bluetooth, cellular, satellite, Wi-Fi, SigFox, Zigbee and Lora. Bluetooth and Wi-Fi, given its range limitation and cost were not considered for this prototype. Cellular communications have a higher cost as well, and at even steeper price comes satellite communication; both this options were also discarded. SigFox and LoRa/LoraWAN were the runner up candidates. I came across a comprehensive post on the comparison of SigFox and LoRa that is worth the read https://www.link-labs.com/blog/sigfox-vs-lora . The winner was LoRa.

Why Lora?

As explained by Libelium on http://www.libelium.com/development/waspmote/documentation/lora-vs-lorawan/ LoRa contains only the link layer protocol and is perfect to be used in P2P communications between nodes. LoRa modules are a little cheaper that the LoRaWAN ones.. LoRaWAN includes the network layer too so it is possible to send the information to any Base Station already connected to a Cloud platform. LoRaWAN modules may work in different frequencies by just connecting the right antenna to its socket..

LoRa which stands for long range wireless operates at a low bandwidth, meaning that its best application is for sending smaller pieces of data such as sensor data. LoRaWAN is known for its good penetration and long coverage which has been recorded to reach over 10 KM distance. LoRaWAN operates on unlicensed bands, so in most countries is legal to have you own LoRaWAN gateway cutting down the cost given that you will not have to pay a carrier or third party to supply you with the service.

Additionally a selling point for me personally was the wide accessibility to various developer platforms and hardware solutions such as DIY LoRa kits, libraries and Arduino compatible LoRa modules. The Things Network offers a strong platform with access to resources, documentation and a great community of IOT LoRa enthusiast.

Gateway

Lets take a look at one of the hardware pieces now. “Gateways form the bridge between devices and The Things Network. Devices use low power networks like LoRaWAN to connect to the Gateway, while the Gateway uses high bandwidth networks like WiFi, Ethernet or Cellular to connect to The Things Network. Gateways are routers equipped with a LoRa concentrator, allowing them to receive LoRa packets”(see more at https://www.thethingsnetwork.org/docs/gateways/). Below is a list of some gateways that were evaluated for this project. I spent time looking at their platform flexibility, the documentation and support provided and what would be the most cost effective solution for a minimum viable product (MVP).

Lorixone

https://lorixone.io/

LORIX One is the first low cost gateway designed and assembled in Switzerland. Its technical specifications include Runx Linux Yocto 4.X SX1301 gateway chip SPI based 8 channels, 49 demodulators @ 868MHz

Lorixone counts with great documentation accessible at https://www.thethingsnetwork.org/labs/story/install-awesome-lorix-one-gateway

Kerlink

Details at https://www.kerlink.com/iot-solutions-services/IoT%20LoRaWan%20Solutions/

Wirnet iBTS is a range of modular and upgradeable gateways designed for IoT public operators. It can be upgraded up to 64 LoRa™ channels to offer an answer to massive messages supporting. I was unable to identify the price point for this gateway.

The Things Gateway

Details at https://www.thethingsnetwork.org/docs/gateways/gateway/

Retails: € 300.00 € 280.00 (ex VAT)

Originally started as a Kikstarter campaign viewable at https://www.kickstarter.com/projects/419277966/the-things-network it provides 10 km / 6 miles radius of network coverage, it can server thousands of nodes and its an straight forward to set up. It counts with ample documentation and a strong community.

Technical specifications:

Fastest way to get started with LoRaWAN (Long Range WAN)

Set up your own LoRaWAN network in as little as 5 minutes

Connects easily to your WiFi or Ethernet connection

Wireless range of up to 10 km (6 miles)

Engage with a global community of IoT developers

Easy cloud integration with popular IoT platforms

Based on open source hardware and software standards

Devices can freely communicate over all gateways connected to The Things Network

XBEE slot for future connectivity protocols or homebrew add-ons.

Security through the https connection and embedded in the LoRaWAN protocol

Can serve thousands of nodes (depending on traffic)

Laird — RG1xx

Details at: https://www.lairdtech.com/products/rg1xx-lora-gateway

Retail 400+ US dollars

This gateway counts with a dual-band Wi-Fi, BT v4.0 (BLE and Classic) and wired Ethernet; LoRa range up to 10 miles and pre-loaded LoRa Packet Forwarder software

Technical specifications:

Full Linux operating system — Kernel v4.x running on Atmel A5 Core @ 536 MHz

Multiple interfaces such as LoRaWAN, 802.11a/b/g/n, Bluetooth v4.0, and Ethernet

8-Channel LoRaWAN support with up to +27dBM max transmit power

Comprehensive Certifications for FCC / IC (RG191) and CE (RG186) (all pending)

Industrial temperature range (-30º to 70º C)

Advanced deployment tools including intuitive web-based configuration, integrated LoRa packet forwarder, and default settings for multiple LoRaWAN Network Server vendors

Enterprise-grade security built on Laird’s years of experience in wireless

Industry-leading support works directly with Laird engineers to help deploy your design

LoRa Network Server pre-sets — The Things Network, Loriot, Stream and Senet

Multitech

Developer resource http://www.multitech.net/developer/products/multiconnect-conduit-platform/

Retail 675–685 US dollars

Breakdown: base gateway MTCDT-H5–210L-US-EU-GB https://www.digikey.com/product-detail/en/multi-tech-systems-inc/MTCDT-H5-210L-US-EU-GB/881-1236-ND/5246365() $490, antenna (https://www.digikey.com/product-detail/en/multi-tech-systems-inc/AN868-915A-10HRA/881-1242-ND/5246371) $13, LoRa module MTAC-LORA-915 (https://www.digikey.com/product-detail/en/multi-tech-systems-inc/MTAC-LORA-915/881-1239-ND/5246368) $180

The MultiConnect® Conduit™ is a configurable, scalable cellular communications gateway for industrial IoT applications. Conduit allows users to plug in two MultiConnect mCard™ accessory cards supporting wired or wireless interfaces. It counts with open source Linux development, wwo mcard slots, Lora 8 channel receiver, Spred spectrum frequency hopping that is ued to Up to 10 miles line of sight. MultiConnect has done a great job with its documentation and it counts with its own platform that can be used as well.

Lorrier LR2

Details at: https://lorrier.com/#introducing-lr2

Developer resource: https://github.com/lorriercom

Retail €615.00 €755.00

Based on LoRaWAN™ protocol. This is a fully outdoor device intended to establish a wide coverage network by telecommunications operators and local network by individuals or IoT connectivity service providers. The whole solution, including both HW and SW parts, follows the Lorrier culture, and it is shared as an Open Source.

The gateway is based on iC880a LoRaWAN™ concentrator by IMST which uses Semtech SX1301 base band processor designed for use with LoRa® networks. BeagleBone Green with 1GHz (2000 MIPS) processor and fully operational on fast SPI bus was chosen as a powerful control unit.

LoRa/LoRaWAN Gateway — 915MHz for Raspberry Pi 3

Details at https://www.seeedstudio.com/LoRa%2FLoRaWAN-Gateway-915MHz-for-Raspberry-Pi-3-p-2821.html

Retails 289.00 US dollars

If you want to build you own LoRa network, there are 3 things that you should prepare to get started: a Gateway, at least one Node and a local server where you can monitor all your devices. This kit provides a gateway & local server that allows you to collect and transfer data among all your LoRa nodes. By connecting the gateway with Seeeduino LoRaWAN and Grove modules, you can build your IOT prototype within minutes.

Regarding the gateway module RHF0M301, it is a 10 channel(8 x Multi-SF + 1 x Standard LoRa + 1 x FSK) LoRaWan gateway moduel with a 24pin DIP port on board, users can easily connect the RHF0M301 with PRI 2 bridge RHF4T002, adapter for Raspberry Pi 3 and RHF0M301.

RisingHF gateway

Details at http://www.risinghf.com/product/rhf0m301/?lang=en

I have seen this solution mentioned and used across the LoRaWAN community. Its technical specs are RHF0M301 is a 10 channels (8 x Multi-SF + 1 x Standard LoRa + 1 x FSK) LoRa/LoRaWAN gateway or concentrator module. The module is integrated one 24 pins DIP hearder, with this header user could connect RHF0M301 with his own embedded platform to build a customized gateway easily.

LG01 LoRa OpenWrt IoT Gateway by Dragino Tech

Details at https://www.tindie.com/products/edwin/lg01-lora-openwrt-iot-gateway/?pt=ac_prod_search

Retails 56.00 US dollars

This gateway is a long distance wireless 433/868/915Mhz, OpenWrt, LoRa IoT Gateway

The LG01 is an open source single channel LoRa Gateway. It lets you bridge LoRa wireless network to an IP network via WiFi, Ethernet, 3G or 4G cellular.

DYI options:

There are various posts on DYI options based both from Raspberry Pi and Arduino boards. Below are a few:

Build your own gateway

https://www.thethingsnetwork.org/docs/gateways/start/build.html

Building a Raspberry Pi Powered LoRaWAN Gateway

https://www.rs-online.com/designspark/building-a-raspberry-pi-powered-lorawan-gateway

Hardware IMST iC880A LoRaWAN “concentrator” board and Raspberry Pi

The iC880A — LoRaWAN https://wireless-solutions.de/products/long-range-radio/ic880a iC880A is able to receive packets of different end devices send with different spreading factors on up to 8 channels in parallel. In combination with an embedded Linux board like Raspberry Pi, Beagle Bone, Banana Pi and the HAL software from https://github.com/Lora-net a complete LoRaWAN® gateway can be setup easily.

From zero to LoRaWAN in a weekend

https://github.com/ttn-zh/ic880a-gateway/wiki

Based iC880a concentrator board and a Raspberry Pi 2.

A DIY low-cost LoRa gateway

http://cpham.perso.univ-pau.fr/LORA/RPIgateway.html

The gateway is based on a Raspberry PI. RPI 1B+/2B/3B can be used. The LoRa modules comes from (a) Libelium LoRa radio module, (b) HopeRF RFM92W/HopeRF RFM95W (or RFM96W for 433MHz), © Modtronix inAir9/inAir9B (or inAir4 for 433MHz), (d) NiceRF LoRa1276. Libelium LoRa and RFM92W use the Semtech SX1272 chip while RFM95W, inAir9/9B and NiceRF LoRa1276 use the SX1276 which is actually more versatile.

Note: The LoRa module and the LoRaWAN module are not compatible because the protocols are different. The LoRa module implements a simple link protocol, created by Libelium. However, the LoRaWAN module runs the LoRaWAN protocol, a much richer and more advanced protocol, created by the LoRa Alliance.

Check out their Github page with detailed documentation https://github.com/CongducPham/LowCostLoRaGw

Conclusion on gateways:

The gateway is a key portion of this solution given that the sensors will need to send the information “somewhere” where it can either be analyzed on the edge or sent to the cloud. After considering price ranges on both the parts needed for a DIY solution or a full blown gateway I considered those solutions that would be cost effective and which I was most familiar with. The “LG01 LoRa OpenWrt IoT Gateway by Dragino Tech” seemed the best approach. The developer kit counts with an Arduino developer node and a Developer gateway. Note that this solution only counts with ONE channel, in comparison with other solutions that allow 8+ channels. This was a compromise that was evaluated and given that this will be a prototype the one channel option seemed sufficient.

In the following articles I will showcase both the remaining hardware parts and the software portion along with updates on how the project is coming along.

#iot #internetofthings #technology #TechNews #tech #smartcities #lora #lorawan

17 notes · View notes

mollydpowellus · 6 years ago

Text

The business case of densifying LoRaWAN deployments

LoRaWAN has recently emerged as one of the key radio technologies to address the challenges of Low Power Wide Area Network (LPWAN) deployments, namely power efficiency, long range, scalable deployments, and cost-effectiveness. The LoRa Alliance has had an exponential growth with 500+ members with the recent arrival of heavyweight members such as Google, Alibaba, and Tencent joining the alliance. The first wave of LoRaWAN was primarily focused on large country-wide deployments led by operators such as KPN, Orange, Swisscom and many more. However, the next wave that is already coming is the arrival of private LoRaWAN deployments from large enterprises and enabling roaming for inter-connection amongst public/private networks (esp. for use cases which involve LPWAN Geolocation [8] [9]]). As the IoT deployments grow in both the densification and geographical footprint, it is inevitable that network design becomes one of the important factors ensuring long-term success and profitability of both operators and end-customers relying on LoRaWAN connectivity for their IoT use cases. A typical example is the recent 3 million water meter contract awarded by Veolia Birdz to Orange [12]: such large-scale projects require careful network planning to achieve the required densification and quality of service while optimizing costs.

A Closer Look at Densification techniques for LoRaWAN

LoRaWAN deployments use a star topology with a frequency reuse factor of 1 which allows simplicity in network deployment and ongoing densification: there is no need for frequency pattern planning or reshuffling as more gateways are added to the infrastructure. Compared to mesh technologies, the single hop to network infrastructure minimizes power consumption as nodes do not need to relay communication from other nodes. Another advantage is that gradual initial network deployment in sparse mode with low node density is possible, compared to mesh which requires minimum node density to operate. Even more importantly, LoRaWAN is immune from the exponential packet loss suffered by multi-hop RF mesh technologies in presence of increasing interferers and noise floor power. Another unique feature of LoRaWAN networks is that messages in uplink can be received by any gateway (Rx macro-diversity), and it is the function of a network server to remove duplicates in uplink and select the best gateway for downlink transmission based on the uplink RSSI estimates. This allows enabling of features such as geolocation to be easily built into LoRaWAN deployment and enables uplink macro-diversity that significantly improves network capacity and QoS (Quality of Service). LoRaWAN also supports features such as Adaptive Data Rate (ADR) that allows network server to dynamically change parameters of end-devices such as transmit power, frequency and spreading factor via downlink MAC commands. Optimization of theses settings is key to increase the capacity and reduce the power consumption of end-devices. The optimization of LoRaWAN parameters along with densification can lead massive amounts of capacity increase in the network. In fact, the LoRaWAN capacity of the network can scale almost indefinitely with densification.

Figure 1: Actility Webinar - Designing LoRaWAN network for Dense Deployment [1] [2] [3]

The future of LoRaWAN networks, particularly in urban environments where the noise floor is expected to get higher due to increased traffic, goes towards micro-cellular networks

How does densification lead to lower TCO for Enterprise deployment?

As the network is densified by deploying more LoRaWAN Gateways and adaptive data rate and power control algorithms are applied intelligently in the network, this leads in dramatic reduction of power consumption of end-device and thus reduction in Total Cost of Ownership (TCO) of end devices. The figures below show clearly that densification can lead to upto 10X savings in both power consumption and overall reduction in 10-year TCO for enterprise deployment. Changing the batteries require manual labor and is the cost that can significantly dominate 10-year TCO of large-scale enterprise deployment (for ex. Smart gas/water meters).

Figure 2: Battery Lifetime Improvement with densification [1] [2] [3]

Figure 3: Impact on 10-year TCO due to densification [1] [2] [3]

Densification leads to very dramatic reduction in power consumption of the end-devices thus reducing overall Total Cost of Ownership (TCO)

LoRaWAN offers disruptive Deployment Models

LoRaWAN is generally deployed in unlicensed spectrum which allows anyone to roll-out IoT/LPWAN network based on LoRaWAN. This allows three deployment models: 1. Public Operator Network: In this traditional model, the operator invests in a regional or nation-wide network and sells connectivity services to its customers. 2. Private/Enterprise Network: In this model, enterprise customers typically setup LoRaWAN gateways on private premises (e.g. an airport), and either have these gateways managed by an operator, or use their own LoRaWAN network platform. This mode of deployment is a game changer for dense device use cases, as network capacity and enhanced QoS can be provided at marginal increased cost. It becomes possible because LoRaWAN runs in unlicensed spectrum and gateways are quite inexpensive and easy to deploy. 3. Hybrid model: This is the most interesting model that LoRaWAN allows due to its open architecture. This is not possible or rather difficult in other competing LPWA technologies or Cellular IoT (due to licensed spectrum and absence of roaming/peering model between private and public networks). There are initiatives like CBRS and MulteFire from 3GPP Players but they are still in progress and far from maturity for large scale IoT deployments (esp. for use cases that demand 10-15 years+ battery lifetime). In hybrid model, operator provides light country-wide outdoor coverage, but different stakeholders such as private enterprises or individuals help in densifying the network further based on their needs on their premises, via managed networks. This model enables a win-win private/public partnership in sharing the costs and revenues from the network and densify the network where the applications and devices are most present. This model is possible because multiple gateways can receive LoRaWAN messages and network server removes duplication. In the cases where different operators/enterprises run their networks, LoRa Alliance already has approved roaming architecture in “LoRaWAN Backend Interfaces 1.0 Specification” [6] [7] to enable network collaboration. This model significantly reduces the operator investment and offers a disruptive business model to build IoT capacity where it is mostly needed.

Figure 4: LoRaWAN Hybrid Deployment Model (source : Actility)

LoRaWAN enables Public-Private deployment that allows disruptive model for cost/revenue sharing and densifying the network where it is needed most, depending on IoT application needs

LoRaWAN densification: A Key driver for reduction in Operator TCO

When designing and deploying a LoRaWAN network, the system operator must balance the cost of a dense network (and it's served sensors) against the cost of a sparse network (and it's served sensors).

Traditional vs Opportunistic network designs

In the traditional deployment model, the operator deploys LoRaWAN gateways on telecom towers. This entails leasing the space from the tower owner, purchasing a waterproof outdoor gateway, climbing the tower to hang the gateway, and perhaps paying for additional power, zoning, permitting, and backhaul. The operator does the detailed RF propagation study and hangs enough gateways to provide coverage for the sensor locations required to provide the services he wants to provide. Another option is to opportunistically deploy “femto” gateways in devices that the operator is already fielding. The gateways are stateless, and thus do not add much complexity to the hosting device. An 8-channel LoRaWAN reference design is mated to the host device using either USB or I2C. The options here are quite diverse. The operator can embed a simple 8 channel gateway into ongoing WiFi hotspots, power supplies, amplifiers, cable modems, thermostats, virtual assistants, or any mass-produced device that already has backhaul. The Bill of Materials adder is quite modest, the power consumption and heat dissipation are less than 3 Watts, and the size delta is roughly 7 cm by 3 cm. Calculating the number of opportunistic gateways to provide adequate coverage for a given deployment can be challenging. The height of the gateways has a large impact on the coverage of the gateway. A gateway deployed in a 20th story of an apartment building has a much better coverage pattern than the same gateway deployed in the basement of a single-family home. Gateways deployed in WiFi hotspots mounted on power poles have a different coverage area than a gateway deployed on light poles. So, the actual number of gateways deployed in each scenario varies widely. When you complete the detailed design of each network type, you typically find that an opportunistic deployment model allows the operator to cover a given area by deploying roughly 100 times as many gateways for roughly 1/10th of the cost (when compared to the traditional 3rd party leased tower model). Example use-case with water meters

For the rest of this analysis, we will assume that the operator needs to deploy a LoRaWAN network to service 100K water meters. Water meters represent a difficult RF propagation model. They are installed at or below ground level, must last 20 years, and suburban meters tend to have accumulations of grass and dirt collect over time. Let’s assume a North American deployment model, and we have the option of using a high power (27dBm) or a low power (17dBm) meter. One possible design is to use a tower-based approach. In a tower-based approach, the operator typically ends up deploying high power water meters in order to reduce the number of (expensive) tower leases. In order to run at high power, the North American regulations require the sensor to send across 50+ channels, which drives the operator to deploy 64 channel gateways. Let’s assume that the average distance between a water meter and a tower-based gateway is ~3km and the sensors need to send one reading per day. Many of the meters thus operate at SF10 at 27dBm. The sensor designer includes a high-power RF amplifier, calculates the energy requirements over the life of the sensor, and sizes the battery appropriately. Another possible design is to opportunistically deploy thousands of femto gateways into the area. The question boils down to “How many femto gateways do I need to cover the desired area?”. Working backwards from the densest possible deployment, most MSOs (Multiple-System Operator) serve 1/3 of the households in their footprint. In many urban environments, the average distance between a given operator’s subscribers is 30 meters. If such an operator could opportunistically deploy in most of those sites, they would have inter-gateway distances as small as 30 meters. For the purposes of this analysis, let’s say that the average distance between the sensor and the closest gateway is reduced from 3000 meters to 100 meters. When a sensor is 100 meters from a gateway, it can typically operate at SF7 at 17dBm (or lower). Clearly, the network designer must account for a distribution of distances between a given sensor and its closest gateway, but the overall power savings is significant. It is also instructive to compare the overall capacity of a tower-based LoRaWAN network to the overall capacity of the opportunistic LoRaWAN network. Remembering that 100 eight channel opportunistic gateways cost about 1/10th of a single 64 channel gateway, we realize that we get ~13 times as much network capacity for 1/10th of the cost. As the sensor density increases, we could deploy additional opportunistic gateways and get ~130 times as much network capacity for the same cost as a tower-based network. When we compare the cost to build a sensor designed to last 20 years using SF10 at 27dBm to the cost to build a sensor designed to last 20 years using SF7 at 17dBm, we find that we can save more than $10 per sensor by deploying the denser network. So, in addition to saving a significant amount of capital by opportunistically deploying the gateways, the operator can save more than $10 per water meter by opportunistically deploying a dense network. This saves more than $1M on the 100K water meter deployment. When one layers in additional use cases, the dense LoRaWAN network provides sensor savings on each additional set of sensors. Most of the sensors do not have the 20 years requirement and thus do not save the same amount of money, but batteries are one of the primary drivers for any sensor’s cost. Conclusion

This analysis is somewhat simplified, and a very large-scale deployment may require a certain amount of traditional gateway placement to provide an “umbrella” of coverage that is then densified using opportunistic methods. By densifying the network, the overall sensor power budget is decreased significantly. One could also envision a deployment model in which an opportunistic gateway is deployed in conjunction with a set of services. The operator would add IoT based services to an existing bundle (let’s say voice/video/data, thermostat control or personal assistant) and know that the sensors would be co-resident with the gateway.

What is the future of LoRaWAN?

LoRaWAN exhibits significant capacity gains and massive reduction in power consumption and TCO when ADR algorithms are used intelligently in the network. We showed how LoRaWAN networks are deployed for coverage and how network capacity can be scaled gracefully by adding more gateways. There are already 16 channels in EU, but there have been recent modifications of the regulatory framework to relax the spectrum requirements and increase transmit power, duty cycle and number of channels [22]. Moreover, Semtech released the latest version of LoRa chipsets [23] with the following key features:

50% less power in receive mode

20% extended cell range

+22 dBm transmit power

A 45% reduction in size: 4mm by 4mm

Global continuous frequency coverage: 150-960MHz

Simplified user interface with implementation of commands

New spreading factor of SF5 to support dense networks

Protocol compatible with existing deployed LoRaWAN networks

The above LoRaWAN features and upcoming changes to EU regulations will allow significantly scaling of unlicensed LoRaWAN deployments for years to come to meet the needs of IoT applications and use cases. LoRaWAN capacity depends indeed on the regional and morphology parameters. As we have showed in the above results, if the network is deployed carefully and advanced algorithms such as ADR are used, there can be dramatic increase in network capacity and massive reduction in TCO. This will be one of the main factors that will determine the success of LoRaWAN deployments as the demands and breadth of IoT applications scale in future. We also showed earlier how LoRaWAN offers innovative public/private deployment model in which operators can build capacity incrementally and supplement with extra capacity by leveraging gateways deployed from private individuals/enterprises. Typically, for cellular networks there can be anywhere from 5-10% IoT devices on cell-edge which are in outage [10]. This applies especially to deep indoor nodes (for example, smart meters with additional 30 dB penetration loss). Such nodes can only be covered by densification of cellular network which is expensive considering it is being done only for 5-10% of IoT devices. One way to address this problem is deploying private LoRaWAN on cell-edge and using multi-technology IoT platform that combines both LoRaWAN and Cellular IoT [11]. On the other hand, LoRaWAN offers a cost-effective way to augment network capacity where it's needed most. LoRaWAN gateways are very cost-effective and can be deployed using Ethernet/3G/4G backhaul with minimal investment in comparison to 3GPP small cells. This allows building IoT network in cost-effective manner and scale it progressively based on the application needs. We believe that his deployment model has dramatic effect on ROI for IoT connectivity based on LoRaWAN. The LoRa Alliance has standardized the roaming feature, which enables multiple LoRaWAN networks to collaboratively serve IoT devices. Macro-diversity used across deployments enables operators/enterprises to jointly densify their networks, hence providing better coverage at lower costs. The future of LoRaWAN as shown below will be private/enterprise network deployments and disruptive business models through roaming with the public networks [4] [5] [6] [7].

Figure 5: Future of LoRaWAN deployments

LoRaWAN does provide horizontal connectivity solution to address wide-ranging needs for IoT applications for LPWAN deployments. However, these benefits are only possible with intelligent network server algorithms proprietary to network solution vendors

For any questions, contact the author below,

https://www.linkedin.com/in/rohit-gupta-2b51503a/

References:

[1] Actility webinar Replay: Designing a LoRaWAN Network for Dense Deployment, https://www.youtube.com/watch?v=xQOZWUQdvf0 [2] Actility webinar slides: Designing a LoRaWAN Network for Dense Deployment, https://www.slideshare.net/Actility/designing-lorawan-for-dense-iot-deployments-webinar. [3] Actility Whitepaper: Designing a LoRaWAN Network for Dense Deployment, https://www.slideshare.net/Actility/designing-lorawan-networks-for-dense-iot-deployments [4] Actility webinar slides: Industrial IoT - Transforming businesses today with LoRaWAN, https://www.slideshare.net/Actility/actility-and-factory-systemes-explain-how-iot-is-transforming-industry [5] Actility webinar Replay: Industrial IoT - Transforming businesses today with LoRaWAN, https://www.youtube.com/watch?v=pRoEbWjffBA [6] Actility webinar slides: LoRaWAN Roaming Webinar, https://www.slideshare.net/Actility/lorawan-roaming [7] Actility webinar Replay: LoRaWAN Roaming webinar, https://www.youtube.com/watch?v=tWP6VV1CKEg [8] Actility webinar slides: Multi-technology IoT Geolocation, https://www.slideshare.net/Actility/multi-technology-geolocation-webinar [9] Actility webinar Replay: Multi-technology IoT Geolocation, https://www.youtube.com/watch?v=YzFZqMBI2QA [10] http://vbn.aau.dk/files/236150948/vtcFall2016.pdf [11] Actility Whitepaper: How to build a multi-technology scalable IoT connectivity Platform, https://www.slideshare.net/Actility/whitepaper-how-to-build-a-mutiltechnology-scalable-iot-connectivity-platform [12] https://www.orange.com/en/Press-Room/press-releases/press-releases-2018/Nova-Veolia-and-its-subsidiary-Birdz-choose-Orange-Business-Services-to-help-them-digitalize-Veolia-s-remote-water-meter-reading-services-in-France

from My Updates http://blog.3g4g.co.uk/2019/01/the-business-case-of-densifying-lorawan.html

0 notes

elcereza · 1 year ago

Text

Leitura analógica do LoRaMesh da Radioenge

Aprenda como usar a leitura analógica com o módulo LoRaMesh da Radioenge

A leitura analógica com o LoRaMesh possibilita com que possamos fazer um amplo sistema de sensoriamento remoto sem precisar necessariamente de microcontrolador adicional na parte do slave. Por qual motivo usar a leitura analógica do LoRaMesh da Radioenge? Uma leitura digital em muito dos casos já é mais que o suficiente para saber se algo está ou não funcionando, mas a leitura analógica do…

View On WordPress

#lora mesh arduino #lora mesh chat #lora mesh device #lora mesh library #lora mesh module #lora mesh network #lora mesh network raspberry pi #lora mesh protocol #lora mesh radio #lora mesh range #lora vs lorawan #loramesh #lorawan #lorawan devices #lorawan gateway #lorawan network #mesh lora

0 notes

mollydpowellus · 6 years ago

Text

The business case of densifying LoRaWAN deployments

The LoRa Alliance has had an exponential growth with 500+ members with the recent arrival of heavyweight members such as Google, Alibaba, and Tencent joining the alliance.

The first wave of LoRaWAN was primarily focused on large country-wide deployments led by operators such as KPN, Orange, Swisscom and many more. However, the next wave that is already coming is the arrival of private LoRaWAN deployments from large enterprises and enabling roaming for inter-connection amongst public/private networks (esp. for use cases which involve LPWAN Geolocation [8] [9]]). As the IoT deployments grow in both the densification and geographical footprint, it is inevitable that network design becomes one of the important factors ensuring long-term success and profitability of both operators and end-customers relying on LoRaWAN connectivity for their IoT use cases.

A typical example is the recent 3 million water meter contract awarded by Veolia Birdz to Orange [12]: such large-scale projects require careful network planning to achieve the required densification and quality of service while optimizing costs.

A Closer Look at Densification techniques for LoRaWAN

Compared to mesh technologies, the single hop to network infrastructure minimizes power consumption as nodes do not need to relay communication from other nodes. Another advantage is that gradual initial network deployment in sparse mode with low node density is possible, compared to mesh which requires minimum node density to operate. Even more importantly, LoRaWAN is immune from the exponential packet loss suffered by multi-hop RF mesh technologies in presence of increasing interferers and noise floor power.

Another unique feature of LoRaWAN networks is that messages in uplink can be received by any gateway (Rx macro-diversity), and it is the function of a network server to remove duplicates in uplink and select the best gateway for downlink transmission based on the uplink RSSI estimates. This allows enabling of features such as geolocation to be easily built into LoRaWAN deployment and enables uplink macro-diversity that significantly improves network capacity and QoS (Quality of Service).

LoRaWAN also supports features such as Adaptive Data Rate (ADR) that allows network server to dynamically change parameters of end-devices such as transmit power, frequency and spreading factor via downlink MAC commands. Optimization of theses settings is key to increase the capacity and reduce the power consumption of end-devices.

The optimization of LoRaWAN parameters along with densification can lead massive amounts of capacity increase in the network. In fact, the LoRaWAN capacity of the network can scale almost indefinitely with densification.

Figure 1: Actility Webinar - Designing LoRaWAN network for Dense Deployment [1] [2] [3]

The future of LoRaWAN networks, particularly in urban environments where the noise floor is expected to get higher due to increased traffic, goes towards micro-cellular networks

How does densification lead to lower TCO for Enterprise deployment?

Figure 2: Battery Lifetime Improvement with densification [1] [2] [3]

Figure 3: Impact on 10-year TCO due to densification [1] [2] [3]

Densification leads to very dramatic reduction in power consumption of the end-devices thus reducing overall Total Cost of Ownership (TCO)

LoRaWAN offers disruptive Deployment Models

LoRaWAN is generally deployed in unlicensed spectrum which allows anyone to roll-out IoT/LPWAN network based on LoRaWAN. This allows three deployment models:

1. Public Operator Network: In this traditional model, the operator invests in a regional or nation-wide network and sells connectivity services to its customers.

2. Private/Enterprise Network: In this model, enterprise customers typically setup LoRaWAN gateways on private premises (e.g. an airport), and either have these gateways managed by an operator, or use their own LoRaWAN network platform.

This mode of deployment is a game changer for dense device use cases, as network capacity and enhanced QoS can be provided at marginal increased cost. It becomes possible because LoRaWAN runs in unlicensed spectrum and gateways are quite inexpensive and easy to deploy.

3. Hybrid model: This is the most interesting model that LoRaWAN allows due to its open architecture.

This is not possible or rather difficult in other competing LPWA technologies or Cellular IoT (due to licensed spectrum and absence of roaming/peering model between private and public networks). There are initiatives like CBRS and MulteFire from 3GPP Players but they are still in progress and far from maturity for large scale IoT deployments (esp. for use cases that demand 10-15 years+ battery lifetime).

In hybrid model, operator provides light country-wide outdoor coverage, but different stakeholders such as private enterprises or individuals help in densifying the network further based on their needs on their premises, via managed networks. This model enables a win-win private/public partnership in sharing the costs and revenues from the network and densify the network where the applications and devices are most present.

This model is possible because multiple gateways can receive LoRaWAN messages and network server removes duplication. In the cases where different operators/enterprises run their networks, LoRa Alliance already has approved roaming architecture in “LoRaWAN Backend Interfaces 1.0 Specification” [6] [7] to enable network collaboration.

This model significantly reduces the operator investment and offers a disruptive business model to build IoT capacity where it is mostly needed.

Figure 4: LoRaWAN Hybrid Deployment Model (source : Actility)

LoRaWAN enables Public-Private deployment that allows disruptive model for cost/revenue sharing and densifying the network where it is needed most, depending on IoT application needs

LoRaWAN densification: A Key driver for reduction in Operator TCO

When designing and deploying a LoRaWAN network, the system operator must balance the cost of a dense network (and it's served sensors) against the cost of a sparse network (and it's served sensors).

Traditional vs Opportunistic network designs

Another option is to opportunistically deploy “femto” gateways in devices that the operator is already fielding. The gateways are stateless, and thus do not add much complexity to the hosting device. An 8-channel LoRaWAN reference design is mated to the host device using either USB or I2C. The options here are quite diverse. The operator can embed a simple 8 channel gateway into ongoing WiFi hotspots, power supplies, amplifiers, cable modems, thermostats, virtual assistants, or any mass-produced device that already has backhaul. The Bill of Materials adder is quite modest, the power consumption and heat dissipation are less than 3 Watts, and the size delta is roughly 7 cm by 3 cm.

Calculating the number of opportunistic gateways to provide adequate coverage for a given deployment can be challenging. The height of the gateways has a large impact on the coverage of the gateway. A gateway deployed in a 20th story of an apartment building has a much better coverage pattern than the same gateway deployed in the basement of a single-family home. Gateways deployed in WiFi hotspots mounted on power poles have a different coverage area than a gateway deployed on light poles. So, the actual number of gateways deployed in each scenario varies widely. When you complete the detailed design of each network type, you typically find that an opportunistic deployment model allows the operator to cover a given area by deploying roughly 100 times as many gateways for roughly 1/10th of the cost (when compared to the traditional 3rd party leased tower model).

Example use-case with water meters

One possible design is to use a tower-based approach. In a tower-based approach, the operator typically ends up deploying high power water meters in order to reduce the number of (expensive) tower leases. In order to run at high power, the North American regulations require the sensor to send across 50+ channels, which drives the operator to deploy 64 channel gateways. Let’s assume that the average distance between a water meter and a tower-based gateway is ~3km and the sensors need to send one reading per day. Many of the meters thus operate at SF10 at 27dBm. The sensor designer includes a high-power RF amplifier, calculates the energy requirements over the life of the sensor, and sizes the battery appropriately.

Another possible design is to opportunistically deploy thousands of femto gateways into the area. The question boils down to “How many femto gateways do I need to cover the desired area?”. Working backwards from the densest possible deployment, most MSOs (Multiple-System Operator) serve 1/3 of the households in their footprint. In many urban environments, the average distance between a given operator’s subscribers is 30 meters. If such an operator could opportunistically deploy in most of those sites, they would have inter-gateway distances as small as 30 meters. For the purposes of this analysis, let’s say that the average distance between the sensor and the closest gateway is reduced from 3000 meters to 100 meters. When a sensor is 100 meters from a gateway, it can typically operate at SF7 at 17dBm (or lower). Clearly, the network designer must account for a distribution of distances between a given sensor and its closest gateway, but the overall power savings is significant.

It is also instructive to compare the overall capacity of a tower-based LoRaWAN network to the overall capacity of the opportunistic LoRaWAN network. Remembering that 100 eight channel opportunistic gateways cost about 1/10th of a single 64 channel gateway, we realize that we get ~13 times as much network capacity for 1/10th of the cost. As the sensor density increases, we could deploy additional opportunistic gateways and get ~130 times as much network capacity for the same cost as a tower-based network.

When we compare the cost to build a sensor designed to last 20 years using SF10 at 27dBm to the cost to build a sensor designed to last 20 years using SF7 at 17dBm, we find that we can save more than $10 per sensor by deploying the denser network.

So, in addition to saving a significant amount of capital by opportunistically deploying the gateways, the operator can save more than $10 per water meter by opportunistically deploying a dense network. This saves more than $1M on the 100K water meter deployment. When one layers in additional use cases, the dense LoRaWAN network provides sensor savings on each additional set of sensors. Most of the sensors do not have the 20 years requirement and thus do not save the same amount of money, but batteries are one of the primary drivers for any sensor’s cost.

Conclusion

What is the future of LoRaWAN?

There are already 16 channels in EU, but there have been recent modifications of the regulatory framework to relax the spectrum requirements and increase transmit power, duty cycle and number of channels [22].

Moreover, Semtech released the latest version of LoRa chipsets [23] with the following key features:

50% less power in receive mode

20% extended cell range

+22 dBm transmit power

A 45% reduction in size: 4mm by 4mm

Global continuous frequency coverage: 150-960MHz

Simplified user interface with implementation of commands

New spreading factor of SF5 to support dense networks

Protocol compatible with existing deployed LoRaWAN networks

We also showed earlier how LoRaWAN offers innovative public/private deployment model in which operators can build capacity incrementally and supplement with extra capacity by leveraging gateways deployed from private individuals/enterprises. Typically, for cellular networks there can be anywhere from 5-10% IoT devices on cell-edge which are in outage [10]. This applies especially to deep indoor nodes (for example, smart meters with additional 30 dB penetration loss). Such nodes can only be covered by densification of cellular network which is expensive considering it is being done only for 5-10% of IoT devices. One way to address this problem is deploying private LoRaWAN on cell-edge and using multi-technology IoT platform that combines both LoRaWAN and Cellular IoT [11].

On the other hand, LoRaWAN offers a cost-effective way to augment network capacity where it's needed most. LoRaWAN gateways are very cost-effective and can be deployed using Ethernet/3G/4G backhaul with minimal investment in comparison to 3GPP small cells. This allows building IoT network in cost-effective manner and scale it progressively based on the application needs. We believe that his deployment model has dramatic effect on ROI for IoT connectivity based on LoRaWAN.

The LoRa Alliance has standardized the roaming feature, which enables multiple LoRaWAN networks to collaboratively serve IoT devices. Macro-diversity used across deployments enables operators/enterprises to jointly densify their networks, hence providing better coverage at lower costs. The future of LoRaWAN as shown below will be private/enterprise network deployments and disruptive business models through roaming with the public networks [4] [5] [6] [7].

Figure 5: Future of LoRaWAN deployments

For any questions, contact the author below,

https://www.linkedin.com/in/rohit-gupta-2b51503a/

References:

[1] Actility webinar: Designing a LoRaWAN Network for Dense Deployment,

https://www.youtube.com/watch?v=xQOZWUQdvf0

[2] Actility webinar slides: Designing a LoRaWAN Network for Dense Deployment, https://www.slideshare.net/Actility/designing-lorawan-for-dense-iot-deployments-webinar.

[3] Actility Whitepaper (coming soon): Designing a LoRaWAN Network for Dense Deployment, https://www.slideshare.net/Actility

[4] Actility webinar slides: Industrial IoT - Transforming businesses today with LoRaWAN, https://www.slideshare.net/Actility/actility-and-factory-systemes-explain-how-iot-is-transforming-industry

[5] Actility webinar : Industrial IoT - Transforming businesses today with LoRaWAN, https://www.youtube.com/watch?v=pRoEbWjffBA

[6] Actility webinar slides: LoRaWAN Roaming Webinar, https://www.slideshare.net/Actility/lorawan-roaming

[7] Actility webinar : LoRaWAN Roaming webinar, https://www.youtube.com/watch?v=tWP6VV1CKEg

[8] Actility webinar slides: Multi-technology IoT Geolocation, https://www.slideshare.net/Actility/multi-technology-geolocation-webinar

[9] Actility webinar : Multi-technology IoT Geolocation, https://www.youtube.com/watch?v=YzFZqMBI2QA

[10] http://vbn.aau.dk/files/236150948/vtcFall2016.pdf

[11] Actility Whitepaper: How to build a multi-technology scalable IoT connectivity Platform, https://www.slideshare.net/Actility/whitepaper-how-to-build-a-mutiltechnology-scalable-iot-connectivity-platform

[12] https://www.orange.com/en/Press-Room/press-releases/press-releases-2018/Nova-Veolia-and-its-subsidiary-Birdz-choose-Orange-Business-Services-to-help-them-digitalize-Veolia-s-remote-water-meter-reading-services-in-France

from My Updates http://blog.3g4g.co.uk/2019/01/the-business-case-of-densifying-lorawan.html

0 notes