Audio Video Bandwidth Management

Abstract:

Introduction
Deployment of high speed internet infrastructure is growing drastically and encouraging the people to
communicate through Voice and Video over IP (VVoIP) calls that support smart features such as
messaging, chat, video share etc. Along with audio call, V.VoIP allows Video when bandwidth
availability in the internet is sufficiently high enough. In the long distance calls or calls through different
network channels or infrastructure, the quality may degrade and may not support video calls if there is a
throughput (bandwidth availability) limitation in some part of the network connection. Similarly, client
side network congestion and varying network characteristics may limit provision for the video call.
Following few scenarios analyze the VVoIP call quality variation in real life cases
a) In Mobile networks: V.VoIP calls are more frequently used with the mobile networks. If the
V.VoIP calls are made using the mobile networks, the network bandwidth available will be
varying based on the number of users within the cell radius. Also, the network bandwidth
available will be varying if the person using the V.VoIP calls is driving and moving from one cell
network to other cell network. In case of 3G with good signal strength, the network bandwidth
may be sufficient to have a normal VVoIP call with ~100-150kbps for video stream and 3040kbps for audio stream. But, if one of the parties uses a 2G network, the bandwidth capability
will be of just 20-30kbps, which may just, be sufficient for the audio calls. In this case, making a

This document contains confidential and competition sensitive information. The information contained within
should not be reproduced or redistributed without prior written consent from HelloSoft Inc or HelloSoft India Pvt.
Ltd.
HelloSoft Inc, 2099 Gateway Place, Suite #200 San Jose, CA 95110. USA Telephone (408)441 7110

Hello AV-BWM
Design Document

video call leads to queueing up the packets in the network interface that will eventually increase
the end to end delay of the call, which may be annoying to the user.
b) In Wi-Fi networks: Even though internet service providers (ISP) are providing a huge internet
bandwidth (~100 mbps), it gets shared among huge number of people in the office environment
or apartments or hostels or restaurants etc. The bandwidth available for the users gets fluctuated
based on the number of users and usage in uplink and downlink. If any of the users make a
VVoIP calls in this situation, the call quality depends on the amount of the bandwidth available
for that particular user. If any of the users who has low throughput makes a VVoIP call, there is a
chance of call quality degradation in the form of increased end to end delay, which may be
troublesome to the user.
All the above real use scenarios may cause the variation in the call quality and in fact may not resume to
good quality even after bandwidth availability is recovered enough if proper action is not taken during
bandwidth crisis. The client should be able to handle the fluctuations in the bandwidth availability to
sustain the call during bandwidth crises. So, there is a need for an algorithm to dynamically check the
bandwidth availability in the network and control or manage the video bandwidth usage during low
bandwidth conditions.
[Video Bandwidth usage]
Video has provision for various codecs that has high dynamic range of bit rate usage. The video
bandwidth usage depends on the video codec bit rate and number of frames per second configuration.
For different frames per second configuration the video bandwidth usage can vary from 32kbps to
500kbps for different video codec bit rate.
The audio bandwidth usage depends on the audio codec bit rate and the packet size configuration. For a
variable bit rate codec like OPUS WB, the bit rate range used for VoIP calls is 6kbps to 30kbps. The
RTP overhead bandwidth usage for packet size configuration of 20ms to 100ms in audio calls varies
from 3kbps to 32kbps. So, the total audio bandwidth usage may vary from 10kbps to 64kbps for packet
size of 20ms to 100ms with voice activity detector enabled. As the RTP overhead consumes considerable
bandwidth, adjustment of the audio bandwidth is done by increasing the packet size during the
bandwidth crisis. If the bandwidth crisis continues even after the audio configuration uses the maximum
possible packet size, the bandwidth adjustment is done by switching to lower bit rate of the codec.

Version: 1.0

Imagination Technologies Ltd. Confidential

Hello AV-BWM
Design Document

