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 usable 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

functions as a distributed tag cloud providing the basis for

content discovery and search. The content overlay is

responsible for distributing content over the network and

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.

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.

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.

This structure guarantees that no traffic other than the

node’s own will pass through a regular node which are

typically less resourceful and typically behind NATed and

firewalled networks like desktops and mobile devices.

Fig. 1 Overlays

Fig. 2 Hierarchical overlay

B. The Tag Overlay

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

overlay and search for tags, super nodes are the node where

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. 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 for convenience.

involving a reliability matrix, popularity matrix and

authentication protocols.

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

Fig. 5 Streams in action

TABLE 1

RESULTS TABLE

Key Word Results England S5, S6, S16

ODI S6, S9

Cricket S0, S1, S6, S9

TABLE 2

WEIGHTS TABLE

Unique Streams Found Weight S6 1

S9 0.66

S0 0.33

S1 0.33

S5 0.33

S9 0.33

The above query produces a set of results consisting of

streams S6, S9, S0, S1, S5 and they are ordered in ascending

order according to a weight function. Weight WSj 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

calculation is given below. If a stream Sj is associated with a

key word ki it is denoted by ki,Sj, which can take a value either

0 or 1. If an association is found ki,Sj = 1 else ki,Sj = 0.

(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.

LookupStream( )i:

Signature:

As for , and actions where is

a message and j is a UID of a process.

States:

As for , plus:

Initially

Intially

Transitions:

As for :

Precondition:

As for , plus:

If then

End if

Effect:

As for :

If then

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