Upload
margaret-lynch
View
223
Download
1
Tags:
Embed Size (px)
Citation preview
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?