During bandwidth crisis, bandwidth adjustment is done in video bandwidth usage as a) the dynamic
range is high in case of video codecs, any bandwidth adjustment in the video bandwidth wont be
perceivable by the remote party, and b) any bandwidth adjustment in the audio bandwidth usage may
show up impact on the audio quality that is easily perceivable by the remote party. So, any degradation
in network characteristics is first adjusted by reducing the video bandwidth consumption or switching
off the video before adjusting the audio bandwidth consumption. The audio bandwidth consumption is
adjusted once the video is switched off by increasing the packet size first and then followed by switching
to lower bit rates of the codec.
The proposed algorithm adjusts the video bandwidth usage during the bandwidth crisis. If the bandwidth
crisis continues even after the video is switched off, the bandwidth adjustment is done in the audio
bandwidth usage. During the sufficient bandwidth conditions, the audio quality is improved first until it
reaches the best possible quality. If there is sufficient bandwidth even after the audio call reaches the
best possible configuration, the video is switched on and video quality is improved by increasing the
video codec bit rate.
The method dynamically detects the quality degradation and manages the audio video bandwidth usage.
A Bandwidth Factor (BWF) is proposed that relates quality degradation with the network bandwidth
availability during bandwidth crisis. In this case BWF is used for estimating the bandwidth overload and
reduce the video bandwidth usage by overloaded bandwidth.
The BWF also indicates the bandwidth availability when the bandwidth utilization by the client is less
than the actual network bandwidth. But in this case the actual amount of bandwidth available is not
estimated. To estimate the available bandwidth audio probing of 100kbps is carried out followed by
increasing the video bandwidth usage by 64kbps upon successful completion of probing. This act is
continued as long as BWF is within the expected range of network degradation.
So in this case the bandwidth availability is estimated in multiple sequences by audio probing of 100
kbps and increases the video bandwidth by 64 kbps if the probing is successful.
During low bandwidth conditions the degradation in the quality is to be dynamically detected and video
bandwidth usage is to be limited to sustain the VVoIP call. Also during good network conditions, the
bandwidth availability in the network is to be estimated and audio quality followed by video quality is to
be restored to the best possible level. The available bandwidth can be measured using probing and if the
network characteristics does not degrade even after repeated probing for a specified duration of time, the

Version: 1.0

Imagination Technologies Ltd. Confidential

Hello AV-BWM
Design Document

probing is stopped and the call quality is increased by distributing the probing bandwidth to audio or
video or both the configurations to next higher bit rates.

Version: 1.0

Imagination Technologies Ltd. Confidential

Hello AV-BWM
Design Document

Proposed Method

Video Engine
Bandwidth usage
by Video Stream
Video
Start
Network
Statistics

Bandwidth Factor
Estimation

Scheduling
State
Estimator

Video
Stop

Scheduling
Algorithms

Video BW

Bandwidth usage
by Audio Stream
Voice Engine
Figure 1. High level design of the proposed method
The proposed method estimates bandwidth factor from the network statistics. The bandwidth factor is
inversely proportional to the network characteristics i.e. a lower value of the BWF indicates the call
quality degradation due to network bandwidth is less and thus sufficient bandwidth is available to further
improve the call quality. A higher value of the BWF indicates the call quality degradation due to network
bandwidth is more and action needs to be taken to control the bandwidth utilization by the client before
the call quality completely degrades and further call cant be sustained. Based on the BWF the network
is classified into one of the GOOD State or BAD State or NORMAL State. The GOOD state represents
no quality degradation due to network bandwidth and so bandwidth utilization can be increased to
improve the call quality further. This is carried out by Release Scheduling algorithm. Similarly BAD
state represents call quality degradation due to the insufficient bandwidth and needs an immediate attack
on the bandwidth utilization which is carried out by Attack Scheduling algorithm. The scheduling
algorithms provide the control commands such as starting or resuming the video packet flow, stopping
or pausing the video packet flow, increase and decrease the video bandwidth utilization to video engine.

Version: 1.0

Imagination Technologies Ltd. Confidential

Hello AV-BWM
Design Document

Figure 1 provides the high level design of the proposed method.

