LoRa P2P + LoRaWAN communication in one module

WisBlock
1

I hope this message finds you well.

I am currently working with the RAK3172 module and exploring the possibility of establishing both LoRa P2P and LoRaWAN communication simultaneously. My goal is to dynamically switch between the two modes based on serial input—sending 1 to switch to LoRaWAN mode and 0 to switch to LoRa P2P mode.

While I understand the basic differences between the two protocols, I have a few specific doubts:

  1. LoRaWAN Mode: I am aware that LoRaWAN supports confirmed packet transmission, where the sender receives an acknowledgment upon successful delivery.
  2. LoRa P2P TX Mode: In contrast, LoRa P2P transmission only confirms that the packet was sent (TX done), without any acknowledgment from the receiver.
  3. LoRa P2P RX and Gateway Communication: My main concern is regarding LoRa P2P reception. Is it possible for a LoRa P2P RX node to send data to a LoRaWAN gateway? If not directly, are there any recommended approaches or workarounds to achieve gateway integration from a P2P RX node?

I would greatly appreciate any guidance, documentation, or examples you could share to help clarify this setup and its limitations.

Thank you for your time and support.

2

Is there any Arduino RUI API related to the send confirmed packet in LoRa P2P communication

3

Hi @Khalid1999 ,

Interesting project. With regards to LoRa P2P RX node (or any LoRa node), they can send data to LoRaWAN gateway then to LoRaWAN Network Server but you need to have the MAC layer associated on in. Else, the gateway will just demodulate those signals but it will be meaningless once it goes to the LNS.

I do not have any examples on this switching mode - LoRa and LoRaWAN. But shouldn’t be impossible to do. That note that you have to reset the device to switch mode so unless you are in ABP, you have to rejoin everytime.

There is no RUI API that have that kind of confirmed behavior for LoRa P2P. You can implement your own protocol though.

4

Hello, @carlrowan

I hope you’re doing well.

I’m currently working on a LoRa-based communication setup and would appreciate your guidance on the next step in my implementation.

Here’s the scenario:

  • I have a LoRa P2P TX node that successfully transmits data packets.
  • These packets are correctly received by a LoRa P2P RX node.
  • Now, I would like to forward the received data from the RX node to a LoRaWAN gateway or directly to a LoRa Network Server (LNS).

Could you please advise on the best approach to achieve this? Specifically, I’m looking to understand:

  1. Whether the RX node can be configured to act as a LoRaWAN end device after receiving P2P packets.
  2. If a hybrid setup is feasible—where the RX node receives data via P2P and then forwards it via LoRaWAN uplink.
  3. Any recommended hardware or firmware configurations to enable this transition from P2P to LoRaWAN.

Your insights would be extremely helpful in guiding the next phase of this integration.

5

Hi @Khalid1999 ,

I’ve never done this combination mode but it should be feasible.

If cost, power consumption and board space is not an issue, it will be best if your RX node will have another LoRa module that will act as the LoRaWAN node.

RX NODE
Module 1 (LoRa P2P) ↔ Module 2 (LoRaWAN)

This way you can have a system, that works independently.

If you really need just one to use just one module for both modes, this will be the flow I can think of.

  1. Module will work as LoRa P2P RX Node by default.
  2. It will receive a LoRa packet from TX node.
  3. It will switch to LoRaWAN. This will require reset.
  4. Join the network or use ABP to skip this re-joining process since it is not good for LoRaWAN network.
  5. Send the payload to Gateway.
  6. Return back to LoRa P2P as RX Node. This will require reset as well.

Some considerations will be,

  • If you are in LoRaWAN mode, you cannot received any packets from TX Node.
  • You have to store the payload to a non-volatile memory. Maybe external flash or eeprom (with high read-write cycle). So that if you reset, you can still retrieve them then forward to LoRaWAN.
  • You have also have to keep track on what mode the module should be because if the module resets, it has no idea what mode it should be. You can have something like on-going mode flag variable stored in NVM to keep track on what mode the module must be.
  • Perform reliability testing for the module that continuously resets. I have encountered a customer that had issues before with continuous reset behavior.