I’m currently designing a LoRaWAN network using RAK hardware and have a specific scenario I’d like to get some insights on.
My setup consists of:
A RAK7248 WisGate Developer D4H Gateway (which I understand is an 8-channel gateway).
8 end-nodes, specifically RAK3172 modules.
My goal is to have all 8 RAK3172 nodes successfully uplink their data to the network server at the exact same time (or as close to simultaneously as possible) during a single transmission event/window.
I understand the basics of LoRaWAN’s ALOHA-like channel access, which can lead to collisions. However, with 8 channels available on the RAK7248 for 8 RAK3172 nodes, I’m exploring the practical feasibility of achieving this high degree of concurrency.
Specifically, I’d like to ask:
With the RAK7248 gateway and RAK3172 nodes, is it realistically possible for all 8 devices to achieve a successful uplink at the very same instant, assuming each could potentially use a different channel?
What are the primary factors or challenges that would prevent this (e.g., precise timing synchronization of the RAK3172 transmissions, RAK7248’s internal processing limitations for concurrent packets, unavoidable collisions)?
Are there any specific configurations for the RAK3172 modules (e.g., fixed channel assignment, strategic use of different Spreading Factors via AT commands or custom firmware) or RAK7248 settings that could maximize the probability of all 8 uplinks succeeding nearly simultaneously?
How does the RAK7248 (given its architecture) handle incoming packets that arrive on different channels at virtually the same time? Can it truly process 8 distinct uplinks concurrently if they arrive on separate channels and potentially different SFs?
If perfectly simultaneous uplink isn’t guaranteed, what level of “near-simultaneous” success and reliability can I generally expect with this RAK hardware combination?
Any insights, experiences with similar RAK setups, or best practices you could share regarding this type of scenario would be incredibly helpful!
The LoRaWAN stack is selecting randomly a channel (frequency), you cannot simply force a specific frequency to send. So 8 devices sending simultaneously at the same will most likely lead to failure.
Thank you for your explanation. I understand that perfectly simultaneous uplinks are challenging due to LoRaWAN’s random channel selection, leading to a high probability of collisions if all 8 devices transmit at the exact same moment.
Given this limitation, could you please advise on the optimal approaches or configurations we could implement with our RAK7248 gateway and RAK3172 nodes to achieve the highest possible degree of near-simultaneous successful uplinks?
For instance, are there any specific strategies regarding:
Spreading Factor (SF) allocation across the devices?
Transmission timing strategies (e.g., introducing very slight, controlled delays between transmissions)?
Any gateway-side configurations on the RAK7248 that might help in scenarios with multiple, closely timed incoming packets?
Or perhaps a different way to frame the problem or the definition of “simultaneous” that is more achievable with LoRaWAN?
My goal remains to get data from all 8 nodes processed as close together in time as practically possible during a specific event. Any best practices or further insights you could share to help maximize the success rate in such a scenario would be greatly appreciated
Sorry, I have no advice for your use case. IMHO, it depends on what “near-simultaneous” means. Packets from 8 nodes within 20 seconds? That might be achievable, taking into consideration that an TX/RX1/RX2 cycle will take roughly 2-3 seconds.
Same with beegee, it will depend on what “as practically possible” is acceptable in your use case.
Easiest way to achieve multiple transmission is just have the devices in different spreading factors. Even if they use the same frequency, it will still push thru without collision. If you can utilize SF7 to SF12, that is 6 devices max. Take note that SF12 can take a second or a little more depending on payload size.
If you really need simultaneous for 8 devices, LoRaWAN might not be the best technology considering it was designed for applications that has minutes of interval of sending uplinks.
Thank you all for the valuable insights regarding the challenges of simultaneous uplinks with LoRaWAN. I’d like to clarify my specific use case further, incorporating some of your suggestions and a new approach I’m considering.
My complete system will involve approximately 400 end-nodes. I plan to divide these 400 devices into smaller groups, with each group consisting of roughly 8 devices.
The operational flow would be:
A downlink command/query is sent, intended for all 400 devices (or a significant subset that needs to respond).
Instead of all 400 devices attempting to uplink simultaneously, I want to implement a staggered response mechanism. The groups of 8 devices would be scheduled to respond with a 1-second delay between each group. For example, Group 1 responds, then 1 second later Group 2 responds, and so on.
This leads to my core question, now focused on the intra-group behavior: Within this staggered approach, when it’s a specific group’s “turn” to respond (e.g., Group 1 during its allocated 1-second window), is it feasible for all 8 devices within that single group to successfully uplink their data to the server as simultaneously as possible (or very closely timed)?
Considering the RAK7248 gateway’s 8 channels and the RAK3172 nodes:
Would the strategy of assigning different Spreading Factors (SFs) to the 8 devices within each group be the most effective way to maximize the probability of successful near-simultaneous uplinks for that group?
Given the 1-second window for each group, how critical is the precise “simultaneity” within that window? Would small, unavoidable variations in transmission timing within the group still be manageable for the gateway if different SFs are used?
Are there any other configurations or considerations for the RAK3172 nodes or the RAK7248 gateway that would be particularly beneficial for this “grouped and staggered” uplink scenario, specifically to ensure the reliability of the 8 uplinks from the active group?
My aim is to reduce overall network collision by staggering the groups, but still achieve high reliability for the 8 devices transmitting within their designated group’s timeframe. I appreciate any further advice on optimizing for this specific scenario.
Now it is irrelevant of how you want to argue the point.
The “LNS based on least amount of noise and congestion” assigns channels to nodes (you don’t do it), it is unaware of your groups.
What amount of date do you intend to transfer? LoRaWAN has a very low data transfer rate, 1 sec.
The SF is there to ensure data transfer occurs when the SNR is bad, it is not something you should assign.
Irrelevant what gateway or node are selecting, you need to change your strategy of the tech you are using, LoRaWAN is not designed to do simultaneous uplinks, you are not the first one to try this, there are 100’s of dev that tried this and failed.
Rather describe what you want to do and then we can advise better. What is the job of the nodes.
Thank you for your follow-up questions and the candid feedback. It helps me clarify my requirements and understand the limitations better. Please see my responses below:
LNS (LoRaWAN Network Server): We are using ChirpStack.
Uplink Payload Size: The maximum uplink payload size per device will be 47 bytes.
Description of Node Task and Operational Flow:
Node Function: The nodes serve two primary purposes:
Actuation: They receive downlink commands to turn connected equipment on or off.
Status Reporting: After an actuation or upon request, they send back status parameters of the equipment to the server.
Operational Scenario:
The server sends a control command (downlink) intended for a large set of approximately 400 devices.
The end-devices are pre-configured and logically divided into smaller sub-groups, with each sub-group containing 8 devices.
Crucially, the staggered uplink timing is pre-programmed into the end-devices themselves. When a device receives the common downlink command, it knows which sub-group it belongs to and its designated response delay.
Devices in Group 1 are programmed to attempt their uplink response immediately (or as soon as possible) after receiving the downlink.
Devices in Group 2 are programmed to wait for 1 second after the initial downlink trigger point before attempting their uplink.
Devices in Group 3 are programmed to wait for 2 seconds after the initial downlink trigger point, and so on for subsequent groups.
My core question, therefore, refines to this: Given this pre-programmed staggered response where only one group of 8 devices is intended to be actively trying to uplink within any given ~1-second window (e.g., Group 1 in seconds 0-1, Group 2 in seconds 1-2, etc.), what is the feasibility of those 8 devices within their designated time slot successfully transmitting their 47-byte uplinks?
I understand that ChirpStack will manage channel allocation based on its algorithms for the devices that are actively transmitting. My strategy of pre-programmed staggering on the device side is an attempt to avoid having all 400 devices (or even a large number) contend for channel access at the exact same micro-moment, thereby distributing the load over time.
The desire for the 8 devices within a specific active group to report back “as simultaneously as possible” is because their status is relevant to the command just issued, and we want to gather the responses from that small, active cohort promptly before the next cohort reports.
Given this clarification:
Does this pre-programmed, device-side staggering approach change your perspective on the feasibility or the advice regarding SF allocation (perhaps still relying on ADR, or considering if fixed SFs within a group could be viable if ADR struggles with such closely timed uplinks even from a small batch)?
With a 47-byte payload, what would be the approximate Time on Air for various SFs, and how might that impact the ability of 8 devices within a group to clear their uplinks if they all started transmitting around the beginning of their 1-second designated window?
Thank you again for your expertise and patience as I try to explain this specific scenario.