2.1 Bandwidth Factor: Bandwidth factor ( BWF (n) ) : It is a sum of weighted statistics parameters
such as network round trip delay, network packet loss, network jitter, burst loss count and max packet
reception gap. The weightage factors are experimentally arrived for discriminating the bandwidth status
of the network, i.e. BWF (n) sensitive to the network performance change due to bandwidth variation
only. If the bandwidth is stable but packet loss or jitter is caused due to some other reason, BWF will not
be varying. The range of BWF is 0 to 10. A lower value of BWF indicates call quality is good. A higher
value of BWF indicates the higher degradation in the call quality due to insufficient network bandwidth
or congestion. The BWF (n) is given as
k
BWF (n) W P (n)
i i
i0
where
k number of metrics
Wi weighting factor of i th metric
Pi (n) Quantized value of i th metric
n measurement index
Different metrics and their weighting factor are provided in Table 1.
Metric
Quantized Network
Round trip Delay
Quantized max
packet reception gap
Quantized Network
Packet loss
Quantized Network
Jitter
Quantized Burst Loss
Count

Symbol

Table 1
Description

AV-BWM BWF metrics

Weightage

P0

Quantized Maximum Network Round trip delay

Factor Wi
0.7

P1

obtained from RTCP report

Quantized Maximum number of continuous play

0.1

P2

request obtained after last RTP packet received

Quantized Maximum network percentage packet

0.05

P3

loss obtained from RTCP report

Quantized Maximum network jitter obtained from

0.1

P4

RTCP report
Quantized Maximum number of continuous loss

0.05

packets played by jitter buffer

If the bandwidth available is less than the bandwidth utilization by the client, then the RTP packets gets
queued up in the network driver interface. This will eventually increase the end to end delay. So, end to

Version: 1.0

Imagination Technologies Ltd. Confidential

Hello AV-BWM
Design Document

end delay is one of the major factors for estimating the BWF. The queued up packets gets cleared once
the network interface buffer is full. The clearing of the packets may be in terms of a) dropping all the
overloaded packets in the network interface buffer and thus may result in the bursty packet loss, b)
occasionally dropping the overloaded network interface buffer, thus resulting in packet loss, c) clearing
the complete buffer at once and start queueing up the buffer from the start, thus resulting in both burst
packet loss and reception gap. So to precisely estimate the network characteristics and know about the
available bandwidth, these network statistics are to be used.
Figure 2 illustrate the increment in the round trip delay between two Android devices that uses 500kbps
uplink bandwidth even though the downlink capability is only 240kbps. The packets gets queued up in
the network interface and results in the increased round trip delay.
[TBD Figure showing the jitter importance in BWF].

Figure 2. Round trip delay between two Android devices when the uplink bandwidth is much
more than the downlink capability
Figure 3 illustrate the burst packet loss count between two Android devices that uses 500kbps uplink
bandwidth even though the downlink capability is only 240kbps.

Version: 1.0

Imagination Technologies Ltd. Confidential

Hello AV-BWM
Design Document

Figure 3. Burst packet loss count between two Android devices when the uplink bandwidth is
much more than the downlink capability
Figure 4 illustrate the RTP reception gap between two Android devices that uses 500kbps uplink
bandwidth even though the downlink capability is only 240kbps.

Figure 4. RTP reception gap between two Android devices when the uplink bandwidth is much
more than the downlink capability
2.2 Scheduling State Estimation: Based on the BWF (n) , the network state is classified into one of the
3 scheduling states viz. GOOD state, BAD state and NORMAL state. For every play request obtained,

Version: 1.0

Imagination Technologies Ltd. Confidential

Hello AV-BWM
Design Document

