Broadpeak and Orange, unlocking seamless video experiences in challenging network conditions 

The widespread adoption of video (and audio) streaming over the past 15 years, at the expense of older broadcasting technologies (terrestrial digital TV, satellite, cable, and even IPTV), has brought numerous benefits to users. It’s now common, for example, to watch TV on a tablet or smartphone, and to access features like pause live, startover (restart a program from the beginning), catch up TV, and more.

This rise of streaming has been accompanied over the same period by the widespread deployment of 4G and then 5G, with more recent phenomena like the success, in many countries, of fixed wireless access (FWA) offers using 4G and 5G networks.

Despite the power and capacity of 4G/5G on one hand, and the adaptability of video streaming – also known as Adaptive Bit Rate (ABR) – to network fluctuations on the other hand, there are still situations – though infrequent and often very temporary – where network conditions are difficult. Neither 5G nor ABR are enough to compensate for these issues (congestion, too poor coverage, excessive interference level reducing useful capacity).

The effects of these problematic network conditions on streaming quality are immediate: pixelization, image freezes (also called stalls), well-known loading wheel appearing on screen to indicate the video buffer is refilling, and incessant changes in video image quality.

Addressing network challenges with Quality on Demand API

Broadpeak and Orange have started to collaborate to address these issues, and using the Quality on Demand (QoD) Network API seemed a perfect fit to remedy these situations.

The integration with Orange QoD API was straightforward: 

• We downloaded the QoD network API on Orange Developer; this API is based on the recent version from Linux Foundation CAMARA project,
• We made test API calls to ensure the functional workflow,
• We integrated Orange QoD network API into Broadpeak’s streaming server.

One of the challenges in API integration is to obtain the device identifier for API calls (NB. this challenge is experienced with other Linux Foundation CAMARA APIs that require device identifier). In our case, we used public IP address of the mobile terminal as the device identifier.

Testbed set up in Orange Lab 

The workflow runs as follows: 

1. Mobile user A has a streaming session with Broadpeak streaming server by regularly sending GET requests including CMCD (Common Media Client Data) information (e.g., buffer length, segment duration, etc.) to receive media manifest/segments. 

NOTE: When the streaming session is stable after a few seconds, congestion is generated by launching large file downloads from other mobile users. 

2. When the GET requests from the user A arrive at Broadpeak streaming server, the server continuously checks and decides whether to ask for or release the bandwidth boost for user A by analyzing CMCD information. 

2′. If the requested content isn’t cached in Broadpeak streaming server, the latter fetches the content from Broadpeak origin server and caches it. 

3. If the Broadpeak streaming server decides to ask for a bandwidth boost, it sends the QoD POST request (/sessions) to Orange Developer that then asks Orange 5G Core Network to handle the request. Broadpeak streaming server stores the sessionId in the response from Orange Developer to use it later. When Broadpeak streaming server decides to release the bandwidth boost for the user A, it sends a QoD DELETE request (/sessions/{sessionId}) so that Orange Developer knows which QoD request should be released. 

4. The request for bandwidth boost is then applied or cancelled for user A. 

5. When the streaming session ends, the video player on user A sends the streaming session statistics (e.g., number of stalls, total stall time, average bitrate, etc.) to Broadpeak analytics server. 

* The QoD network API was used, as its name suggests, only temporarily, when the situation required it. Another strategy (not presented here) was also tested, which consisted of not releasing the QoD API once it was activated. In that case, the improvement is greater, but this strategy goes against our goal, which is to provide a smooth streaming service for the greatest number of people without penalizing other services or favoring certain users. 

One of the challenges we faced was to congest the radio cells in the lab. By definition, 5G networks have enormous capacity. For our experiment, however, we needed low bandwidth to create the problematic situations we aimed to solve. 

In our initial tests, streaming worked perfectly, both with and without the help of QoD, because the radio cell had “too much” capacity available for the test devices. 

We finally implemented the following set up to limit the capacity of the lab’s 5G network and successfully trigger calls to the QoD network API: 

• We limited the 5G network to a single radio cell
• We significantly increased the video bitrates, with ABR profiles of 3.7Mbps, 5.3Mbps, and 7.2Mbps. 
• We started downloading large files on one and then two devices. 

Results: improving streaming under pressure

Our test campaign, conducted on 3.5-minute video samples, gave the following results. 

The three main video quality of experience (QoE) indicators were significantly improved, with a marginal compromise on the average video bitrate. The combination of Broadpeak’s streaming server’s Bandwidth Boost Intelligence feature with Orange’s QoD network API proved its effectiveness in improving video streaming on 4G/5G.