HIP 48: IP-over-LoRaWAN

[ivelin]

HIP 48: IP-over-LoRaWan

• Author(s): @ivelin
• Start Date: Dec 6, 2021
• Category: Technical, Economic
• Original HIP PR: https://github.com/helium/HIP/pull/320
• Tracking Issue: https://github.com/helium/HIP/issues/319 (this)

Summary

As of Dec 2021, Helium supports only simple Class A broadcast messages under 100 bytes. This is a good start, but without IP support, the use cases are somewhat limited. This proposal begins to describe adding support for IP-over-LoRaWAN to the Helium protocol.

Proposal

Rendered view:

https://github.com/helium/HIP/blob/master/0048-ip-support.md

[synfinatic]

Can you speak to:

• IPv4 or IPv6?
• What about IoT devices which move (roaming)
• Since you mention HTTP, I assume you mean bi-directional traffic. But does this assume that the IoT device is always the initiator of the connection?
• With more complex protocols like HTTP, and the need for security, any concerns regarding the additional costs with not just doing TCP 3 way handshake, but SSL/TLS handshake?

[ivelin]

Good questions, @synfinatic . Please see below:

Can you speak to:

• IPv4 or IPv6?

IPv4 is still more common, but either one would be fine I think.

• What about IoT devices which move (roaming)

I assume these will be better suited for the upcoming 5G upgrade for Helium.

• Since you mention HTTP, I assume you mean bi-directional traffic.

Correct.

But does this assume that the IoT device is always the initiator of the connection?

Yes, but not always. In the ambianic architecture, the edge devices send heartbeat pings to a signaling server that allows the UI app to discover them and establish p2p connection over WebRTC. In this sense the user initiates connection to the edge devices (smart cams) on demand.

Naturally the edge devices also initiate notifications via HTTP/REST or MQTT when an event or object of interest is detected.

• With more complex protocols like HTTP, and the need for security, any concerns regarding the additional costs with not just doing TCP 3 way handshake, but SSL/TLS handshake?

Very good point. We will have to test this to be sure, but nowadays http/s v2 is highly optimized compared to the classic v1. The upcoming http v3 is even more performant in terms of compute and packet efficiency.

[jamiew]

@ivelin this sounds fantastic, would you be willing to write it up into an actual HIP draft? Doesn't need to be complete, but just something using the template so we could number and merge for further discussion

[ivelin]

@ivelin this sounds fantastic, would you be willing to write it up into an actual HIP draft? Doesn't need to be complete, but just something using the template so we could number and merge for further discussion

@jamiew I'd be happy to.

UPDATE: Just found the template: https://github.com/helium/HIP/blob/master/0000-template.md

[ivelin]

Just FYI, I started a related discussion in the ambianic community. There seems to be interest there as well.

The author of this cool Smart Cam for LoRa project which was references in the Helium discord also engaged on this topic and we are meeting on video call later this week to brainstorm.

[ivelin]

@ivelin this sounds fantastic, would you be willing to write it up into an actual HIP draft? Doesn't need to be complete, but just something using the template so we could number and merge for further discussion

OK, I updated the draft to fit the template. Please note that there are still a number of blank areas that need to be discussed and filled in. Happy to brainstorm with anyone interested.

[jamiew]

@ivelin are you comfortable resubmitting this as a PR as a file checked into the repo, per usual process? you seem OK with GitHub but I have a brief writeup here in case helpful.

Basically just need to click "new file" on https://github.com/helium/HIP, write "HIPxx-ip-support.md" and paste what you wrote above

[synfinatic]

I have lots of concerns regarding the vague description of this proposal. At minimum we need to know if we're talking about v4 vs v6 as there are trade-offs. It's also unclear if this is a pure mesh overlay network (where every endpoint needs to be on the Helium network) or we're talking about exposing Helium networked devices to the Internet itself. The latter of course brings with it a whole slew of security concerns- especially since an apparent requirement is that Helium network devices can be "servers" and not just initiators (clients) of connections. Can IoT devices talk to each other, or just well defined static endpoints? Or are these endpoints not static and we need some kind of discovery solution like DNS?

I also, don't understand why roaming would be excluded for the LoRa network and would be a 5G only application? Isn't one of the major advantages of LoRa is its low power requirements which makes it perfect for small devices which can be embedded into virtually anything and go anywhere?

