Gateway on GSM for mobile devices

1

Hi everyone,

First of all, I’ve been reading this post and this other one. The former one much more interesting to my purpose.

The idea is to design a PoC, for an industrial application (telemetry of some elements in train coaches) So I was looking for an outdoor gateway and I found this article from Ahoysys, which brings me into some confusion.

As I understood all of this is that LoRa is the physical wireless link between nodes and gateways, then LoRaWAN introduces a TCP/IP link between gateways and some concentration server (as TTN, I guess). At this respect, the second post from this forum I linked confirms my understanding of the differences between both (LoRa and LoRaWAN).

However, the Ahoysys article confuses me. Is there some chance to just use LoRa? I guess in this case I won’t need TTN, but… Why according to Ahoysys … “If you put a GSM sim-card in our LoRa gateway, this gateway will create a local LoRa network spreading over 1 square kilometer.”

As you can infer from the short description of the PoC I made, probably, the gateway installed at some point of the train will be able to forward node data to some server (TTN (?)) through GSM, that’s why I was looking for Gateways with some GSM module.

As we are currently using ThingsBoard as data manager/viewer … and it allows TTN integration I think the most proper way is to use LoRaWAN (TTN Open-Source version for now) … but I’m confused about the possibility of just using LoRa and connect directly with ThingsBoard.

Also … I’m not sure what gateway model would be more suitable for this. I’ve been checking also pygate hat (from pycom) which apparently has a socket to plug also a GSM module … But I’m not sure what’s actually this intended for, is this used to design your own gateway? I don’t think this is suitable for an industrial application but maybe for a PoC is enough.

So … may you recommend me some apropriate Gateway (most for production, because for the PoC I’d say I might use any basic gateway). Also … I’m guessing there is some kind of universality between gateways and LoRaWAN but I’m not sure if this is in that way, I mean … are all gateways by design able to use the LoRaWAN protocol?

Thank you very much!

2

Mobile TTN Gateways are not encouraged, they are distruptive to static nodes within reach;

1 Like
3

Unfortunately not - best to read the official documentation rather than topics that someone else dumped their thoughts on the matter - Learn link at the top of this page leads to: https://www.thethingsnetwork.org/docs/lorawan/

LoRa is a radio signal format with a bit of protocol. LoRaWAN turns the signal in to an agreed format with message control & encryption and more. Once the electromagnetic radiation (LoRa) from the device hits a LoRaWAN gateway’s antenna, the gateway does no more than check the CRC (in the LoRaWAN packet) and if it’s OK, it then forwards, without any other decision making, to the Network Server - using UDP or TCP/IP depending on the gateway software, but it could be carrier pigeon, the backhaul is largely irrelevant but is time sensitive which leads to your application.

Trains go through tunnels. GSM/LTE does not. So your mobile gateway, that can cause havoc to shared networks but could potentially work on a private / closed network, will be challenged to ensure it can contact the central server.

There is no store & forward options for LoRaWAN so that’s not a discussion (because there is no spec for it and there are parts of the security in the spec that would make it very very difficult to get around). There are gateways that can act as a Network Server but all the devices will need registering on it for the train it is on, so swapping carriages/trucks would be a logistic nightmare.

By looking at gateway that happens to have GSM, you are about to derail yourself, there are many GSM/LTE based gateway, any box that says it is a LoRaWAN gateway is interoperable with any LoRaWAN device as long as they meet the specs, but the existence of a potential gateway doesn’t make it a workable solution. So I’d strongly urge you to learn LoRaWAN 101 from the link above before getting invested in a brand.

There is the potential to use LoRa point to point (aka P2P) with a central box on the train that receives the uplinks, which is off topic for this forum, or if it turns out that the data doesn’t have to arrive on a fixed schedule (which seems likely, nothing should normally be on the tracks that can’t last until the next station), have powered Class C devices and gateways at the station.

Regarding your “can’t post” comment on the other thread, If I search for “mobile gateways” I get a selection of topics to read …

As your query is about your application and not a theoretical discussion on LoRa vs LoRaWAN I’ve adjusted the title accordingly.

1 Like
4

Thank you for answering!

I’m sorry if I didn’t set a proper title for my question. For sure the article you linked will clarify these differences, I’ll take a read of it :wink:

So … If I’ve understood this properly, as Mobile gateways are discouraged … The most proper architecture would be something like

node_1 ... node_n -> (LoRa P2P) -> concentration node -> (LoRa) -> stationary gateway in some train station -> (LoRaWAN) -> TTN

Right? May you recommend me a specific forum to treat properly the LoRa P2P part?

Thank you very much! :blush:

5

I dont know of one really, Semtech have a developers forum, but they dont often answer questions in there.

There is the Arduino forums, but this does sound like a professional project, so perhaps taking advice in a hobby forum is not so good an idea.

Your getting into an area of maybe needing to employ someone experienced in the field to advise.

1 Like
6

