Video Splitting Techniques for Inverse Multiplexing
over Multiple GPRS Channels
(Final Report)
Muhammad Mudassar Nazar
Lahore University of Management Science
06030031@lums.edu.pk
ABSTRACT
Inverse multiplexing is an old phenomenon used
to aggregate bandwidth of multiple network links. It
can also be used to aggregate low bandwidth GPRS
channels to create a single higher bandwidth virtual
channel. The performance of this virtualization layer
totally depends on how we schedule packets from
above layer to the actual physical channels. For
using Inverse Multiplexing to stream videos,
importance of another component, video stream
splitter, comes into play. Now in multimedia context,
video splitting and scheduling both determine the
performance of the inverse multiplexed system.
In this writing we have tried to motivate the need
for a sophisticated scheduler and video splitter in
order to achieve high bandwidth utilization, smooth
latency, and error resilience during packet loss for
the inverse multiplexing over GPRS. We have
explored different video splitting techniques and
developed an emulation layer to experiment with
techniques.
1.
need is to adapt and modify this work to cater the
situation in our country.
Inverse multiplexing will enable us to meet the
high bandwidth requirements of some applications.
Video streaming is one such application that requires
higher bandwidth. Inverse multiplexing over GPRS
will enable us to stream video to and from anywhere,
especially in rural areas. This work can potentially
carry emerging applications like telemedicine, online
video lecturing, and video on demand etc in the areas
where it was never possible. Using telemedicine, we
can provide better health care facilities in our remote
areas. Similarly, video lecturing and video on
demand can be used to increase the education and
entertainment level of our rural areas. However
inverse multiplexing over GPRS involves a list of
research problems that need to be solved:
1.
2.
INTRODUCTION
Scarcity of bandwidth is an important hurdle in
deployment of multimedia applications everywhere.
In countries like Pakistan, this issue is more
highlighted as we have very low bandwidth last mile
connectivity e.g. dialup connections. DSL is being
offered by different ISPs but is limited to a subset of
city regions and is expensive. This situation is more
severe in rural areas where even dialup connectivity
is difficult to find. However, recent telecom
revolution in our country enabled us to use GPRS as
a last mile connectivity alternative to dialup. GPRS
connections just like dialup are low bandwidth. In
addition to it, available bandwidth and latency is
highly variable due to short term fading and multipath effects. However research efforts have been
made in order to make a higher bandwidth virtual
channel by aggregating the bandwidth of multiple
low bandwidth channels [1, 2, 3]. This virtualization
strategy is known as Inverse Multiplexing. Now, the
3.
4.
5.
Maintenance, graceful degradation of GPRS
channels (low bandwidth channels)
Calculation of end-to-end channel characteristics
like calculation of bandwidth, delay, jitter and
packet loss. [7] lists down the current work in
this research area. However as GPRS is a low
bandwidth channel, we need to measure these
characteristics in a manner that the measurement
procedure is bandwidth efficient i.e. consume
less bandwidth. This bandwidth consumption has
a direct influence on the available bandwidth of
the virtual channel as a whole.
Splitting, encoding, decoding and merging of
video streams. Some techniques are presented in
[8, 9, and 10]. These techniques derive the QoS
specification for each block that in turn will be
used for scheduling decisions.
A sophisticated scheduling scheme to schedule
data packets to underlying physical channels of
the inverse multiplexer.
Graceful degradation of the video with respect to
the available bandwidth. This includes
dynamically changing codec according to the
bandwidth available as available bandwidth is
time-varying in nature. Efficient utilization of
available bandwidth i.e. quality should be
directory proportional to available bandwidth.
1
In this writing, we have highlighted several
video splitting techniques and developed an
emulation layer to experiment with techniques.
Several experiments have been performed and their
results are analyzed. This emulation layer will
multiplex the packets to multiple available physical
channels and provide a high bandwidth virtual
channel abstraction to the application layer.
Scheduler implemented in the emulation layer
schedules requests to underlying physical channels in
a round robin fashion. We will prove by experiment
that we need a sophisticated scheduling and video
splitting scheme in order to achieve high bandwidth
utilization, smooth jitter and error resilience during
packet loss
architecture of such middleware in an effective
fashion but does not provide the mechanism to
implement scheduler in order to achieve the goals
specified by the application. Applications specify
their goals using objective specification language to
the middle ware and it is harder to write lengthy
specifications. Horde uses a random-walk scheduler
that uses QoS specified by the application to schedule
packets. Our scheduler will provide the application
specific QoS by giving more consideration to end-toend GPRS channel characteristics (available
bandwidth, latency jitter and loss) and we can say
that our scheduler QoS mechanism is network driven.
Different network characteristics measurement tools
are available, latest study of such tools is given in [7].
2.
The problems of using a simple round-robin
scheduling are highlighted in [3] as it will fail in
achieving a higher bandwidth virtual channel that
guarantees application specific QoS. RR may lead to
adverse effects, in case we schedule a packet
requiring a reliable channel to a lossy channel.
Hence, scheduling scheme should take care of the
characteristics of channels instead of blind
scheduling. This type of simple scheduling scheme
can work in circumstances when underlying physical
channels are less varying channels. We will prove in
our experiments that GPRS channels are highly
variable and thus these simple scheduling schemes
will not work effectively.
RELATED WORK
Inverse multiplexing is used to aggregate the
bandwidth of multiple network channels to create a
single higher bandwidth virtual channel. This
mechanism is being used in circumstances where
individual bandwidth of channels is not sufficient
enough to fulfill higher bandwidth demand of
applications e.g. multimedia applications [1, 2].
Inverse multiplexing can be implemented above the
transport layer [2] or at link layer level as Multilink
PPP under IP layer [1].
However, whatever is the architecture of the
inverse multiplexer and wherever we implement it in
the protocol stack, scheduling scheme is at the core
of its success. In the case when we are using inverse
multiplexing for video streaming, a scheduler is
sandwiched between the network channels and the
different data streams generated by the Splitter.
Network channels are time-varying and scheduler has
to take care of this fact. On the other end, Splitter
splits a video stream into multiple video streams with
different QoS requirements. Scheduler has to meet
these QoS requirements with respect to the QoS
provided by the network channels at a particular time.
Horde[2] proposes an architecture that can be
used to inverse multiplex multiple GPRS channels. It
makes the claim of separating striping policy from
mechanism by providing support for application
specific QoS provisioning. Applications can specify
their QoS features dynamically and Horde uses
underlying (possibly heterogeneous) GPRS channels
to transfer the data. As the QoS characteristics
exhibited by these individual GPRS channels is a
function of time, the overall performance of the
middleware (Inverse Multiplexer) is dependent on the
scheduling scheme used to schedule packets on these
channels. Horde lays down a comprehensive
The disadvantages of using TCP as a transport
mechanism over GPRS are discussed in [4, 5]. TCP
flows destined to a single mobile host should be
aggregated to increase the TCP performance [4]. This
aggregation is accomplished using a TCP aggregation
proxy at the wired-wireless network boundary. This
proxy avoids TCP slow-start mechanism and attains
the full utilization of link from the start known as
fast-startup. This mechanism will only increase the
performance of TCP to individual mobile hosts and is
beneficial when user is surfing internet and opening
different sites. In our case, it is not beneficial as we
will be using at most two connections per GPRS
channel (control and data). Moreover this aggregation
mechanism only work for the flows generated from
wired to the wireless medium and not the other way.
GPRSWeb [5] presents a UDP based transport
mechanism that is optimized to be used over GPRS.
Like [4], GPRSWeb is also optimized for web surfing
i.e. to service HTTP content in an efficient manner.
Moreover it also needs addition of a GPRSWeb
proxy node in the existing GPRS infrastructure. As
our scheduling algorithm will schedule data from
different type of applications, we assume a best effort
2
service from underlying channels i.e. UDP transport
mechanism and ARQ disabled link layer. Although
[4, 5] are providing mechanisms to improve web
surfing experience of the mobile users, but proposing
techniques that need a change in the underlying
infrastructure that is harder to accomplish.
A scheduling problem is formulated in [6] that
conform to our scenario; Splitting, replication and
erasure coding techniques are used to optimally
schedule the packets in delay tolerant networks
(DTN) context. It tries to maximize the probability of
successful packet delivery in path volume
constrained environment. In general, optimization
problem formulated is proved to be NP-hard.
However for some special cases this is solvable i.e. Si
is approximated by Gaussian distribution. We can
find the behavior of Si in our case and apply the
formulation to solve the scheduling problem. Among
other things we need to consider is that techniques
given in [6] are related to DTN. In our scenario we
have limited bandwidth; replicating data in order to
maximize guaranteed delivery may not be a good
idea. Our traffic (video and audio) needs bounds on
latency and jitter; however we can tolerate some loss.
So problem formulated in [6] is relevant to our
problem but with different constraints.
MobiStream [11] uses virtual channel link layer
level abstraction. Application can open multiple
virtual channels and can choose different channels for
different blocks of a video stream, depending on QoS
provided by a virtual channel and QoS required by a
particular video block. To achieve a higher level of
error resilience, MobiStream partitions a video frame
into slices that are independently decodable and
priorities the slices on the basis of their perceptual
usefulness. It also introduces techniques like multiple
description coding, slice structured coding, and interframe/intra-frame slice interleaving. Slice structured
coding and slice interleaving are used to mitigate the
effects of bursty losses.
Three simple and elegant block interleaving
techniques, namely triangular, quadrant and
coefficient interleaving schemes are proposed in [10].
In triangular interleaving scheme, a DCT block is
divided into a lower triangular region and an upper
triangular region. These upper and lower regions
from one DCT block are interleaved with the regions
of other DCT blocks. This interleaving is done in
such a way that if a lower region from a particular
block is lost then there is higher probability that
upper triangular region from that block is not lost.
Here DC coefficients are grouped in a different block
and thus can be transmitted on a more reliable GPRS
channel.
In quadrant interleaving scheme, we have four
interleaving groups instead of two. Each 8x8 DCT
block is divided into four quadrants namely L (low
frequency), HD (Horizontal medium to high
frequency), VD (vertical medium to high frequency)
and HI (high frequency). Interleaving is done by
combining four 8x8 blocks to make a 16x16 macro
block in such way that each 8x8 block in the new
macro block contains quadrants from different block.
Each 8x8 block is number clock-wise from 0 to 3 in
the macro block. The
general formula for
interleaving is that select Li (i= 0,1,2,3) and HDi+1,
HIi+2 and UDi+3 to form new interleaved 8x8 blocks
within the16x16 block.
Coefficient interleaving scheme treats each AC
coefficient as a group. So, we have sixty three
interleaving groups per DCT block. Although this
scheme optimally interleaves the information but it
has higher processing cost and may lead to
compression inefficiency. Interleaving block is made
by combing groups from different blocks in a way
that we select first group from first block, second
group from second block and so on.
3.
EXPERIMENTS
We have performed some experiments in order
to increase our knowledge about characteristics of the
GPRS network. So far, we have completed three
types of experiments: RTT, jitter and bandwidth
estimation for a single GPRS channel.
3.1 Experimental Setup
Currently multiple operators are providing GPRS
services in Pakistan, we have chosen Warid GPRS
for our experiments. We have made a ppp connection
with a GPRS enabled mobile handset over Bluetooth.
This connection is made over rfcomm to use GPRS
as the last mile connectivity to internet.
3.2 RTT calculation using PING
Using the above mentioned setup we have
estimated the RTT for one thousand packets. Figure 1
shows the variability among the RTT’s of different
packets.
These high fluctuations in the RTT behavior
favor our thesis that overall performance of the
inverse multiplexer for GPRS will depend on the
scheduling scheme used.
3
ti-1 is the time stamp for (i-1)th packet and
α is the time spacing for generation of two
consecutive packets at sender.
Figure 1
2500
Practically, during these experiments we have
taken care of losses using sequence numbers in
packets. Sequence numbers have helped us to filter
wrong jitter results.
1500
1000
500
0
1
83
165 247 329 411 493 575 657 739 821 903 985
Time
Figure 1.Result of RTT experiments
Table 1 shows the statistics for this experiment
as RTT. Fluctuations observed in figure 1 have
resulted in the higher value of standard deviation.
Higher mean value can become problematic in
bounds for latency in real time applications.
Experiment
RTT
Jitter(1s)
Jitter(2s
Mean
588
333
149
Dev.
353
289
208
Max.
2367
1830
1390
Min.
204
0
0
Table 1.Statistics for all the experiments
However the actual value need to be looked is
deviation instead of the mean. This high deviation
emphasizes the need for a sophisticated scheduler in
order to achieve bounded jitter. One can argue that
RTT is not a good measure to estimate jitter as it is
two-way. However it gives a rough behavior of the
delay (one way) and is somehow related to jitter that
we will experience.
We have experimented for two values of α
respectively 1 and 2 seconds. This allows us to
examine the behavior in periods of higher utilization
of the link and relatively low utilization of the link
respectively. Figure 2 and 3 plot results of both the
experiments respectively. From Table1 it is clear that
variability for both the experiments is high 289 and
208 respectively.
During these experiments, loss occurred was
2.6% and 2.2% respectively. We have mentioned
losses in order to highlight that we are using lossy
channel. Therefore, one objective of the scheduling
scheme is to provide error resilience in case of packet
loss. So here comes the importance of using video
splitting techniques.
Figure 2
2000
1500
Jitter(ms)
RTT(ms)
2000
1000
500
0
0
Another statistic we have measured in RTT
estimation experiments is packet loss that is around
5%. This is low as ARQ is enabled at the link layer.
ARQ is enabled between Mobile and the Base Station
to balance the signal attenuation due to fading and
multi-path behavior of the wireless medium.
200
400
600
800
1000
Time
Figure 2.Jitter estimation for α = 1 s
Figure 3
1600
3.3 Jitter Estimation
1400
ji = │ti-ti-1- α│
Where
ji is the jitter for ith observation
ti is the time stamp for ith packet
Jitter(ms)
1200
We have also estimated the jitter for a particular
time period. We have a sender that sends a packet
after a regular time interval α. At receiver we record
the time at which every packet received. Then we use
the following formula to calculate the relative delay
variance between two successive packets.
1000
800
600
400
200
0
0
200
400
600
800
1000
1200
Time
Figure 3.Jitter estimation for α = 2 s
By closely observing Figure 2, we can define 4
classes for the jitter observations:
4
a.
b.
c.
d.
Jitter observations that are close to zero
Jitter observations that are close to 150
Jitter observations that are close to 500
Jitter observations that are highly variable and
greater than 600
Figure 3 can be summarized as that, in case
when we have relatively less congestion in the
network, jitter observation can be classified in two
classes, one in which observations are less variable
i.e. observations less than 200 and other in which
observations are highly variable i.e. observations
greater than 200.
Now, we can see that difference between packet
losses is very less for both jitter experiments.
However jitter values for both experiments have a
significant difference. This is because that the jitter
introduced is not due to high loss but is due to the
queuing delay in the intermediate nodes. We need to
define the scheduling scheme in way that it does not
congest the network.
3.4 Bandwidth Estimation
We have used pathload, a bandwidth
measurement tool to estimate the available bandwidth
of the GPRS channel. Its open source implementation
is available. We have to change some configuration
variables in order to adapt it for estimating bandwidth
for low bandwidth channels e.g. GPRS.
We have estimated the available bandwidth at
different times of the day. It was ranging from 2kbps
to 4kbps. According to Horde [2] measurements, it
ranges from 19kbps to 25kbps. But these
measurements have been performed in US.
intervals, making connection with the newly
discovered devices, creating routing table and routing
rules for each discovered device. Beyond that it adds
each discovered device in the device list.
Channel manager is used to synchronize the
device list maintained by the layer with actual
physical devices available at that particular time.
Some devices may disappear and we have to remove
them from the device list.
Scheduler queues the requests from the outer
world and schedule requests to available devices
(GPRS channels) in a round robin fashion. Different
shell scripts have been developed for different
purpose. Following is the description of work done
by each script:
makeConnection.sh: Device Discover uses this script
to make a GPRS connection with a device. This
script also releases the unused rfcomm devices as
part of selecting rfcomm device for this particular
connection.
getLastInterfaceDetails.sh: Device Discoverer uses
this script to get the interface name, IP address and
gateway of the last device added.
getPPPInterfaces.sh: This is used by the Channel
Manager in order get all available GPRS channels at
this particular time.
init_alternate_route.sh: This script is used by both,
the Device Discoverer and Channel Manager, to
create a separate routing table and rule for each
network channel.
init_route.sh: This script is called at the start of
program in order to initialize routing tables for
Ethernet interfaces (if any)
5.
4.
We have developed an emulation layer to
experiment with the above mentioned video splitting
techniques on real GPRS channels. This layer has
three major tasks:
Up till now we have explored different video
splitting techniques, conducted experiments to study
the behavior of network channels and implemented
an emulation layer. Some future directions are:
a.



FUTURE WORK
EMULATION LAYER
It provides an interface to outer world in order to
schedule packets
It Identifies new GPRS devices and make
connection with them using Bluetooth
It maintains a list of available GPRS devices for
scheduling purpose
b.
c.
Major components of this layer are Device
Discoverer, Channel Manager, Scheduler and shell
scripts. Responsibility of the Device Discoverer is to
initiate a search for new devices after periodic
Setting up experiments for video splitting
techniques using emulation layer described
above.
Defining a better scheduling scheme that
maximizes the performance of the inverse
multiplexer. This include the rate control on
different links to reduce packet loss and jitter
The gap between the bandwidth available in
Pakistan and US has guided us to validate the
feasibility of video streaming over inverse
multiplexed system. One direction is that instead
of using GPRS channels on one side and internet
5
on other side, we use GPRS channels at both
sides. This idea may boost the bandwidth
available as data is not routed to internet.
6.
CONCLUSION
High variability in RTT and jitter values is
giving us a clue that whatever is the architecture of
the inverse multiplexer and wherever we implement
it in the protocol stack, we need a sophisticated
scheduling scheme.
For video streaming over an inverse multiplexed
system, we need a splitter that splits a video stream
into multiple streams and define the QoS of each new
stream. Scheduler is sandwiched between the
network channels at one side and splitter on the other
side. At one end, it has to look at the characteristics
provided by the network channels and at the other
end, it has to meet the QoS requirement of each
stream.
SIGCOMM’05
Computer
Communication
Review
7. http://www.icir.org/models/tools.html
8. Goyal V., “Multiple description coding:
compression meets the network”, IEEE Signal
Processing Magazine, vol. 18, pp. 74-93,
September 2001.
9. Rajiv Chakravorty, Suman Banerjee and Samrat
Ganguly., “MobiStream: Error-resilient video
streaming in wireless WANs using virtual
channels”, in IEEE Infocom, Barcelona, Spain,
2006
10. Add reference to paper written by sir
11. Rajiv Chakravorty, Suman Banerjee, Samrat
Ganguly, “MobiStream: Error-Resilient Video
Streaming in Wireless WANs using Virtual
Channels”, Proceedings of IEEE Infocom 2006
Different values of jitter are experienced for
different values of α. So we need some mechanism
for rate control at each network channel. This
mechanism should take care of the fact that our
sending rate to particular channel should not exceed
the bandwidth provided by that channel.
7.
REFERENCES
1.
Alex
C.
Snoeren,
“Adaptive
Inverse
Multiplexing for wide-area wireless networks”,
Proceedings of IEEE GlobeCom’99
Qureshi A. and Guttag J., “Horde: Separating
Network Striping Policy from Mechanism”,
ACM MOBISYS’05
James C. Funk, Heidi R. Duffin, Lichen Dai,
Charles D. Knutson, “Inverse Multiplexing in
Short-Range
Multi-TransportWireless
Communications”, Proceedings of the IEEE
Wireless Communications and Networking
Conference 2003
Rajiv Chakravorty, Sachin Katti, , Ian Pratt, Jon
Crowcroft, “Using TCP Flow-Aggregation to
Enhance Data Experience of Cellular Wireless
Users” IEEE Journal on selected areas in
Communications’06
Rajiv Chakravorty, Andrew Clark, Ian Pratt,
“GPRSWeb: Optimizing the web for GPRS
Links” MobiSys 2003: The first international
conference on Mobile Systems, Applications and
Services
Sushant Jain, Michael Demmer, Rabin Patra,
Kevin Fall, “Using Redundancy to Cope with
Failures in a Delay Tolerant Network”, ACM
2.
3.
4.
5.
6.
6