It might be helpful if the author focuses on the specific user stories/use cases for this and why the current protocol is not sufficient to enable certain kinds of devices/value. The example of push notifications from a smart cam seems totally doable with the existing Helium protocol?

Finally, while yes, HTTP/2 is better than the old 1.0, just getting to that point requires 6 packets to even start HTTP over TCP: https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/ That said, QUIC (aka HTTP/3 which happens over UDP) is better, but also far less supported today. This is where understanding the actual use cases would be very helpful to understand if what we really need is "IP" and support random use cases like GRE, ICMP, IGMP, etc over IP or something far more limited/easier to implement.

[ivelin]

@ivelin are you comfortable resubmitting this as a PR as a file checked into the repo, per usual process? you seem OK with GitHub but I have a brief writeup here in case helpful.

Basically just need to click "new file" on https://github.com/helium/HIP, write "HIPxx-ip-support.md" and paste what you wrote above

Done. https://github.com/helium/HIP/pull/320

[wolfenhawke]

I don't see this as tunneling other protocols' continuous traffic via lora (Helium). That would not seem to work for one of the questions posted above even. For instance the WiFi TLS handshake would be too much data and too much delay to succeed using Lora. Instead, I see this as a means to send packets (truly "envelopes") of data on Helium meant for a data lake that is ingesting particular types of traffic. For instance, yes, an MTTQ sensor alarm packet. An HTTP push of sensor alarm data packet. It's not so much IP-over-LoRaWAN but IPPackets-over-LoRaWAN. IPData? IPAlarms? There should be the support of 2-way traffic also. So the twin can trigger a local response from the alarm back at the device sending the data.

[wolfenhawke]

On the question of security. That would be left for a higher stack implementation. For example, the IPData-over-LoRaWAN can be encrypted. Still an n-byte packet, but it could be custom encrypted or pre-shared key (I know, deprecated, but good principal for this) encrypted for the clients data. Even a hash salted via individual device physical security key.

[wolfenhawke]

