Real-time Mobile Peer – to – Peer Video Streaming
Overlay
W.V. Wathsala, Ramith Jayasinghe, Nuwan R. Gunarathna
Lanka Software Foundation,
UCSC Building Complex, 35, Reid Avenue, Colombo7, Sri Lanka
{wathsala, ramithj, nuwanr}@opensource.lk
Abstract— The Real Time P2P Video Streaming Overlay is a
real time video streaming application that uses a peer – to – peer
overlay for streaming and discovery of content. Streams can be
created, discovered and viewed from plethora of heterogeneous
devices such as desktops, smart phones and internet tablets etc. It
comes with capabilities to perform real time video stream search
queries and aggregating those into user defined channels (filters).
The real time search allows users to search for live video streams
available on the network coming from various devices connected
to the network ranging from mobile phones to HD cameras
attached to PCs. Channels can be considered as standing queries
plus a collection of known and permanent set of video streaming
resources which are at the disposal of the users allowing them to
access their favourite content easily.
Keywords— streaming, P2P, overlay, mobile
I. INTRODUCTION
Today the Internet has passed the point where it could
become unusable as a means of sharing digital information
without existence of search engines. With power of search
engine technologies such as Google real - time search and web
– 2.0 paradigms have changed the life style of people by
making the World Wide Web a platform for entertainment and
news with a personal touch. For example, online diaries such
as Blogspot[6], Wordpress[7] allow people around the world
to share their ideas, experiences and knowledge while places
like Flickr[9] let users to publish their photos in a searchable
format. Taking the content sharing and publishing to a new
era of social networking, web sites like Facebook[8] has allow
its users not only to share but also to make virtual
communities and networks that expand over geographical
boundaries. On the other hand file sharing software such as
Napster[10], Kazaa[11] brought paradigm of P2P to
mainstream, creating another opportunity for Internet users to
share content without central governance. It’s obvious that,
underlying concepts of these softwares and services are to let
users to share something with others, instantly and
boundlessly. Extreme popularity of these softwares and
services allow us to believe that Internet users and humans in
general are fond of sharing and expressing themselves and are
always looking for newer means of doing so.
Because of these reasons, we believe that there should be
more opportunities to content publishers (especially
individuals and small and medium scale publishers) while
improving individual choice by introducing heterogonous
software and hardware infrastructure which enables live/real –
time video streaming over a peer –to – peer network. The
environment we propose (over the time) will consist of
thousands of content publishers who are streaming various
media types such are localized news, sports, musical shows
etc., while consumers search and filter the media creating their
own channels as their per se. Since proposed system is a peer
– to – peer system every participant can be viewed as a
potential consumer and a producer.
However it should be mentioned that this is not the first
attempt on peer – to – peer media streaming [12], [13], [14].
Most of the previous works including both none – real-time
streaming and real-time streaming does not have an integrated
distributed stream search service. In those systems peers
become aware of streams through a web site [12]. Secondly
none real-time peer – to – peer media streaming environments
hold redundantly stored media which can be searched and
accessed by peers, in such systems it is also possible for a peer
to relay a stream receiving at the moment to another peer.
Relaying of streams is not a quite scalable method when it
comes to mobile devices that have less CPU power and
bandwidth. Existing real-time peer – to – peer streaming
environments also use the above mentioned stream relaying
method which is not scalable where mobile devices are used.
System proposed here eliminates these two issues of real-time
streaming platforms. To overcome the two issues we are
proposing two overlay networks organized appropriately to
serve the requirements of being able to scale and being able to
search in real-time. The purpose of the system is searching a
stream and building a map of the stream delivery network and
extending it. Actual streaming takes place with existing
streaming protocols such as RTP and appropriate CODECs
once the nearest location of the stream has been identified by
the recipient. Therefore QoS is not a concern in this paper.
From here onwards the paper is organized as follows, in
section II the design of the overlays and algorithms are
discussed, in section III future works and implementation is
discussed and in the section IV the conclusion is presented.
II. DESIGN
The system is built to share and search video content on
real time fashion. At this point we should make two
assumptions and their basis clear.
 A stream made available by a participating node is
available for the rest of the nodes in time
after streaming has been started.
 Before streaming starts a set of tags describing the
