DeviceTimeAns timestamp is not corresponding to the specification

[adriansmares]

Summary

References #2471
References #2478
References #5585

The Network Server should not use the Network Server receive time as a response to DeviceTimeReq, but instead the timestamp of the end of the transmission.

Current Situation

The Network Server received timestamp is used:

lorawan-stack/pkg/networkserver/mac/device_time.go

Lines 34 to 43 in 70d88dd

	func HandleDeviceTimeReq(ctx context.Context, dev *ttnpb.EndDevice, msg *ttnpb.UplinkMessage) (events.Builders, error) {
	ans := &ttnpb.MACCommand_DeviceTimeAns{
	Time: msg.ReceivedAt,
	}
	dev.MacState.QueuedResponses = append(dev.MacState.QueuedResponses, ans.MACCommand())
	return events.Builders{
	EvtReceiveDeviceTimeRequest,
	EvtEnqueueDeviceTimeAnswer.With(events.WithData(ans)),
	}, nil
	}

The standard is both misleading and clear regarding this in both the 1.0.3 and 1.0.4 specification:

I think that #2471 is caused by the phrasing of 'current Network time', but the below sentence (GPS time at the end of the transmission) should be hopefully clearer.

Why do we need this? Who uses it, and when?

We need this for proper class B support.

Proposed Implementation

This requires #5585 first.

I think we need the following fallback system:

1. In the presence of a settings.gps_time field, use that.
2. If not found, walk through the rx_metadata slice and use the first gps_time found.
3. If not found, use the Network Server receive time.

I think that option 2 can become more sophisticated later on, but for now this should suffice.

cc @johanstokking

Edit:
Also https://github.com/TheThingsNetwork/lorawan-stack/pull/2478/files#diff-9ba913e113eb0e0a51b8c6b091c237d7af5d797e29720b3fea84410ece5a99c5L666-L671 should be reverted, as the handler should run after deduplication.

Contributing

• I can help by doing more research.
• I can help by implementing the feature after the proposal above is approved.
• I can help by testing the feature before it's released.

Code of Conduct

• I agree to follow TTN's Community Code of Conduct.

[johanstokking]

I think that #2471 is caused by the phrasing of 'current Network time', but the below sentence (GPS time at the end of the transmission) should be hopefully clearer.

Yes it's confusing but not incorrectly written. Network is everything that is not the end device. And it receives the time indeed from the Network Server, like all frames. But indeed, the wall time is determined at the end of the uplink transmission.

I would suggest:

1. time from RX metadata. There is no GPS time in settings (= TX settings), and if so, it would be the transmission GPS time (so receive GPS time minus time-on-air)
2. received_at determined by Gateway Server (not Network Server). If we have RTT, subtract half of the mean RTT to estimate the time it was received by the gateway. The only thing we don't account for then is the delay by the packet forwarder

[adriansmares]

• time from RX metadata. There is no GPS time in settings (= TX settings), and if so, it would be the transmission GPS time (so receive GPS time minus time-on-air)

• received_at determined by Gateway Server (not Network Server). If we have RTT, subtract half of the mean RTT to estimate the time it was received by the gateway. The only thing we don't account for then is the delay by the packet forwarder

You're going in the right direction with respect to GPS time - I think we should clarify #5585 first before looking at this issue. Mixing GPS and non GPS timestamps is causing problems down the line, and I do think that we should not fall back to approximations if we really have the GPS time available.

Keep in mind that the same frame may be received by multiple gateways, so it becomes confusing to know which time to choose - having a dedicated gps_time would solve a multitude of issues. If I have two RxMetadata, I don't which time or even adjusted-received_at I should trust.

Another thing worth mentioning is that I don't think that the time in the settings (TxSettings) is actually the timestamp at the start of the transmission, but rather at the end of the transmission. My argument is as follows:

1. We don't alter timestamp anywhere in the uplink path of the GS, nor in the NS.
2. When we compute the RX1/RX2 timestamps, we just add the RX delay.
3. Since the RX windows start from the end of the transmission + the RX delay, the timestamp that we have is from the end of the uplink transmission.

From here we can deduce the following:

1. The GPS timestamp in the UDP protocol is at the end of the transmission - notice that we only take the concentrator timestamp there - there is no uplink parameter that would allow the conversion to take into account the time on air.
2. Same in Basic Station - The XTime (concentrator timestamp + session ID) is converted to GPS time without any TOA considerations.

[johanstokking]

Keep in mind that the same frame may be received by multiple gateways, so it becomes confusing to know which time to choose - having a dedicated gps_time would solve a multitude of issues. If I have two RxMetadata, I don't which time or even adjusted-received_at I should trust.

What to do with multiple gps_times?

---