The real beauty of this is the support of extreme edge as IOT response processing is migrating to from the cloud. Professionally, I am discussing this as cloud workloads are pushing to the edge for much faster response times than directed twins can support. So, a true high traffic intelligent device would be IP connected (wouldn't use this). But a lesser bandwidth - I'm thinking alarm type - could send a (raised hand) signal via Lora. This won't replace the high bandwidth always connected use cases. Idea is to expand their usefulness for otherwise ignored use cases that are enabled by Helium.

[ivelin]

I have lots of concerns regarding the vague description of this proposal.

That's a fair point. I need to dive deeper into the Helium /LoRaWAN stack to be able to add more substantiated comments.

At minimum we need to know if we're talking about v4 vs v6 as there are trade-offs.

Not being an expert on this topic, I would vote for IPv4 given that its ubiquitous and v6 adoption has stalled at 30% or less (in most countries): https://www.arin.net/blog/2019/05/02/economic-factors-affecting-ipv6-deployment/

It's also unclear if this is a pure mesh overlay network (where every endpoint needs to be on the Helium network) or we're talking about exposing Helium networked devices to the Internet itself.

One possible approach could be to upgrade hotspot capabilities and allow hotspots owners to choose an operating mode:

1. LoRaWAN only addressable node. This is the current status from what I understand.
2. LoRaWAN + Private WiFi Router.
   • Allow Helium hotspots to offer local WiFi connectivity (as a WiFi router) to IoT devices (wifi clients) near them.
   • Enable routing of IP traffic from IoT devices to other IP addressable devices on the Helium network.
3. LoRaWAN + Public WiFi Router & Firewall.
   • Same capabilities as LoRaWAN + Private WiFi Router, plus.
   • Ethernet Port to connect to a local Internet router (e.g. over DHCP).
   • Enable IP enabled devices on the Helium network to initiate outbound connections to public IP addresses (e.g. web sites).
   • Implement Full-cone NAT or another STUN compatible NAT scheme that allows secure direct p2p connectivity over WebRTC between Helium IP devices and non-Helium connected endpoints (such as web browser apps or mobile apps).

The WiFi Router capabilities in the latter two schemes can be reused for the Helium 5G upgrade.

It would make sense to adequately incentivize hotspot providers/miners who chose to upgrade to operating mode 2 or 3 with increased added value and assumed risks.

The latter of course brings with it a whole slew of security concerns- especially since an apparent requirement is that Helium network devices can be "servers" and not just initiators (clients) of connections. Can IoT devices talk to each other, or just well defined static endpoints? Or are these endpoints not static and we need some kind of discovery solution like DNS?

Not sure if I answered these questions above.

I also, don't understand why roaming would be excluded for the LoRa network and would be a 5G only application? Isn't one of the major advantages of LoRa is its low power requirements which makes it perfect for small devices which can be embedded into virtually anything and go anywhere?

Good points. I stand corrected.

Roaming is a complex problem that is solved for 5G (as it was solved for any previous mobile network protocol).

After your comment I looked around and found this announcement suggesting that LoRaWAN roaming was introduced earlier in 2021 and is worth exploring further: https://lora-alliance.org/lora-alliance-press-release/lorawan-roaming-now-available-in-more-than-25-countries/

It might be helpful if the author focuses on the specific user stories/use cases for this and why the current protocol is not sufficient to enable certain kinds of devices/value. The example of push notifications from a smart cam seems totally doable with the existing Helium protocol?

A few more use cases suggested on the related ambianic thread: https://github.com/ambianic/ambianic-edge/discussions/405#discussioncomment-1767914

I think the question is not as much about technical feasibility as it is about economics and network effects.

I agree that many use cases can be implemented directly on the LoRaWAN stack. Provided there is a party willing to invest the time and effort to acquire compatible hardware components and the matching software development skills.

The economic reality is that the vast majority of developers are educated to work with IP hardware and software. Respectively tooling and components for IP is abundantly available off the shelf. So are app development skills.

Doesn't it make sense to build a bridge from our island to the mainland?

Here is a related thread on reddit that highlights the issue: https://www.reddit.com/r/IOT/comments/r6pokn/connecting_sensors_to_wifi_router_to_lorawan/

I also pulled up a few charts (shared below) from google trends that roughly show the critical mass of people gravitating around various protocols.

I included SIP (Session Initiation Protocol) in the chart, because it is a telling example of a dominant protocol that was introduced over 20 years ago and now powers 80% of voice calls worldwide. Yet very few developers are comfortable using SIP libraries directly. It was not until the introduction of HTTP APIs (CPaaS) that made Programmable Voice and SMS a common feature set in modern applications.

Finally, while yes, HTTP/2 is better than the old 1.0, just getting to that point requires 6 packets to even start HTTP over TCP: https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/ That said, QUIC (aka HTTP/3 which happens over UDP) is better, but also far less supported today. This is where understanding the actual use cases would be very helpful to understand if what we really need is "IP" and support random use cases like GRE, ICMP, IGMP, etc over IP or something far more limited/easier to implement.

Completely agree! IoT apps over LoRaWAN cannot copy SaaS design templates verbatim. Even if IP becomes available as an option, IoT app developers still have to take into serious consideration the severe limitations of the long range radio bandwidth.

[ivelin]

Came across a few products related to this topic:

2020 Hunting cameras over LoRa with Verizon Cell tower connected base station as Internet gateway to upload photos. https://www.trailcampro.com/products/copy-of-covert-lora-lb-v3-verizon

The Things Indoor LoRaWAN WiFi Gateway - 8 Channel LoRa 900 MHz https://www.adafruit.com/product/4345

NETGEAR 4G LTE Modem (LM1200) – Use LTE as a Primary Internet Connection & Connect to any WiFi router https://www.amazon.com/NETGEAR-LTE-Broadband-Modem-LM1200/dp/B08R813HLW?th=1

[theseusyang]

lora protocol now should not support bi-directional traffic.

[ivelin]

The diagram below is an attempt to clarify the proposal.

The gist of it is that it enables IP IoT devices to participate in the Helium network with minimal friction apart from compliance with the available (and usually very low) bandwidth budget.

Diagram source here.

[vincenzospaghetti]

This HIP has been stale and without discussion for some time. We are going to move to close it. If you would like to reopen this HIP, please submit it as a new PR with changes. Thanks for your contributions to the Helium Community!