Jani Pousi Supervisor: Jukka Manner Espoo,

Contents Background Research problem Proposed methods Testing Results Conclusions Future studies

Why is this needed? The used bitrate is negotiated when creating the conference Decision is based on current state of the network A change in network conditions can either worsen or improve the situation Conference calls require realtime communication so problems have an immediate effect on quality Dynamic bitrate adaptation of the video streams adapts the conference to the new network conditions

Mobile networks Mobile networks have properties that can cause significant network changes in a short time period Problem causes: Interference from other signal sources Signal weakening due to distance or obstacles Bandwidth sharing Latency is higher than in fixed networks Realtime applications are more sensitive to problems

Research problem This study focused on the Ericsson implementation of the MRFP (Media Resource Function Processor) node (conference server) Questions: How can the conference server use existing information to detect network problems? How and when should the video streams be modified by the server? How should the bitrate adaptation be coordinated with the conference clients?

Problem detection ECN (Explicit Congestion Notification) Has to be supported by network elements Changes in the RTT (Round-trip time) calculated from the RTCP (Real Time Control Protocol) report data Report send interval varies between client implementations (10 ms – 5 s) Changes in the inter-arrival time of video frames Packet loss

Adaptation MRFP capabilities Bitrate change Framerate change

Negotiation The studied node was unable to renegotiate conference parameters The only option was to modify the video streams directly without notifying the clients

Test setup (1/2) Simulated environment with a real MRF (Media Resource Function) system Clients were running on two PCs connected to the environment Network congestion was simulated by placing a Linux laptop between one PC and the rest of the network The server manipulated the amount of available bandwidth Background traffic with UDP

Test setup (2/2)

Test implementation Steps: 1. Start background traffic and a conference 2. Drop available bandwidth 3. Restore bandwidth after 20 seconds Run tests: RTT monitoring Frame inter-arrival monitoring Both of the above together Both bitrate and framerate adaptation was tried Bandwidth was limited in the uplink, downlink and both directions in separate tests

Results (1/6) RTT monitoring Implementation did not work as intended Reacted when it shouldn’t and sometimes missed the congestion signs The data shows that the method could work with some modifications Congestion evident regardless of which direction is congested

Results (2/6)

Results (3/6) Video frame inter-arrival time monitoring Implementation had many problems Samples had a lot of variance which confused the algorithm Detected problems are in the client’s uplink side Adapting the downlink side might not be helping at all Method might still be usable with modifications Congestion can be seen in the data when the uplink direction of the client is congested

Results (4/6)

Results (5/6) RTT and frame inter-arrival methods combined The methods mostly got in each others way The combination might however be beneficial Would help discern the direction of the congestion with the RTT method If the client sends too few RTCP reports, the frame inter- arrival method could work as a backup

Results (6/6) Bitrate and framerate adaptation could not be compared Framerate adaptation failed to activate Probably due to a software bug

Conclusions The proposed methods could be used to detect building congestion with some modifications The best result can be achieved by combining them Instead of the samples, the adaptation algorithm could track changes in the average value A communication channel should be created between the server and the clients Server can notify the client of detected uplink congestion and vice versa

Further studies How can the congestion detection algorithms be optimized? What should be changed in the video streams? How could the communication channel between the client and the server be implemented? Does ECN and the packet loss method work as intended?

Questions?