Jani PousiSupervisor: Jukka Manner

Espoo, 11.02.2015

ContentsBackgroundResearch problemProposed methodsTestingResultsConclusionsFuture studies

Why is this needed?The used bitrate is negotiated when creating

the conferenceDecision is based on current state of the network

A change in network conditions can either worsen or improve the situationConference 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 networksMobile networks have properties that can

cause significant network changes in a short time period

Problem causes:Interference from other signal sourcesSignal weakening due to distance or obstaclesBandwidth sharing

Latency is higher than in fixed networksRealtime applications are more sensitive to

problems

Research problemThis 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 detectionECN (Explicit Congestion Notification)

Has to be supported by network elementsChanges in the RTT (Round-trip time)

calculated from the RTCP (Real Time Control Protocol) report dataReport send interval varies between client

implementations (10 ms – 5 s)Changes in the inter-arrival time of video

framesPacket loss

AdaptationMRFP capabilities

Bitrate changeFramerate change

NegotiationThe studied node was unable to renegotiate

conference parametersThe 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) systemClients were running on two PCs connected

to the environmentNetwork congestion was simulated by placing

a Linux laptop between one PC and the rest of the networkThe server manipulated the amount of

available bandwidthBackground traffic with UDP

Test setup (2/2)

Test implementationSteps:

1. Start background traffic and a conference2. Drop available bandwidth3. Restore bandwidth after 20 seconds

Run tests: RTT monitoring Frame inter-arrival monitoring Both of the above together

Both bitrate and framerate adaptation was triedBandwidth 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 signsThe 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

combinedThe methods mostly got in each others wayThe 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 comparedFramerate adaptation failed to activate

Probably due to a software bug

ConclusionsThe proposed methods could be used to detect

building congestion with some modificationsThe 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 clientsServer can notify the client of detected uplink

congestion and vice versa

Further studiesHow 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?