Be careful how you use and interpet the Ahoysys article (remember their positioning of LoRa vs LoRaWAN is skewed by the fact they want to sell you something! :wink: ) as you may find yourself on the wrong track ('scuse the pun!). I have worked with LoRa for near 10 years and (what became) LoRaWAN for over 7 and, whilst I am a fan of both in the right context, the reality is that both implementations (Proprietary LoRa/P2P LoRa & LoRaWAN) run in to the same global and local regulatory limits for any given frequency band wrt data use from RF airtime perspective. LoRaWAN is a predefined standard that addresses many (if not all and some may argue imperfectly) of the system implementation issues you need to consider when defining and implementing your own LoRa based system and architecture. It does this at the cost of some message overhead (~13Bytes) and with some operating rules to ensure good operating practice and device interoperation, but it takes care of a number of issues you need to consider in a LoRa only instance. What is payload/structure/encoding mechanism, how are messages handled/validated, how do you descriminate foreign/alien LoRa (or LoRaWAN) transmissions you nodes and GWs may hear, how do you ensure message security - at the network (node/gw/server) level or indeed at the application (sensors/processing/conditioning - node/gw/server - application/payload decoder) level? Etc. P2P ok for node to node, P2MP ok for small star connected small qty of nodes/gw…but doesnt scale up well or use scarce RF resources efficiently once you start to scale beyond a single small instance. Most Rail based systems I have observed around the globe use static GW’s deployed at a (reasonably regular where practical) distance along the approximate route of the track (even allowing then for deployments inside tunnels addressing a concern raised above! - and using techniques also used in extactive industries like deep shaft mining etc.), Mobile GW’s can and have been used, but should not really be applied on TTN for reasons explained…use on a private instance is more practical but your application and use case must allow for potential (significant) gaps in delivered data…just in last few days a train got stuck in the Channel Tunnel for many hours causing significant travel disruption and in that instance - if there were LoRa nodes on board (there are when I use it! :wink: ) and if no tunnel deployed GW’s or mobile GW’s that were enabled to use in the limited in tunnel 3G/4G network (only partial coverage during a journey) - then data would be lost…

Think carefully how you address this requirement and take professional advice from those who know something of real world LoRa/LoRaWAN deployments… you may need to engage consulting services…and put hand in pocket…

1 Like
7

To re-iterate what has been said about P2P LoRa.

A LoRa device is simply a radio device that sends packets of data. Sure there are comms settings needed for the configuration which impact the distances that can be achieved and the air time used. LoRa can be fast when need be too.

So the design of a LoRa P2P setup for a moving train has very little to do with LoRa as such, its to do with how you use the packet of data bytes to manage the nodes and the collection of data.

1 Like
8

Obviously, I’ve been always refering to a private TTN instance. So I guess discouragement of using mobile gw doesn’t apply for a private TTN instance, am I right?

That was the PoC I was considering, to acquire some GSM + LoRa gateway and check if I’m able to retrieve data from some node in a private TTN instance while moving both (node and gw). As I’d use this private TTN instance, I wouldn’t need to take care of those implementation issues that @Jeff-UK pointed.

About the point of lossing data … for sure a mobile gw won’t be as reliable as setting gateways along the tracks, but it will be also cheaper if data losses are tolerable; as this is a PoC and it’s not actually a project, I might tackle this point in the future, the point of this PoC is indeed that, to test and check in different scenarios/use cases.

So … just to summarize … Would be then suitable a mobile GW always you use it withina private TTN instance?

9

If running a private instance you could go the whole hog and run the LoRaWAN server on the GW (TTS or Chirpstack or whatever) as well and then just use the GSM/Cellular connection to access remotely to pull down data as and when connection allows - all this gets well away from TTN however :wink:

1 Like
10

Obviously???

Sure, go mobile gateway with a private instance - but LoRaWAN needs response times that are often incompatible with mobile comms - a static gateway on GSM/LTE hasn’t got to switch between towers at speed. So you will certainly will lose some data.

I do IoT systems - I wouldn’t use LoRaWAN on a long moving vehicle - in fact the first thing I’d try is something very cheap & off the shelf just to figure out the RF penetration given that the central data collection receiver may be at the front, sticking an antenna out has all sorts of potential for it being a very temporary fixture and without something sticking up, I’d have to wonder how the devices will get a signal through, even if they can have a sticky up antenna that will be snapped off very quickly by environmental or human input.

So once I’d tried on a stationary train when I can try all sorts radio tests, then I’d look at the technology.

Please note, we are all volunteers answering questions, so please don’t expect too much enthusiasm for questions that have bypassed some technical smoke tests. But most of all, none of us can agree on the exact range of LoRaWAN on a good day, so it’s deeply unlikely you’ll get a :+1: to any marginal application of the tech here - the final responsibility rests with you. If it’s a proper project, you should have the funds to go and buy something and try it out on exactly that basis …

1 Like
11

Sorry for assuming this :disappointed: I’ve just realized I’ve been using whole the time TTN when I should have used TTS :blush:

Well, may you suggest some alternative? (I know this is probably off-topic, but right now I’m curious about your point of avoiding LoRaWAN in this use case). As you are pointing to the protocol (LoRaWAN) what about the physical layer? Would you use LoRa at least?

Some specific recomendation about one of this devices? (prolly also off-topic :disappointed:)

Sure … and you are providing me very useful info :blush:

12

The forum will be very reluctant to give you advice on LoRa in general for your non-TTN application, Mr Google has a long memory …

1 Like
13

Not here as the forum is TTN/I/S only and the topic & your use case have enough complications that free advice is worth exactly the amount of paper it is written on or some other aphorism.

1 Like