TTN Mapper and how to indicate V2 vs V3 vs Private

[jpmeijers]

Background

Today I had a discussion with the community in Australia, and one of their main concerns is how to distinguish between V2 coverage and V3 coverage on a map. Currently TTN Mapper only shows coverage for the V2 Public Community Network. Another feature request is to indicate which frequency plan a gateway is using (Australia uses both AU915 and AS923).

Current situation

All data that is forwarded to TTN Mapper, via the HTTP Integration on TTN v2 is assumed to be for the Public Community Network.

Currently on TTN Mapper there are 4 colours being used for gateway icons:

• Blue: gateway is online and the coverage is mapped. ie, we have received at least one packet through this gateway, and we can assume the gateway is at this location and working correctly.
• Green: gateway is being reported as online by the network, but no packets have been forwarded to TTN Mapper. We therefore can’t reliably say if this gateway is at its reported location, or if it is working correctly.
• Yellow: Gateway has only been heard on one or two channels. It is assumed to be a single channel gateway.
• Red: Gateway is being reported as last heard more than an hour ago, but less than 5 days ago.

The default coverage layers are blue, but more advanced layers use a rainbow to indicate the signal strength.

How to indicate different networks and frequency plans

On TTN v3 mapping data can come from multiple locations. This includes private hosted clusters, cloud hosted tenants, or the public clusters. In short that is any network that peers using the Packet Broker, or has the TTN Mapper Webhook template enabled.

To make the map user friendly, we need to indicate the network instance, as well as the frequency plan for the gateway and the coverage it is providing. In other words we need to show the public network’s coverage, and public coverage provided by private networks - indicated differently.

This is where I need recommendations from the community. A simple gateway icon colour like for V2 might not be good enough. Does anyone have UI/UX experience and ideas how we can do this?

Data flow V2 vs V3

With the launch of TTN v3, along with the private and hosted instances that potentially will feed data to TTN Mapper, things became a little tricky. On V2 all data was assumed to be for the Public Community Network, because there was no peering. On V3, with the Packet Broker, this assumption can not be made. We therefore need to be able to identify the network instance where the Webhook HTTP POST originated.

Some Github issues around this topic:

Report gateway network

Expose tenant id in webhook template

Tenant ID and Cluster ID in uplink message json

Summary

Please help us to find a good way to indicate different networks and frequency plans on the map.

We are actively working on adding support for V3 to TTN Mapper, but due to some hurdles this is a little tricky.

Any ideas or comments are welcome.

[Uskompuf]

I was thinking maybe you could just display all the data combined in a similar way to what already exists and the just have a drop-down menu to filter by network or frequency plan.

[Jeff-UK]

Hi @jpmeijers can you confirm what happens where a GW does move V2 to V3 (yes I know we are advising GW owners to hold off wholesale moves as yet, however, there is increasingly a need to move some for test purposes, esp where some temporary support for V2 users is or can be backfilled). If I want to ‘loose’ old mapping data then advice is relocate it >100m away from prior location (temoprarily or virtually) forcing old data to be purged & cleared, however, what happens if move isnt in 3D space but rather an existential move to another dimension (i.e. V2 to V3!), whilst keeping to same location (a bit like same space different time!), will historic coverage data be lost? (Fact is whether V2 or V3 the LoRaWAN RF coverage will still be there)

I’m fearfull you will say it gets lost or ages off as GW not seen after several days then removed from map, in which case next question: What are plans to crystalise/capture historic data to re-instate post V3 move…many folk really wont want to go back out and restart mapping all over again from a clean sheet!

What is status on implementing V3 integration project? Any update for the Community…?

In addition and thinking further on this…

What happens where a GW goes offline for any reason - accidental switch off or network disconnect, PSU failure (or lack of thermo-nuclear reactor for solar powered! ) or if backhaul network goes down for several days, such that existing GW ages off the map, but is subsequently re-instated…does historic data get restored & re-rendered or is it lost forever?

[jpmeijers]

Many questions, so let me answer the core ones.

A gateway is uniquely identified by the network id and the gateway id. So there is a TTNv2 gateway with ID eui-0011223344556677, and there is a separate gateway on eu1.thethings.network (V3 eu) with ID eui-0011223344556677. These two are currently handled separately. At some point we can try and find a way to either copy old coverage data over, or merge the two. We can do this because we know TTNv2 and eu1.thethings.network are essentially the same network what coverage is concerned.

Raw coverage data is never deleted. Only aggregated data is hidden from the map when a gateway is offline. At least this is the case for V2. On V3 we do not have a NOC, so the only way to know if a gateway is online or offline is by looking at messages received. To start off we will likely have to assume a V3 gateway is never offline and always show it.

Mapping V3 is already possible using the Android app. It is also possible using a gps tracker and setting up a webhook integration. It’s a little tricky to do, and therefore we need a template. Issue is that the template doesn’t allow optional fields, making the “experiment” option difficult to implement. My plan is to release a template that does not have the experiment option, but one can manually add it by editing the webhook.

Make template fields optional

Edit:
I’ve filed a PR to add the webhook template:

Add TTN Mapper template

[Jeff-UK]

@jpmeijers

On V3 we do not have a NOC

Thanks for the response/update JP. Lack of noc is indeed a problem for all sorts or reasons…it’s been invaluable to users, mods and staff over the years in solving a range of problems and answering a number forum and in use questions. Have asked if each cluster could at least have have a mini-noc… and from there it’s not a big challenge to scrape data and create a global overview noc/dashboard…even if not truly live (though if too far adrift from real time that would diminish value). I guess we just have to hope and wait.

[Uskompuf]

Hey, I see that the GitHub issue mentioned has been resolved, any updates for this?

[jpmeijers]

You will see on https://status.thethings.network/ that the update is scheduled to be deployed on 12 April. Only after that we can see how this was implemented, and add support for the new identifiers on TTN Mapper’s side.