Can I use a Gateway alternatively as a LoRaWAN node

Hi,
we would like to use a gateway (concentrator) hardware alternatively as a LoRaWAN node. So, depending on the configuration of our system, the gateway would be used as a gateway or as a node. Is this possible?
Thanx
Gerald

Simple answer is no.

Not with the software stacks currently available as far as I know. However, the gateway hardware would certainly be able to function as a node with the right software. Reusing the existing node software wonā€™t work because of the huge differences in hardware used by gateways and nodes.
Attaching a AT command capable module to the gateway (and making sure the receiver hardware is powered down when transmitting with the module to avoid overloading the input circuits of the gateway) is probably the easier and more cost effective solution.

Thatā€™s going to be a pretty expensive end device.

Like many ā€œideasā€ that come up, we can usually make helpful suggestions if we know more about the what & the why of your needs.

Thanx for your immediate answers!
To explain our situation: We will build up a classical star topology where the node devices are doing the measurement tasks and the gateway device will collect and transform the data and then forward it to a server (a non-LoraWAN server). Whenever we prepare our system for a project, weā€™ll need between 3 and 13 nodes, plus 1 gateway. To make assembly, distribution, maintenance and replacement simpler, our philosophy is that the boxes we build (raspberry + sensor + modem) are the same for all devices. So, we build black boxes that may work as nodes or as gateways. Sure, we could integrate a LoraWAN node and a router in all of our devices, seems that this is the only feasible solution.

How will you decrypt the packets, maintain sessions etc etc?

Is that you Elon? Please can you be my client - I love clients that just throw hardware at a problem and by the time youā€™ve finished paying for all those concentrator cards, hopefully you wonā€™t notice that Iā€™ve upgraded my car to an Aston Martin.

If itā€™s not too impertinent question, have you done an IoT or LoRaWAN project before?

Whilst never one to disuade people from using LoRaWAN it may be that its not the technology you need. I have historic clients using LoRa in point to point and point to multi-point star deployments where there are only a few nodes, a single ā€˜gwā€™ and little traffic such that the additional capacity of a multi-channel, multiSF full LoRaWAN system and its associated, sometimes more complex, moving parts isnā€™t actually neededā€¦ more info on traffic/types/message timing etc. might allow for more advice and pointers but then that kind of system woudl be out of scope for the TTN Forum. As the others have pointed out keep the GW as a GW and nodes as nodes if heading down the LoRaWAN path - kitting is then simple enough - there is little to be gained from trying to eliminate just one SKU type from a typical kit deployment and it helps KISS ! :slight_smile: And stops the node costs escalating. Curious as to your node/sensor requirements as RPiā€™s not power consumption friendly or normally 1st choice for low power nodes and low power battery based systems are where LoRaWAN comes into its own and thrives c/w other technologies and potential solutionsā€¦

We appreciate your blunt answers. And we are not ashamed to admit that we are newbies, so obviously.

You are probably right that itā€™s not a good idea to force LoRa-WAN into the given project. Besides the fact that we wonā€™t have more than 12 nodes per installation and besides the node&gateway-in-a-box issue (which might be negotiable with our client), there is still the hard requirement to send the data from the gateway directly to a server of our customer.
In fact, we are building a GNSS measurement system in areas where thereā€™s no cellular network, distances between the receivers are 1ā€¦3 km. Yes, this kind of system does exist off-the-shelf but the system architecture never matches with the requirements of our customer.
As so often, the feasibility of a system is easy as long as you ignore the non-functional requirements.

If using LoRaWAN that involves an LNS somewhere that handles the data and associated registrations and routing and then forwards to the end application and presentation server. Even if the LNS then also resides on the gw. This could be your own TTS instance if appropriate hardware for the Gw is chosen. If no TTS used either as TTS(CE) aka TTN, or on board then that would make this outside scope of this forumā€¦ā€¦ Note also a typical LNS should scale well to handle lots of gws and a great many end devices, committing an LNS per gw is really a waste of resources and effort imho! Though have done it many times for small private deployments.

1 Like

I remember hearing this idea years back: let each gateway send a device packet at some interval, to see if it is received by surrounding gateways. That could be used as a kind of health check and a check of the radio path.

Helium uses a mechanism like to this for ā€œproof-of-coverageā€.

The UDP protocol seems to at least have an ā€œinverse polarityā€ setting, which is one of the things required to change between uplink and downlink transmission: https://github.com/Lora-net/packet_forwarder/blob/master/PROTOCOL.TXT#L364

So, technically a LoRaWAN gateway is probably capable of doing it, but I donā€™t know of a way to do this with TTN.

That just sends a packet but does not handle downlinks, no MAC command processing either. So it is not even close to a LoRaWAN compliant node.