the BWF (n) is measured and compared with a pre-defined threshold BWFT for estimating the
scheduling state. If the BWF (n) is very low (< 1), the network state is classified to be GOOD state and
sufficient bandwidth is present to further improve the call quality. If the BWF (n) is high (> 2), the
network state is classified as BAD state and it indicates that the network degradation is more and
immediate action is to be taken to improve the call quality. If the BWF (n) is between 1 and 2, the
network state is classified as NORMAL state and it indicates that the call quality is optimal. So no
operation will be carried out in this state. Based on this scheduling state, the scheduling algorithm is
selected to either attack or release the bandwidth.
2.3 Scheduling Algorithms: Scheduling algorithms contains the selection of the Release Scheduler
algorithm or Attack Scheduler algorithm based on the scheduling states. The Release scheduler
algorithm is invoked during the GOOD state and it checks if any additional bandwidth is available by
probing. If additional bandwidth is available, the release scheduler algorithm will invoke audio
bandwidth management to improve the audio quality. If the audio quality is already at the max possible
quality level, the release scheduler will invoke the video bandwidth management to either resume video
call in case of video paused condition or increase the video bandwidth by the given probing bandwidth.
The Attack scheduler algorithm is invoked during the BAD state. It estimates the overload bandwidth
utilization from the BWF (n) and invokes the video bandwidth management to reduce the bandwidth
utilization by the overload bandwidth. If the bandwidth utilization available for the video management is
less than the min bandwidth needed for the video, then the video is paused.

Version: 1.0

Imagination Technologies Ltd. Confidential

Hello AV-BWM
Design Document

Scheduling
Algorithm
GOOD State

BAD State
Scheduling Algorithm

Scheduling Algorithm for

for N/W BW

increase in N/W BW

deficiency (Attack

availability (Release

Scheduler)

Scheduler)
NORMAL State
Network Stable
(No Operation)

Figure 5. High level design of the selection of Scheduling algorithm in the proposed method
The above figure provides the high level classification of the network to one of the states and selection
of the one of the 3 scheduling algorithms.
2.3.1. Attack Scheduler State
In attack scheduler, probing is stopped if any probing is in progress, as in many cases the degradation in
network condition may be only less and stopping the unwanted probing will restore the network to
normal or good condition. If there is no probing in progress, video bandwidth is reduced to stop the
degradation of the network. This is done by estimating the overloaded BW from the BWF and triggering
the video engine to reduce the bandwidth utilization by this overloaded BW. If the available video
bandwidth after reducing the video bandwidth by overloaded bandwidth is less than the minimum video
bandwidth allowed, video is paused. Audio BW management will trace the network conditions and
restore or resume the video packets flow once the network is stable enough to handle both audio and
video packets flow.
Following are the algorithm steps for the attack scheduler state.
Step 1: If the probing is in progress, stop probing and reset the MinProbe kbps to default value. Update
the firing time for next probing as below.

Version: 1.0

Imagination Technologies Ltd. Confidential

10

Hello AV-BWM
Design Document

FT * T
If no probing is in progress, go to Step 2.
Step 2: Verify for Video Stream presence. If no video stream, go to Audio BW management. If video
stream is present, go to Step 3.
Step 3: If the video bandwidth utilization is more than the allocated video bandwidth, then go to Step 4.
Else go to Step 5
Step 4: increment the video bandwidth command ignored count (VBCI) by 1. If the VBCI is more than
the pre-defined value MAX_IGRD, then pause the video. Else go to Step 5.
Step 5: Estimate the overloaded BW as below and go to Step 6
video _ bw * BWF
MAX _ BWF
Step 6: Reduce the video BW utilization or pause the video as below based on the ovrld _ bw
ovrld _ bw

tmp _ bw _ diff video _ bw ovrld _ bw

if (tmp _ bw _ dif MIN _ VDO _ BW )
PauseVideo
else
Switch Video to use " tmp _ bw _ dif " bandwidth configuration

Version: 1.0

Imagination Technologies Ltd. Confidential

11

Hello AV-BWM
Design Document

Attack Scheduler State

Probing is
in
progress?
?

Yes
Stop Probing

Increment by Update
Firing time (FT)

No

No

Video is
ON??

Trigger Audio BW
management

Yes

Allocate
d VBW <
Video
BW

Yes

Video
Bandwidth CMD
ignored++
(VBCI)

VBCI >
MAX_IG
R??
No

Yes

Pause
Video

Yes
Estimate BW
overload

Video BW
>
Overload
BW

Yes

Reduce video BW by
Overload BW

No
Pause
Video

Process Next
Statistics

Figure 6. Flow of the attack scheduler algorithm in the proposed method

Version: 1.0

Imagination Technologies Ltd. Confidential