stream is distributed in time by the
publisher which in turn can be searched by the
other nodes in time
When an overlay satisfies the above assumptions it is safe
to assume the system will act in a real-time fashion as
expected even with large values of n (number of peer).
However with modern Distributed Hash Tables (DHTs) such
time complexities are practical and also hop – to – hop time
counts are in milliseconds in the Internet. Therefore the entire
system is built by integrating several Distributed Hash Tables
(DHTs) as shown in Fig. 1 and two of them are core overlays
or mandatory overlays corresponding to two assumptions
stated above. Namely they are the content overlay and the tag
overlay. The tag overlay is built on top of a DHT which This structure guarantees that no traffic other than the
functions as a distributed tag cloud providing the basis for node’s own will pass through a regular node which are
content discovery and search. The content overlay is typically less resourceful and typically behind NATed and
responsible for distributing content over the network and firewalled networks like desktops and mobile devices.
functions on top of a DHT. Beyond these two services any
overlay based on DHTs can be added to the system depending
on the application requirements such as overlays for
authentication, advertising, etc., which we will not be
covering here.

A. Hierarchical Structured Overlay

Methods described [1],[2],[3] assumes multiple senders and
discusses algorithms for selecting the best sender. In those
approaches parts of the stream can be downloaded from
different senders making it impossible to stream in real-time.
Such systems may not be scalable for mobile devices as they
are not resourceful with respect to CPU power, RAM and
bandwidth. Fig. 1 Overlays
In real-time streaming environment the video is uploaded to
the network on the fly from a single device while all other
devices are reading it as it becomes available. However it is
impossible to connect all interested stream recipients to the
streaming device or use peer – to – peer relaying techniques
used by [12], [13], [14] due to resource constraints such as
CPU power, RAM and available bandwidth on the mobile
device streaming the content. To overcome this problem we
propose a hierarchical structured overlay for distribution of
real-time video streams where devices lacking resources will
become Regular Nodes while resourceful devices become
Super Node. Super nodes form the peer – to – peer real-time
streaming network and should have adequate bandwidth to
perform this task. The sub overlay formed by the Super Nodes
will handle routing of media streams while Regular Nodes are
only involved in publishing and receiving media streams.
In this environment nodes join the DHT as regular nodes
and may get upgraded to super node status based on their
resource availability such as available bandwidth, CPU power
and RAM. To evaluate the suitability to become a super node
an approach similar to sender selection method discussed in [1]
can be used. The hierarchical overlay is shown in Fig. 2,
regular nodes are depicted as small circles and super nodes as
large circles. The only difference between super nodes and
regular nodes are that. Fig. 2 Hierarchical overlay

B. The Tag Overlay

 Only super nodes can function as bootstrap nodes.
 A node which has been elected as a super node
should at least have one super node as its immediate
neighbour.
Fig. 2 shows a graph satisfying above conditions. The key
characteristics of such formation are that
 Regular nodes always cluster around super nodes.
 All the super nodes excluding all the regular nodes
should form a sub graph.
Tag overlay enables the user to search for live streams in
real-time fashion. The search mechanism described here is
implanted on clients and is not a distributed process. Each tag
on a super node in the tag overlay contains keywords and
associated meta-data objects. A keyword is simply a string
which describes a particular stream. A meta-data object
contains a set of parameters such as stream key (which
identifies the DHT key of the streaming device) and a
timestamp (if the holding node’s time is greater than the value
of this timestamp the metadata object will be deleted). The tag
overlay or the distributed tag cloud must be populated
accordingly by each user before using the content overlay as
shown in the Fig. 3. Regular nodes only submit tags to the involving a reliability matrix, popularity matrix and
overlay and search for tags, super nodes are the node where authentication protocols.
those submitted tags are stored and searched for those (note:
super nodes are also regular nodes therefore in addition to
special tasks they too can perform whatever performed by
regular nodes). When a regular node submits a tag and if the
same tag has been already stored in the overlay by a different
device the super node holding the tag will not create a new tag;
instead it will associate incoming meta-data with the existing
tag, otherwise a new tag will be created by the destination
super node with associated metadata. In other words there is a
one – to – many relationship between keywords and tags.
Similarly if a tag has no more metadata objects associated to it
the super node will delete the tag itself from the system thus
freeing the system resources. This mechanism does not allow
for stale tags to last in the system for long periods of time
pointing to dead streams. To avoid premature deletion of a
metadata object the streaming node has to update the
timestamp in the metadata object stored in a super node in a
timely fashion by sending messages. Fig 4 shows how
metadata {S0, S1, S6 and S9} has been associated with the tag
Cricket.

Fig. 4 Bob’s device starting a stream after setting tags in the overlay

Fig. 3 Accessing tag overlay and content overlay separately

In the tag overlay shown in Fig. 4, Bob’s device start a

