TSP latency reporting

[BenGardiner]

latency of the API instance is very important to carriers. We have heard at least two examples of carriers using TSP-provided timestamps to estimate latencies. In both cases these estimates were for the purposes of measuring the quality of service of a daily basis. To enable this use of latencies we propose to add an endpoint to state of health endpoints.

The alternative is to expose event 'created times' in the data model which would enable carriers to calculate latencies themselves; however, this wouldn't be enough to enable estimates of outbound message latencies. So the additional fields and complexity wouldn't completely satisfy the request.

The new endpoint should report daily summaries; comprised of:

• total numbers of inbound and outbound messages over the 24h period
• total numbers of inbound and outbound messages with latency above 5 minutes
• total numbers of inbound and outbound messages with latency above 10 minutes.

Available only sometime after the 24h period in question.

[BenGardiner]

to account for periods where vehicles are outside the range of service of wireless networks the latency reported should be defined as the delta between a. when the event is available in OTAPI and b. when the event was transmittable due to network availability

[BenGardiner]

there are two distinct cases where latencies are inspected by carriers

• events/objects/logs etc from the vehicle devices to the carriers
• messages from the carrier to drivers, via the TSP

and for different reasons as well. Carrier inspect latencies on messages to drivers to ensure delivery and in many cases also display to the driver (e.g. read receipts). The other object latencies are inspected for the purposes of quality of service.

It is the 'messages to drivers' use case that has been explicitly requested at this time and the 'state of health' endpoints are already in place and meant to serve the purpose for quality of service.