12

Hello AV-BWM
Design Document

2.3.2. Release Scheduler State

In release scheduler, the audio and video quality can be improved by switching to higher bit rate
configurations. First priority is given to audio to increase to the highest possible quality configuration.
The highest possible configuration refers to the best audio codec negotiated, highest bitrate of the codec
that is negotiated with the negotiated packet size. Once the audio reaches the best possible configuration,
probing is carried out for verifying the sustainability of the network for increased bandwidth. If the
probing is successful then probing is stopped and corresponding bandwidth is used for either switching
on the video or increasing the bandwidth usage by the corresponding value.
Following are the algorithmic steps for the release scheduler state.
Step 1: If the Audio BW management has adapted to the max or the best quality configuration, then go to
Step 2. Or else adapt the Audio configuration as per the audio BW management steps
Step 2: Increment the probing wait time (PT) by the measurement duration. Go to Step 3.
Step 3: If the probing wait time has reached the firing time ( FT ), start or continue probing with
MinProbe kbps.

Step 4: If the PT is greater than probing stable duration time ( PDT ), go to Step 5. Else go to next
statistics.
Step 5: If video is ON, increment the video BW utilization by MinProbe kbps and increment MinProbe
kbps as below. Else if video is OFF, switch on the Video with MinProbe kbps.
if (VIDEO _ IS _ ON )
IncrementVideo BW utilization by MinV kbps
else
Switch ON Video with MinV kbps
MinProbe MinProbe MIN _ INCR _ VAL
Default / Initialization Values in Scheduling Algorithms
Variable
Default/Initialization Values
MinV
64 kbps

1
0.3

6 secs
T
MAX _ BWF
10
MIN _ VDO _ BW
64 kbps
MIN _ INCR _ VAL
32kbps
6 secs
PDT

Version: 1.0

Imagination Technologies Ltd. Confidential

13

Hello AV-BWM
Design Document

Release Scheduler State

Audio
adapted to
Max
quality?

No

Trigger Audio BW
Management

Reset

Yes
Increment Probe time
(PT) by measurement
interval

PT >=
FT?

No

Process Next
Statistics

Yes
B
Figure 7. Flow of the Release scheduler algorithm in the proposed method part 1

Version: 1.0

Imagination Technologies Ltd. Confidential

14

Hello AV-BWM
Design Document

Start or continue to
probe by MinProb
kbps

PT >=
FT +
PDT?

No

Process Next
Statistics

Yes

Increment Video
BW by MinProb
kbps

Yes

Video
is ON?
No
Start Video
with MinProb
BW

Figure 8. Flow of the Release scheduler algorithm in the proposed method part 2
Switching between Start-Probing and Stop-Probing
If the bandwidth available is just sufficient for the audio and video configuration being used, then any
probing being done may degrade the network characteristics. This will be observed in the form of
switching between II.Step 3 and I. Step 1. To reduce the frequent switches between these two states, a
Switching control algorithm is implemented as below.
Stop probing command or Step 1 is followed by incrementing the Firing duration for next probing by
amount. The firing wait time ( FT ) is thus updated as follows

FT * T
This will make sure that there is no frequent switching between the two states.

Version: 1.0

Imagination Technologies Ltd. Confidential

15

Hello AV-BWM
Design Document

Optional Handing over of the probing to Video Engine

After the Release Scheduler, continuous probing by Audio and providing the corresponding available
BW value to VideoEngine is not desirable as the network is overloaded with unwanted data packets. So
in this case, once the audio probing reaches MAX_AUDIO_PROBE_BW, the probing by audio can be
stopped and video can start probing. Following steps provide the details of handing over the probing to
VideoEngine
Step 1: If the Audio Probing is ON, go to Step 2. Else exit
Step 2: Verify if the past K network states are Release Scheduler State or not. If yes, go to Step 3.
Else exit.
Step 3: Compare the Video BW consumption with MAX_AUDIO_PROBE_BW and hand over the
probing to Video engine if the following condition is satisfied
if ( MAX _ AUDIO _ PROBE _ BW VIDEO _ BW _ USAGE )
Handover the probing toVideo
else
continue
Default / Initialization Values in Scheduling Algorithms
Variable
Default/Initialization Values
MAX _ AUDIO _ PROBE _ BW
256 kbps
3
K
Audio BW management: Enhanced Voice Quality Management (EVQM), IMA01-100481GB patent
documentation.

