Simon Elliott and Andrew Murphy (BBC)
For live radio to be streamed without interruption in connected cars, the mobile network delivering the content needs to be consistent and ubiquitous. For media delivery over IP, content providers already log data through their apps to monitor various aspects of performance including the Content Delivery Network (CDN). However, it’s possible to collect additional data to define and measure the Quality of Service (QoS) provided by a mobile connection.
Time to last byte
The mobile network distribution chain sees streamed live audio moving from the origin server through CDNs and the mobile network to the media player app running in the connected car. Streamed audio is generally delivered in segments, using technologies such as MPEG-DASH. These segments are made available at the origin server and the CDN at regular intervals, ready to be requested by the media player and re-assembled into a continuous stream of audio. The time taken for the app to request each segment and receive it in full is known as the Time To Last Byte (TTLB). It can readily be measured at the client by a timer. If any individual segment takes too long to be delivered, there is the risk of an interruption to playback.
Mobile network conditions will inevitably vary, e.g., due to fluctuations in coverage or capacity, and these directly impact the TTLB. To cope, the media player maintains a buffer. If every segment is received in less time than the buffer’s duration, playback remains uninterrupted; exceeding that duration causes dropouts.
Increasing the buffer allows the player to tolerate longer TTLBs without interrupting playback. However, the buffer’s length delays playback relative to live by a commensurate amount of time. The application owner may therefore set the buffer’s length considering this trade-off versus the likely performance of the network.
Crowd-sourced data
An internal prototype app has been implemented to crowd-source data that could be used to define QoS as shown in the graphic below. The TTLBs for each audio segment, along with their corresponding location, could be aggregated into, say, 100x100m square geographical areas, or pixels, for which the statistics could be assessed.
There will be a high probability of unbroken playback if a sufficiently high proportion of TTLBs (e.g., the 99.999th percentile) are shorter than the device buffer length. Pixels meeting such a threshold could be considered covered, while those exceeding the threshold would be deficient.
Mapping the data, pixel by pixel, then reveals the coverage specifically for the service in question, i.e., the service coverage of streamed live radio. Deficiencies in service coverage, or where improvements might be targeted could then be identified. Similarly, common tasks like finding the proportion of roads covered would also be possible.
A wealth of other data, such as mobile signal quality and strength, cell IDs, and the amount of time the app spent playing versus rebuffering can also be collected. This too can be used to find out more about the connection quality and app performance, as well as for troubleshooting.
Importantly, such data and analyses provide content providers with agency. With greater knowledge and information they are better positioned to engage with industry, MNOs and regulators; able to contribute their findings and requirements to any discussions about how well mobile networks might work for their specific services and whether any improvements might be required. Finally, much is in the hands of the app developer to optimize the playback experience specifically for the mobile environment. Data allows the impact of any design changes to be objectively measured.
For more detail on this topic see the BBC R&D White Paper and the recent EBU webinar.
This article first appeared in the March 2026 issue of tech-i magazine.