Sort out message updates between services
As per the TMC specs, message updates between services are only possible where any station carrying that service has indicated this in a Variant 9 tuning information. (All other tuning information variants refer to the same service.)
This is because the authors of the spec assumed that a receiver would rely on Other Network information for retuning. This would confine the receiver to a group of mutually updateable services and exclude all others, unless the receiver moves to an area where none of the referenced networks are available—which is the only case in which the spec provides for a full scan.
In practice, however, it is possible to pick up multiple services which have overlapping competence areas but do not reference each other, and get the same message twice—once from each service.
It would be desirable to de-duplicate these messages. This could be achieved by allowing updates between services.
On the other hand, allowing updates between random services could lead to “update wars” of the following kind if different services send different messages for the same location:
- Service TMC-A reports queuing traffic at location 42, extent 1, positive direction.
- Service TMC-B reports stationary traffic at location 42, extent 2, positive direction.
Since both messages share the same update class, location and direction and are both dynamic, they would update each other back and forth as the receiver alternates between stations. Or consider a scenario in which one service still broadcasts an event for a particular location while the other is already broadcasting a cancellation.
Deduplication between services therefore needs to be worked out in detail.