Version: 1.0

Imagination Technologies Ltd. Confidential

16

Hello AV-BWM
Design Document

Test Set-up and Test Results

Testing is carried out between two android mobiles with VoIP engine running on them under isolated
private network using NistNet network simulator for simulating different network scenarios. Below table
provides the details of the network conditions simulated for testing. Audio Video calls of ~10 minutes
are made between the two mobiles. Bandwidth utilization and commands to video engine from audio
engine are used for the performance evaluation. One of the devices (DUT R) is fixed. This Device is
called reference and is common for all test cases. Other end is connected to an access point which can
be used to connect any of the Wi-Fi enabled or Wi-Max enabled or Ethernet devices. Since both
transmission and reception RTP packet streams from the devices go through NIST NET gateway,
bandwidth availability, jitter and other network parameters of the network route can be controlled by the
simulator.

DUT
DUT AA
R
R Enabled)
DUT
DUT BB (Wi-fi
(Wi-fi
Enabled)

Isolated
Isolated
Private
Private

DUT
DUT R
R

LAN
LAN

RR
RR

DUT
DUT C
C (Wi-max
(Wi-max
Enabled)
Enabled)

Figure 9. Test set up

Case
1

Test Duration (in mins)

7

Test case simulated*

No Impairments

10

3-7mins packet loss of 10%

15

3-10mins jitter of 100ms

Version: 1.0

Imagination Technologies Ltd. Confidential

17

Hello AV-BWM
Design Document

10

3-7mins bandwidth limited to 1Mbps

3-5mins bandwidth limited to 200kbps

1-3mins bandwidth limited to 200kbps

10

3-7mins bandwidth limited to 1Mbps with packet loss of 10%

8
9
10

4
4
4

1-4mins bandwidth limited to 1Mbps with packet loss of 15%

1-4mins bandwidth limited to 20kbps
1-4mins bandwidth limited to 50kbps

11

10

3-7mins bandwidth limited to 1Mbps with packet loss of 30% and

network jitter of 200ms

* Default network conditions (if not given in table) are bandwidth limitation of 3Mbps, 0% packet loss
and 0ms network jitter

3000

Allotted BW

Video Stop/Pause

Total BW Usage

Instant of Increase BW

Bandwidth Factor

Instant of Decrease BW

Video Start/Resume
2500

2000

1500

1000

500

0.2

0.4

0.6

0.8

1
1.2
Play Event count

1.4

1.6

1.8

2
4
x 10

Figure 10. Audio Video bandwidth management for case 1

1. It takes ~180secs for reaching the best quality video of ~600kbps. After 600kbps, video
bandwidth does not change.
2. Occasionally BWF is observed to be going above 200. This is due to the delay spikes in the
network interface or network drivers of the Android mobile. Even though occasional spikes
are observed, the algorithm succeeds in continuing the Audio and Video call.

Version: 1.0

Imagination Technologies Ltd. Confidential

18

Hello AV-BWM
Design Document

3000

Allotted BW

Video Stop/Pause

Total BW Usage

Instant of Increase BW

Bandwidth Factor

Instant of Decrease BW

Video Start/Resume
2500

2000

1500

1000

500

0.5

1.5
Play Event count

2.5

x 10

Figure 11. Audio Video bandwidth management for case 2

1. After 3mins the bandwidth utilization is increased due to the packet loss mitigation
2. After 7mins as there is no packet loss, the bandwidth utilization is observed to be getting
steadied back to ~600kbps

3000

Allotted BW

Video Stop/Pause

Total BW Usage

Instant of Increase BW

Bandwidth Factor

Instant of Decrease BW

Video Start/Resume
2500

2000

1500

1000

500

0.5

1.5
Play Event count

2.5

3
4
x 10

Figure 12. Audio Video bandwidth management for case 3

1. After 3mins the bandwidth utilization is increased due to the network jitter
2. After 7mins as there is no jitter and the bandwidth utilization is observed to be getting
steadied back to ~600kbps

Version: 1.0

Imagination Technologies Ltd. Confidential

19

Hello AV-BWM
Design Document

3000

Allotted BW

Video Stop/Pause

Total BW Usage

Instant of Increase BW

Bandwidth Factor

Instant of Decrease BW

Video Start/Resume
2500

2000

1500

1000

500

0.5

1.5
Play Event count

2.5

x 10

Figure 13. Audio Video bandwidth management for case 4

1. Max Video bandwidth usage is ~600 kbps. So any increment given after 600kbps does not
get reflected in total BW usage.

3000

Allotted BW

Video Stop/Pause

Total BW Usage

Instant of Increase BW

Bandwidth Factor

Instant of Decrease BW

Video Start/Resume
2500

2000

1500

1000

500

0.2

0.4

0.6

0.8

1
1.2
Play Event count

1.4

1.6

1.8

x 10

Figure 14. Audio Video bandwidth management for case 5

1. As the bandwidth usage at around 3mins is ~600kbps, sudden drop in bandwidth available to
200kbps queues up the packets in the network. This causes increase in BWF and switches off
the video packet flow. Once the network is cleaned up, Video Start/Resume is given at
around 6mins.

Version: 1.0

Imagination Technologies Ltd. Confidential

20

Hello AV-BWM
Design Document
800
700

Allotted BW

Video Stop/Pause

Total BW Usage

Instant of Increase BW

Bandwidth Factor

Instant of Decrease BW

Video Start/Resume
600
500
400
300
200
100

1000

2000

3000

4000
5000
Play Event count

6000

7000

8000

9000

Figure 15. Audio Video bandwidth management for case 6

1. BWF is observed to be increasing as and when bandwidth utilization is increasing due to
probing.
2. Video is always OFF in this case, due to non-steadiness of the network.

3000

Allotted BW

Video Stop/Pause

Total BW Usage

Instant of Increase BW

Bandwidth Factor

Instant of Decrease BW

Video Start/Resume
2500

2000

1500

1000

500

0.5

1.5
Play Event count

2.5

x 10

Figure 16. Audio Video bandwidth management for case 7

1. After 3mins the bandwidth utilization is increased due to the packet loss mitigation
2. After 7mins as there is no packet loss, the bandwidth utilization is observed to be getting
steadied back to ~600kbps

Version: 1.0

Imagination Technologies Ltd. Confidential

21

Hello AV-BWM
Design Document
1400

1200

Allotted BW

Video Stop/Pause

Total BW Usage

Instant of Increase BW

Bandwidth Factor

Instant of Decrease BW

Video Start/Resume
1000

800

600

400

200

2000

4000

6000
Play Event count

8000

10000

12000

Figure 17. Audio Video bandwidth management for case 8

1. Bandwidth usage is steadily increasing upto ~600 kbps.
1400

1200

Allotted BW

Video Stop/Pause

Total BW Usage

Instant of Increase BW

Bandwidth Factor

Instant of Decrease BW

Video Start/Resume
1000

800

600

400

200

2000

4000

6000
Play Event count

8000

10000

12000

Figure 18. Audio Video bandwidth management for case 9

1. As the bandwidth available is only 20kbps, the BWF is increasing in the call startup and thus
not allowing the video to be switched on.

Version: 1.0

Imagination Technologies Ltd. Confidential

22

Hello AV-BWM
Design Document
1400

1200

Allotted BW

Video Stop/Pause

Total BW Usage

Instant of Increase BW

Bandwidth Factor

Instant of Decrease BW

Video Start/Resume
1000

800

600

400

200

2000

4000

6000
Play Event count

8000

10000

12000

Figure 19. Audio Video bandwidth management for case 10

1. The video gets started at ~6secs. Once the video is switched ON, the BWF is increased
drastically and switches off the video

3000

Allotted BW

Video Stop/Pause

Total BW Usage

Instant of Increase BW

Bandwidth Factor

Instant of Decrease BW

Video Start/Resume
2500

2000

1500

1000

500

0.5

1.5
Play Event count

2.5

x 10

Figure 20. Audio Video bandwidth management for case 11

Observations:
1. The video start time is observed to be ~6secs for the cases where the network bandwidth
available is sufficiently high for both audio and video call.

Version: 1.0

Imagination Technologies Ltd. Confidential

23

Hello AV-BWM
Design Document

2. The total bandwidth usage (both by audio and video) is always less than the total available
bandwidth
3. With deficiency in bandwidth, bandwidth factor is increased and triggers to use lower video
bandwidth.
4. For the calls that has initial low bandwidth availability (case 9, case 10), video start wont be
triggered as the bandwidth is not sufficient for sustaining the video calls. For remaining cases, as
the initial bandwidth is sufficient for sustaining the video call, video packet flow is enabled at
~6secs.
5. With increase in packet loss, the increment in audio bandwidth utilization is very less as
compared with the expected increment in the audio bandwidth for the given packet loss. This is
because of the audio probing that can be used for restoring the lost packets from the network.

Version: 1.0

Imagination Technologies Ltd. Confidential

24

Hello AV-BWM
Design Document

Conclusion
The proposed method tracks the bandwidth deficiency using a Bandwidth factor and accordingly shares
the available bandwidth across audio and video. The video packet flow is enabled only after the
network bandwidth is sufficient to handle both audio and minimum video. Any degradation in network
due to bandwidth is reflected in BWF that is used for adjusting the video bandwidth during bandwidth
crisis. During sufficient bandwidth conditions, BWF is less than 1 and release scheduler increases the
audio and video quality respectively.

Version: 1.0

Imagination Technologies Ltd. Confidential

25

Hello AV-BWM
Design Document

Appendix
1.1 Initial Call Start Up
In an audio video call, audio is started and bandwidth availability is verified before switching on the
video packets flow between the parties.
Step 1: Initialize an audio call
Step 2: Estimate the BWF from the network statistics
Step 3: Compare the BWF with pre-defined threshold BWFT . Wait until BWF is stable for pre-defined
duration of T secs. Stability of BWF means BWF < BWFT
Step 4: Once the BWF is stable for T secs and audio configuration is best available configuration,
network bandwidth availability is verified by estimated by sending a pre-defined amount of additional
audio packets of K kbps for a pre-defined amount of time T1 secs.
Step 5: After sending an additional audio packets for T1 secs, wait for additional time of T2 secs. If the
BWF is stable until the time T1+T2 secs, enable the video packets flow between the two parties.
Step 6: After sending an additional audio packets for T1 secs, wait for additional time of T2 secs. If the
BWF is unstable, stop sending the additional audio packets and wait still the BWF is stable for enabling
the video call.
Step 7: Repeat step 2 to step 5 until the BWF is stable for (T1+T2)*J secs, i.e. above iterations are
repeated for J times. Once the BWF is stable for J times, Dynamic Video Quality Management (DVQM)
can be enabled if any.

1.2 Mid Call AV-BW switching

Steps during degrading network conditions
Step 1: Estimate the BWF from the network statistics
Step 2: Compare the BWF with pre-defined threshold BWFT. If BWF is more than the threshold, reduce
the video bandwidth utilization by a pre-defined value.
Step 3: Repeat the step 2 for 2 continuous times. If the BWF is still more than the pre-defined threshold
even after 2 decrements in video bandwidth utilization, stop the video packets flow.

Version: 1.0

Imagination Technologies Ltd. Confidential

26

Hello AV-BWM
Design Document

Steps during improving network conditions

Step 1: Estimate the BWF from the network statistics
Step 2: Verify the audio call configuration, i.e. codec used, packet size and codec mode (if any). If the
audio call configuration is the best voice quality configuration possible for the call, then go to Step 3
else, continue to Step 1.
Step 3: Follow the call start up process.

Version: 1.0

Imagination Technologies Ltd. Confidential

27

Hello AV-BWM
Design Document

Last Page of the Document

Version: 1.0

Imagination Technologies Ltd. Confidential

28