We just need the GPS time at the end of the transmission, right? So gateways can determine this with NTP or GPS. If they can't, GS does it for them but then we can subtract half of the known RTT. If we don't know the RTT, fine, we use GS clock.

---

This is the updated text from the yet unreleased LoRaWAN Backend Interfaces 1.2:

Information Element	Generated by	Carried over fNS-sNS interface	Carried over sNS-hNS interface	Description/notes
RecvTime	fNS	Yes	Yes	Timestamp of the end of packet arrival reception (GPS time with 1sec precision). Generated by the NS controlling the receiving GW.

So here, Backend Interfaces says that it is the NS (in TTS: GS) that determines the time. This obviously assumes negligible latency between gateway and GS. I'm fine with that as well.

So maybe we should just stick to GS provided time, not override it in NS, and not bother with gateway's absolute time, be it GPS or NTP or something else?

[adriansmares]

What to do with multiple gps_times?

The expectation here is that they are all equivalent with millisecond precision.

We just need the GPS time at the end of the transmission, right? So gateways can determine this with NTP or GPS. If they can't, GS does it for them but then we can subtract half of the known RTT. If we don't know the RTT, fine, we use GS clock.

But the NS has to somehow know which timestamp to pick. If we put this fallback mechanism at GS level, and just say 'use time', we're not solving the issue - if we have 2 times, which one do you put in DeviceTimeAns ?

Take the following two gateways that share the same room - any uplink sent is going to be visible by both gateways:
https://tti.staging1.cloud.thethings.industries/console/gateways/ttkg-adrian-1/data
https://tti.staging1.cloud.thethings.industries/console/gateways/multitech-adrian-2/data

The ttkg-adrian-1 will have record time with second accuracy (the MQTT v2 protocol receives a Unix timestamp without a fractional part), while the multitech-adrian-2 will record time with microsecond accuracy (time in BasicStation is based on gpstime when gpstime is available - see this and this).

If an uplink arrives via these two gateways, and it contains a DeviceTimeReq, I should receive in DeviceTimeAns the time of multitech-adrian-2, not the one of ttkg-adrian-1.

This is the updated text from the yet unreleased LoRaWAN Backend Interfaces 1.2:

I think that the two specs (L2 1.0.4 vs BI 1.2) have been developed independently, or at least there is so little use of class B that no one actually cares.

In the L2 1.0.4 specification we have the following text:

Why do we have the 8 bit fractional part if we're just going to put a non-fractional RecvTime there ? The 8 bit fraction will always be zero via BI.

Below we have an even stronger requirement:

We cannot use RecvTime (with second accuracy) as a response to DeviceTimeReq as it won't have 100ms accuracy. We should always respond with a GPS timestamp (tmms / gpstime) when available, or with a round-trip-adjusted timestamp.

---

As a general remark about BI 1.2 I think that the specification should separate between a timestamp that is provided for debugging reasons only (and may come from NTP) from a real GPS timestamp (that can be used for DeviceTimeAns).

[johanstokking]

But the NS has to somehow know which timestamp to pick. If we put this fallback mechanism at GS level, and just say 'use time', we're not solving the issue - if we have 2 times, which one do you put in DeviceTimeAns ?

The one where we know is GPS. If we don't know for sure it's GPS time in the MQTT V2 protocol, then we don't consider that GPS time. Otherwise it's GS observed received_at.

---

Why do we have the 8 bit fractional part if we're just going to put a non-fractional RecvTime there ? The 8 bit fraction will always be zero via BI.

Yep, RecvTime needs to get the fraction too.

---

As a general remark about BI 1.2 I think that the specification should separate between a timestamp that is provided for debugging reasons only (and may come from NTP) from a real GPS timestamp (that can be used for DeviceTimeAns).

Why?

RecvTime should just be what it is: the GPS time at the end of transmission. If it can be observed by the gateway, use the gateway GPS time, otherwise the server time. I don't really care what the NTP time is of a gateway in another network.

[adriansmares]

Why?

Settled offline - we will interpret the specification requirement of +-100 ms error as being present only if a GPS-enabled gateway is available. Otherwise it is technically impossible to have a bound on the time error, and the server time will suffice.

---

Tasks to do here:

• In HandleDeviceTimeReq the timestamp which we will attempt to use is as follows:
  • The first non-nil gps_time that is available in the uplink metadata.
  • The first non-nil received_at that is available in the uplink metadata.
  • If all else fails, use the top level received_at of the uplink.
• Revert the change that made the MAC handler run before the deduplication occured.
  • The original code can be found here.
  • I expect that it doesn't compile anymore in that form, but you can see how this was done for the LinkCheck command here.

This PR depends on #5585, so start with that.

cc @happyRip