Can I use NB-IoT as a backhaul for LoRaWAN?

I see a lot of texts making parallels between LoRaWAN and NB-IoT, with some of those comparing LoRa with NB-IoT. I understand that LoRa is a RF proprietary modulation, it is in the physical layer of the system architecture. NB-IoT cannot be compared to LoRa, as NB-IoT is in a different layer. NB uses some LTE modulation, such as QPSK or BPSK, which can be compared with LoRa.
Even LoRaWAN I do not see, always, as an alternative to NB-IoT, as NB connects to the internet “directly” using cellular network, and LoRaWAN needs some backhaul, for instance LTE, or Satellite to connect to the cloud.
As a consequence, I think NB-IoT much more as a complement to LoRaWAN.
I understand that we can connect some device to the internet using NB-IoT, without using LoRa at all. In this scenario, NB would be an alternative to LoRaWAN. But I also see a scenario where several devices are connected via LoRaWAN to a gateway and this gateway is using NB-IoT as the backhaul to connect to the internet. The problem is that I cannot find any project or article using this combination.
I would like to discuss whether there are some misconceptions in my thoughts! Am I missing some concepts, or misunderstanding some of them?

The key questions would be capacity and latency.

A traditional LoRaWan network requires that information be able to get from the gateway to the server and back in a small fraction of a second, because nodes expect downlink replies to begin exactly one second after the end of an uplink. TTNv3 lengthens that to 5 seconds, but that was mostly to accommodate multi-level infrastructure routing, more than backhaul delay. But if you can get ping times in the 100 ms range it might still be reasonable.

Then there’s the question of capacity, particularly economic capacity. A LoRaWan gateway in a busy location might generate on the order of a gigabyte of traffic a month. In the traditional architecture, gateways know hardly anything about the traffic they are handling - they just blindly pass it on to the server, to use or reject as irrelevant. And since this is the TTN forum, even more than on a private network you really aren’t supposed to be trying to guess the value of traffic at gateway level, but rather you’re expected to pass anything without a link level CRC error on. So apart from latency, the question would be does your service plan make hundreds of megabytes to a gigabyte economical? Or are you better off with a traditional LTE plan?

For a LoRaWAN network devices connect to the network, not the gateway. Only if the gateway implements the other LoRaWAN services as well the device connects to those processes on the gateway.

With regards to using NB-IOT for the back haul, according to GSMA the latency can be several seconds in an area of extended coverage, that makes it unreliable when an uplink and poll for downlink need to be within 5 seconds window.
At the last TTN conference there was a session on using LTE-M for the back haul.

1 Like

Hi Pedro,
NB-IoT would not be the right technology to provide the backhaul for a LoRaWAN gateway. The latency in NB-IoT would prevent the join request/accept process from working, and downlink messages from getting through. Stick with 4G for backhaul.

People do compare NB-IoT and LoRaWAN all the time - they are both in the LPWAN “family” of network technologies along with Sigfox and others. There is quite a bit of overlap in use cases for NB-IoT and LoRaWAN and there are pros and cons to both.

2 Likes

Thanks for the insights about capacity and latency!

Regarding “economic capacity”, I’m more concerned about the range I can achieve using NB-IoT. I’m deploying services in rural areas, where cellular towers are far away… Regular LTE network in my country uses 2.6 and 1.8GHz for 4G and 900 MHz for 2G… Now, the carriers are deploying LTE-M and LTE Cat NB1 at 700 MHz. Here in the rural areas no access to GPRS is common, so I’m hoping these lower frequencies of NB and LTE-M can enhance cell coverage. If cellular is not an option, I have to jump to satellite comm, which is much more expensive.
I am also thinking about designing a “drone gateway”, so I can achieve higher altitudes to get a line of sight to some cell tower or LoRa gateway! have you guys already heard some proposition like that to use as reference?

You mean each device has an independent internet connection? This architecture would be more expensive, as I have to provide a modem, sim card, antenna and service plan to all devices… Or did I get it wrong?

You misunderstood. In LoRaWan gateways provide transparent translation between radio and Internet encapsulation, but they do not meaningfully participate in the LoRaWan protocol, they merely pass the packets through without any understanding of them.

As such a LoRaWan connection exists between the node and the server, not the node and a gateway.

Anyway, your goal doesn’t really seem supported by present practical implementations of LoRaWan - there is talk and theory about how to use various relay technologies other than a traditional low latency Internet connection to get between gateways and the server infrastructure, but at present not really practical support for deploying them, especially not in TTN.

In truly isolated situations you might be able to use a small LoRaWan server running on a gateway’s emebedded computer and passing high latency decoded results up to a cloud aggregator which would also accept data from TTN coverage of other areas. But the private isolated part of such a system would not be TTN, and so would not be on topic here.

1 Like

Did you see my mention of lte-m as a viable solution?

Yes! I saw the video!! But here in my country this technology is still experimental… with one carrier trying it! NB is more advanced here… but I understand the limitations! Will have to work with what is available here… probably using a LoRa transceiver as gateway and developing my data link and network protocol, instead of using LoRaWAN. I don’t have to manage lots of nodes… around 5 or 6 per gateway, so I think it will be ok!!

If you don’t have overlapping coverage between the gateways, then that could well be a use case for running a compact independent LoRaWan network server in each gateway, something many of the gateway vendors offer or which you can DIY.

But once you’re not using TTN it’s not really on topic here, regardless if it’s LoRaWan or some other scheme leveraging LoRa modulation.

Hi pedro. Interesting approach, we use Band 31, LTE and NB, for rural areas. did you solve the puzzle? what country are you from? rgds

Hi Kersing, I am always learning and it is really interesting to read your inputs. I am another guy with the same concern, using NB as Lora Backhaul, Did you practiced it?
I found a gateway that is advertised as a viable solution.

Cheers!

That device can use LoRaWAN as backup. It is not a LoRaWAN gateway.

Hi Mikael, our CloudGate nano is effectively a LoRaWAN gateway that can be used as LoRaWAN forwarder or LoRaWAN server, using either NB-IoT/CatM or Ethernet as cloud connectivity.

1 Like

This is really interesting and usefull device.

Thanks for clarifying. Sorry for misunderstanding. I could not find any information about the LoRaWAN gateway support in the online documentation.