stream by first publishing tags {Cricket, Sri Lanka, Dambulla,
ODI, England}. As depicted in the graph (content overlay) a
tag can have metadata objects that intern has pointers (stream
keys) to multiple streams if multiple devices have streams
tagged with same key word. Bob’s stream is identified by the
stream key S6. The tags he submitted to the overlay are now
stored with metadata (S6 in this case1) in super nodes SN1,
SN3, SN4, and SN5.
Once the stream has been made available to the public over
the content overlay it can be contacted by clients through the
stream key after searching for the appropriate key words on
the tag overlay. As shown in Fig. 5, Ted may search for
keywords set {England, ODI, Cricket} and find a set of results,
S6 video stream being the closest match to his query. The
simplest form of this search is given below; however in reality
search may become a more complex process than given below

1
Metadata data object is identified by the stream key ignoring the timestamp Fig. 5 Streams in action
for convenience.
 TABLE 1 LookupStream( )i:
RESULTS TABLE Signature:
Key Word Results As for , and actions where is
England S5, S6, S16
a message and j is a UID of a process.
ODI S6, S9
Cricket S0, S1, S6, S9
States:
As for , plus:
TABLE 2
Initially
WEIGHTS TABLE
Unique Streams Found Weight Intially
S6 1
S9 0.66
S0 0.33
S1 0.33 Transitions:
S5 0.33 As for :
S9 0.33
Precondition:
The above query produces a set of results consisting of As for , plus:
streams S6, S9, S0, S1, S5 and they are ordered in ascending If then
order according to a weight function. Weight W Sj of the
stream Sj is simply the number of keywords which are
positive for Sj out of n number of key words (each denoted by
ki) that made up the user’s query. The formula to this End if
calculation is given below. If a stream Sj is associated with a Effect:
key word ki it is denoted by ki,Sj, which can take a value either As for :
0 or 1. If an association is found ki,Sj = 1 else ki,Sj = 0. If then

