This is more of a conceptual question if this would actually be possible with the lmic library.
My plan is to subdivide a LoRaWAN end device into multiple “virtual devices”, which act completely independet from each other. Each virtual device has its own device address nwskey and appskey, but they all share the same transciever.
I would use ABP because I dont think this would be possible with JOIN (or its easier with ABP). I also use class a, because large downlink windows would interfere.
In my specific use case i will have three different systems. Each system should be handled as a single LoRaWAN device, but they share the same transciever (HopeRF RFM95c).
For each system, a seperate application server exists.
lets say my three virtual devices would have following apb credentials:
My plan is to save the uplink payloads from the connected systems in a buffer on the microcontroller that implements the library. Then it would cycle through the registered virural devices and set the session with the given abp credentials (with LMIC_setSession).
The corresponding payload that is saved in the buffer for the current device would then be sent off to it’s application server and the downlink window stays open for a response (which is also written to a buffer). This process repeats infinitely for all virtual devices.
The systems could then access the buffer to recieve their downlink payload.
Would this be a viable solution for “splitting” a single transciever into multiple LoRaWAN devices?
ABP or OTAA would both be possible and in both cases you need to save the stack state.
I don’t understand your remark regarding downlink windows. Care to explain?
Keep in mind an active LoRaWAN session has more information. Up- and downlink counters, power settings, frequency settings, data rate used among others. All those need to be stored for each virtual device.
Keep in mind legal airtime limits apply to the transmitter, not the virtual device.
My first instinct would be to try to actually run multiple copies of a LoRaWAN stack, with a a locking scheme were one owns the hardware from the preparation to transmit through to the end of receiving or the second empty RX window.
But MCCI LMiC did recently get an ability to save its (allegedly complete) context as a blob of data (for processors which loose state when asleep) so if that completely works, it might be possible to use it to swap things out.
Keep in mind legal airtime limits apply to the transmitter, not the virtual device.
Indeed, this is where things would get harder, because the airtime tracking both overall and per channel, needs to be shared.
In theory if one were aware of the internal details of LMIC’s save blob, it might be possible to share some of the fields related to RF regulations while keeping others related to LoRaWAN state distinct.
What’s missing so far in this proposal is the why? What would be the benefit? I can think of some ideas that might be barely valid, but others that would not. What’s the goal here?
To simply separate information flows, put each on it’s own fport of the same device. Having multiple virtual devices won’t get you anything better than that for airtime allowance, actually less, as the occasional bits of network-level traffic would have to be done for each individually.
This! / These! Using a port for each of your “virtual” devices would allow you to differentiate between each device - maybe not redirect them to different end points, but the end points can all be run in parallel (via web hooks or MQTT) and drop any irrelevant uplinks. Bit messy, but …
Subverting any of the LoRaWAN MACs to make them schizophrenic is a whole package of work - it would be almost infinitely easier if you gave us the why. Then we could make some informed contributions.
An ESP32 will handle the lmic stuff in combination with hosting a web server.
It contains a web interface which allows the management and creation of these virtual devices, which will later correspond to a connected Wifi device.
(The ESP32 also creates an access point)
The connected Wifi devices are now able to interface with a http rest API on the ESP, allowing payloads to be stored and retrieved.
The goal is to connect WiFi based devices (like other microcontrollers) to the lorawan network over this ESP32. It is important that every WiFi device has their own application server.
This whole thing is only a rough idea as of right now. It is only for evaluating the possibility of this route.
The application server is an adjunct to the Network Server - your scheme presupposes that it has to communicate with different LoRaWAN networks which has all sorts of potential issues with coverage and so forth.
Whereas a single set of credentials can be used to enable routing via your endpoint (MQTT or webhook) without warping time, space & the LMCI firmware.
You do understand LoRaWAN is a low bandwidth, low capacity network? And when using the community network you are limited to 30 seconds airtime for uplinks and 10 downlinks?
And when using other LoRaWAN networks your radio at least need to observe legal limits but if you don’t want to be considered an noisy neighbor you still should transmit rarely? (And too many noisy neighbors will render LoRaWAN unusable for anyone for many miles around that location due to LoRa being long range)
So write a little bit of custom backend logic on the infrastructure side to route uplinks to these different sub-application consumers based on the LoRaWAN fport, and to assign that fport if they try to inject downlinks back into the LoRaWAN part.
But overall, your scheme strongly suggests intended usage likely to drastically exceed airtime limits (nevermind TTN usage policy) for a single radio.
Or else a lot of your clients are going to be getting back post responses on the order of “thanks, message queued for transmission, behind 15 others, expected transmit time about 3 hours from now, use this token if you’d like to cancel that”
This isn’t a place to play traffic aggregator - in reality, the LoRaWAN air link is the narrow capacity chokepoint in the system diagram of just about anything that makes use of it.