One of the most useful DAB/DMB data-applications is TPEG, the newer and most often much better traffic service compared to TMC.
In-car infotainment systems with TPEG support (for the navigation function) face one problem with the way this data service is signaled by DAB/DMB metadata.
The DAB/DMB meta-data about a service misses the TPEG-SID. There has been a proposal to supply this data within the (normally unused) user-application-data field (of FIG 0/13); unfortunately, no one ever followed this suggestion.
Instead, to know about the TPEG-SID of a DAB/DMB service carrying TPEG, the tuner has to tune to that service and listen to the content for a while, until this TPEG-SID is received.
Why is the TPEG-SID important?
It is not always important. It depends on the way a navigation system decides which TPEG service should be received. If a navigation system has contracts with specific TPEG providers (often paid), they usually select among the receivable TPEG services by means of the TPEG-SID (the navigation system will have built in knowledge about that providers TPEG-SIDs).

Typically, in-car infotainment systems do not have a dedicated DAB tuner device reserved for TPEG. Often, we see a dual tuner setup where one tuner serves the current audio/video source, the other timeslices between band-scan and data service reception (TPEG/EPG).

With the need to tune into each newly receivable DAB/DMB service for TPEG to know about the TPEG-SID, the ‚productive‘ TPEG delivery is interrupted.
Most often the TPEG-SID is found very fast, but often it is not – sometimes providers do not behave well, sometimes reception issues are a cause.

So, the idea is to encode the TPEG-SID within the service-label. This means, the SID can be parsed from DAB metadata directly without the need to tune the ensemble and select the service.

Examples:
Instead of                name it
—————————————————
‚TPEG‘                    ‚TPEG$010203$‘
‚TPEG_MM‘           ‚TPEG_MM$XXXXXX$‘
‚KBS TPEG‘           ‚KBS_TPEG$640301$‘

Everything enclosed by the $ sign is the TPEG-SID encoded as ASCII hex (XXXXXX of course is a placeholder).
It is possible that some dedicated navigation systems use the label to recognize a service.
In that case the DAB provider could signal two DAB services pointing to the very same data source; one service would use the original service-label and DAB service-id, the new one would use the new label. This way we can avoid updating such systems.
This method does not fit directly, should a DAB/DMB service ever carry two or more different TPEG services. However, I have never seen that in the wild.
For such a ‚double service‘ case we could name a service ‚$010203$$010204$‘ to extend this scheme; or we could add additional DAB-services with individual labels, but pointing to the very same data source.
I’m quite sure that this is just another proposal that will never be adopted on a larger scale or even at all by anyone.
However, even a single TPEG provider could introduce this method as an additional way to optimize newer infotainment systems that use its services.
No need to say ‚all or nothing‘.