(2)
As an example S9 appeared for two keywords in the query
consisting keywords England, ODI, Cricket as shown in Table
1. Since there are three keywords involved here
. In the above query
S9 is positive for both ODI and Cricket but negative for
England. Therefore , hence
according to Eq. 2 Ws9 = (1 + 1 + 0)/3 = 0.66 as shown in
Table 2.
C. Peer – to – Peer Streaming Overlay
According to the architecture of the system, regular nodes
only stream content to the network (in this case video streams
from devices) while super nodes are responsible of both
delivering streams and streaming to consumers.
The video stream submitted to the content overlay by the
streaming node will be routed to a super node closest to the
stream key of the video stream through the DHT. The super
node which receives this stream from the streaming node
becomes a rendezvous point on the DHT. The stream key of
the metadata object found as a result of the previously
mentioned search process points to this rendezvous point.
Since all communications happen over the DHT any
intermediate super node in the overlay that falls in the path
between rendezvous point and intended recipient will also
have to read the stream as they are responsible of routing the
stream between two endpoints in the overlay.
Else
End if
Effect:
As for in :
Fig. 6 I/O automaton for stream lookup
In Fig 5, the path between streaming node and the
rendezvous point of the stream identified by the key S6 is
given by the edge (SN1, SN4) and path between the end
recipient and the rendezvous point is given by the edge (SN0,
SN1, SN3). In the example Ted searched for key words
Cricket, ODI and England and ended up with the stream key
S6 corresponding to a video streamed by Bob. Since Ted
knows the stream key S6 he is now capable of requesting the
overlay to connect his node with the rendezvous point of the
video identified by the stream key S6, thus creating the edge
(SN0, SN1, SN3). After the path SN0 - SN1 - SN3 has been
created on the DHT an RTP connection can be established on
the same path relaying the stream from SN1 to SN3 via SN0.
As depicted in Fig. 5, after Ted starts receiving the stream
Alice who connects to the overlay through SN0 too wants the
same video stream identified by the key S6, but in this case no
new stream paths will be created between super nodes SN0
(Alice’s super node) and SN1 (the rendezvous point for S6) as
the stream requested by Alice is already passing through SN0.
Therefore SN0 will directly start streaming the video to
Alice’s node which is connected to SN0 in Fig 5 using RTP.
As a result of this approach only one connection will be
maintained per video stream between super nodes no matter
how many end users requested to watch the video stream
identified by the same key. This approach for streaming is
very economical due to effective bandwidth utilization and it
resembles the qualities of IP multicasting. In this case it is
possible to visualize the group of nodes which falls on the
same stream path as a multicast group.
The advantage of this architecture is that it ensures at most
one connection per stream is maintained in the sub graph
formed by the super nodes. Therefore this model splits the
system bandwidth in to two partitions.
1) Super Node to Super Node Outbound Bandwidth:
The network presented by this sub - graph is the most
resourceful network. The bandwidth is used for
streaming between two or more super nodes on
demand. Each super node in between the sender and
the recipient nodes contribute their bandwidth to the
stream established between them.
The model can be used to specify the maximum
number of streams that can be streamed
simultaneously in the peer – to – peer overlay. Let
denote the playback rate of the ith stream on the
network, Let be the super node to
super node outbound bandwidth of super node .
Node is said to be saturated with streams if
following condition is satisfied.
(2)
Once a super node becomes saturated no more
streams can be transferred over it. If it is the only way
between a potential sender and a recipient of a stream
then that stream cannot be realized until comes out
of the saturated state.
If a super node in the way is found to be saturated
then the saturated super node can forward the stream
establishment request to its super node neighbours
until a super node that streams the intended stream is
found. The I/O automaton is specified in Fig. 6.
2) Super Node to Regular Nodes Outbound Bandwidth:
This is the simplest bandwidth management problem
in the system. If a super node has enough bandwidth
more regular nodes can connect to it. Let
be outbound bandwidth of super
node to the direction of regular nodes and be the
ith stream transmitted to any of the regular nodes
connected to it. A super node can get saturated by
streaming videos to its regular peers if following
condition is satisfied.
(3)
If a regular node connects to a saturated super node
the super node should transfer the regular node to its
next immediate none saturated super node on the
overlay. This process too can be presented using an
I/O automaton similar to the one given in Fig. 6.
III. FUTURE WORK AND IMPLEMENTATION
Future work will be done separately on peer – to – peer
real-time streaming and real-time searching. The stream
lookup algorithm can be simulated before a real
implementation and sender selection and bandwidth
management approaches mentioned in [1], [2], [3] also can be
considered when improving system performance.
Implementation will be done on Linux a platform using
Chimera DHT. The system will be developed in C++ language
and should be ported to mobile platforms such as MeaGo,
Android and iPhone with appropriate language wrappers if
necessary.
IV. CONCLUSION
Apart from entertainment, news and revenue models the
system will have an impact on the society as well. The social
aspect of this utility will ensure the free flow of information
which is quite essential in a free society. Since we are
proposing a free peer – to – peer platform for heterogeneous
devices such as mobile phones and PCs, reporting of social
events will be drastically changed. The society will be aware
and experience events in real-time due to real-time peer – to –
peer streams which are searchable and capable of being
aggregated in to channels created by users themselves.
ACKNOWLEDGMENT
We thank our peers at Lanka Software Foundation and its
administration for the constructive role they have played while
continuously supporting to refine the concept and by proof
reading this article.
REFERENCES
[1] Dongyan Xu , Mohamed Hefeeda , Susanne Hambrusch , Bharat
Bhargava, On Peer – to – Peer Media Streaming. In Proc. Of IEEE
ICDCS’02, 2002, pp 363 – 371
[2] Mohamed Hefeeda, Ahsan Habib, Boyan Botev, Dongyan Xu, Bharat
Bhargava, PROMISE: Peer – to – Peer Media Streaming Using
CollectCast. In Proc. of eleventh ACM international conference on
Multimedia, 2003, pp 45 – 54
[3] Duc A. Tran, Kien Hua, Tai Do, A Peer – to – Peer Architecture for
Media Streaming, 2003.
[4] Chimera (n.d.) [Online]. Available:
http://current.cs.ucsb.edu/projects/chimera
[5] A. Rowstron and P. Druschel, Pastry: Scalable, decentralized object
location and routing for large-scale peer-to-peer systems,
Middleware'2001, Germany, November 2001.
[6] Blogspot (n.d.) [Online]. Available: http://www.blogspot.com
[7] Wordpress (n.d.) [Online]. Available: http://www.wordpress.org
[8] Facebook (n.d.) [Online]. Available: http://www.facebook.com
[9] Flickr (n.d.) [Online]. Available: http://www.flickr.com
[10] Kazza (n.d.) [Online]. Available: http://www.kazza.com
[11] Napster (n.d) [Online]. Available: http://en.wikipedia.org/wiki/Napster
[12] TVU (n.d) [Online]. Available:
http://en.wikipedia.org/wiki/TVUnetworks
[13] PPLive (n.d.) [Online]. Available: http://en.wikipedia.org/wiki/PPLive
PPStream (n.d.) [Online]. Availabe:
http://en.wikipedia.org/wiki/PPStream