Remote Collaborative Real-Time Multimedia Experience … · virtualisation. 1.2 Scope of the ... that is responsible for network access and resource allocation to support IP ... routers

ROMEO WP5 Page 1/40

Remote Collaborative Real-Time Multimedia Experience over the Future Internet

ROMEO

Grant Agreement Number: 287896

D5.1

Interim report on 3D media networking and synchronisation of networks

ROMEO WP5 Page 2/40

Document description

Name of document Interim report on 3D media networking and

synchronisation of networks

Abstract This document provides an interim report on

3D media networking and synchronisation of

networks, mainly providing preliminary

decisions and guidelines towards possible

network configurations to deliver 3D multi-

view video and the associated spatial audio

with the best possible QoE, by using

mechanisms which monitor the overall

system delivery performance, in order to

adapt the network to maximize the service

delivery to the end user.

Document identifier D5.1

Document class Deliverable

Version v1.0

Author(s) H. Marques, H. Silva, J. Rodriguez (IT)

H. Keskin, H. Gökmen, B. Demirtaş, O.

Dinçer, U. Halatoğlu (ARC)

Vencislav Petrov (MMS)

Fernando Pascual Blanco (TID)

A.Akman, E.Cimen, S.Ciftci, S.O.Pelvan

(TTA)

I. Politis, K. Birkos, A. Likourgiotis and A.

Kordelas (UP)

QAT team H. Ibl (R&S),E. Ekmekcioglu (US), X. Shi

(MULSYS)

Date of creation 20-Jul-2012

Date of last

modification 26-Sep-2012

Status Final

Destination European Commission

WP number WP5

Dissemination Level Public

Deliverable Nature Report

ROMEO WP5 Page 3/40

TABLE OF CONTENTS

1 INTRODUCTION ................................................................................................. 6

1.1 Purpose of the Document ............................................................................. 6

1.2 Scope of the Work ........................................................................................ 6

1.3 Objectives and Achievements ...................................................................... 7

1.4 Structure of the Document ............................................................................ 7

2 Server Components .......................................................................................... 8

2.1 P2P .............................................................................................................. 8

Internet Resource and Admission Control Subsystem (IRACS) ............ 8 2.1.1

Multicast Tree Manager (MTM) ............................................................. 9 2.1.2

Topology Builder (TB) ......................................................................... 11 2.1.3

P2P Packetisation Structure for ROMEO ............................................ 14 2.1.4

3 Peer Components ............................................................................................ 16

3.1 P2P ............................................................................................................ 16

Internet Resource and Admission Control Subsystem (IRACS) ........... 16 3.1.1

Topology Controller (TC) ..................................................................... 16 3.1.2

P2P Depacketisation ........................................................................... 17 3.1.3

P2P Chunk Selection .......................................................................... 17 3.1.4

3.2 Synchronisation .......................................................................................... 19

Play-out Synchronisation ..................................................................... 19 3.2.1

Collaborative Synchronisation ............................................................. 20 3.2.2

3.3 A/V Communication Overlay ...................................................................... 21

Video conferencing platform ................................................................ 21 3.3.1

Collaborative Synchronisation Controller ............................................. 21 3.3.2

3.4 A/V Adaptation & Network Monitor ............................................................. 21

3.5 User Generated Content ............................................................................ 23

User Generated Content Capture ........................................................ 23 3.5.1

User Generated Content Upload / Download ....................................... 24 3.5.2

User Generated Content Register and Store ....................................... 24 3.5.3

User Generated Content Search and Discovery .................................. 24 3.5.4

4 Network-related Components ......................................................................... 25

4.1 Mobility ....................................................................................................... 25

Media Aware Proxy ............................................................................. 26 4.1.1

Media Independent Handover ............................................................. 27 4.1.2

Proxy Mobile IP (PMIP) ....................................................................... 30 4.1.3

4.2 Virtualisation ............................................................................................... 31

Virtualisation Platform ......................................................................... 31 4.2.1

ROMEO WP5 Page 4/40

ROMEO QoS Enforcement ................................................................. 31 4.2.2

4.3 Internet Resource and Admission Control Subsystem (IRACS) .................. 32

Control Information Base (CIB) ............................................................ 32 4.3.1

Resource Reservation Subsystem (RRS) ............................................ 32 4.3.2

Admission Control Subsystem (ACS) .................................................. 32 4.3.3

Resource Controller (RC) .................................................................... 33 4.3.4

Network Initialization Phase Management ........................................... 33 4.3.5

Network Operating Phase Management .............................................. 34 4.3.6

5 CONCLUSIONS ................................................................................................ 35

6 REFERENCES .................................................................................................. 36

7 APPENDIX A: GLOSSARY OF ABBREVIATIONS: ......................................... 37

ROMEO WP5 Page 5/40

LIST OF FIGURES

Figure 1 - Scenario for distribution of 3D real-time content over P2P networks (high-level view) .............. 6

Figure 2 - Illustration of an ISP network topology supporting ROMEO....................................................... 8

Figure 3 - Preliminary SDL diagram for READY links computation algorithm at access level by the MTM ................................................................................................................................................ 10

Figure 4 – Simplified set of procedures performed by a peer upon detecting major failure in the media stream delivery ........................................................................................................................ 11

Figure 5 – Preliminary SDL diagram for the tree construction algorithm .................................................. 13

Figure 6 – Scenario for distribution of 3D real-time content over P2P networks (detailed view) .............. 14

Figure 7 – Scenario for distribution of 3D real-time content over P2P networks (overlay view) ............... 14

Figure 8 – P2P Chunk Structure .............................................................................................................. 15

Figure 9 – Topology Controller blocks and interconnections with other ROMEO components/modules .. 16

Figure 10 - Conceptual and functional representation of the P2P Chunk Selection module .................... 18

Figure 11 - Flow chart of the operations performed by Chunk Selection.................................................. 18

Figure 12 – Play-Out Synchronisation Blocks .......................................................................................... 20

Figure 13 – A/V Adaptation & Network Monitor blocks and interconnections with other ROMEO components/modules .............................................................................................................. 22

Figure 14 – NMS aggregation capabilities – full data structure specifications will be included in D6.2 .... 23

Figure 15 Mobility module functional blocks and Information flow ........................................................... 25

Figure 16 – Flowchart datagram of the Media Aware Proxy .................................................................... 27

Figure 17 IEEE 802.21 Media Independent Handover framework ........................................................... 28

Figure 18 - Media Independent Handover key services ........................................................................... 28

Figure 19 - Preliminary flow chart diagram of the enhanced MIH function ............................................... 29

Figure 20 Preliminary flow chart diagram of Proxy Mobile IP scheme ..................................................... 30

ROMEO WP5 Page 6/40

1 INTRODUCTION

1.1 Purpose of the Document

This document provides interim decisions on the networking solutions for the delivery

of 3D multi-view video and the associated spatial audio with the best possible Quality

of Experience (QoE) to ROMEO end users. This document mainly focuses on the

peer-to-peer (P2P) and Digital Video Broadcast (DVB) interworking for fixed, portable

and mobile equipment, and the play-out synchronisation for real-time 3D content

delivery in heterogeneous networks. In addition this document also provides

preliminary decisions regarding the real-time audio-visual communication overlay

between remote users, user generated content provision and terminal equipment

virtualisation.

1.2 Scope of the Work

The work described in this document is relevant to define how multi-view 3D media

content is distributed using both terrestrial DVB and a P2P overlay network, as

illustrated in Figure 1, while assuring redundancy, low-delay delivery and

synchronization amongst the multiple views, aiming at providing the best quality of

service to each peer in proportion to its available resources.

Stereoscopic view

Other view (e.g. far right)

Other view (e.g. far left)

Multiple camera views

Encoding Server

Content/Authentication/ROMEO Server

Super-Peer

Operator A premises

Super-Peer

Operator B premises

Parent

Parent/Child

Child (leaf)

Mobile users(always child)

BS

DVB Service Provider

stereoscopic

view

Enhancement layer

Legend

P2P network

Synchronised

Figure 1 - Scenario for distribution of 3D real-time content over P2P networks (high-

level view)

ROMEO WP5 Page 7/40

1.3 Objectives and Achievements

This deliverable further details the ROMEO network configuration requisites and

associated server, peer and network-related modules for the DVB and P2P

synchronous real-time streaming delivery.

The main achievements of this document are the interim specifications of: (i) the

operations of an Internet Resource and Admission Control Subsystem, operating at

server, peer and network devices, capable of defining a scalable QoS architecture

while keeping low QoS reservation control signalling and related overhead; (ii) a

Multicast Tree Manager, Topology Builder, Topology Controller and Network

Monitoring Subsystem and their interoperation in the construction and management of

the multiple multicast trees and peer insertion on such trees; (iii) the Packetisation,

Depacketisation modules that significantly improve the video and audio decoding

process by facilitating error concealment at the receiver; (iv) Chunk Selection and

Synchronization modules responsible for improved reliability and synchronization; (v)

network-related modules responsible for ensuring seamless 3D video service

continuity to mobile and portable users across heterogeneous radio access networks.

In addition, this deliverable also provides preliminary guidelines for: (i) a virtualisation

solution to be employed within the ROMEO platform to reduce the number of devices

needed in the residential environment and to ensure that the user perception meets

the expected QoE for all services subscribed to the residential environment (ii) the

operation of the audio-visual communication overlay solution that will enable ROMEO

users to share content and interact via video conferencing platform (to be updated on

D5.3) and; (iii) user generated content that enable users to create, store, search and

download content (to be updated on D5.4).

1.4 Structure of the Document

For 3D media networking and the synchronisation of networks, ROMEO depends on

software modules running both at the server and at the peer. Server side modules are

described in section 2 and peer side modules are described in section 3. Network-

related modules towards providing seamless access for mobile users, virtualization

and Quality of Service (QoS) assurances are described in section 4. Conclusions on

the proposed report are provided in section 5. References and abbreviations can be

found at the end of the document, in sections 6 and 7 respectively.

ROMEO WP5 Page 8/40

2 Server Components

2.1 P2P

Internet Resource and Admission Control Subsystem (IRACS) 2.1.1

The main objective of the Internet Resource and Admission Control Subsystem

(IRACS) is to define a scalable QoS architecture to enable bandwidth-aware IP

transport, keeping low QoS reservation control signalling and the related overhead.

To facilitate the understanding, one can imagine a network as illustrated in Figure 2

which represents an Internet Service Provider (ISP) network spanning three Point of

Presences (PoPs), towns A, B and C connected through a common backbone

infrastructure composed of 4 core routers and 5 edge routers (ERs). IRACS goal is to

optimize the resource utilization and ROMEO service performance by properly

enforcing QoS measures at the ISP network.

C2C1

ER1

ER5

ER4

ER3

ER2RAM

C3

C4

Encoding

Server

Content/Authentication/

ROMEO ServerSuper

Peer

Operator A

premises

Town B

Town C

Town ARC

RC

RC

RC

RC

RC RC

RCRC

Enhancement layer

Other view

Connection request

Operator A

Backbone

NCDP

NCDP

NCDP

NCDP

RAM

RAM

RAM

Resource Admission ManagerRAM

Resource ControllerRC

Edge RouterER

Network Control Decision PointNCDP

Core RouterC

Connection response

PoP

PoP

PoP

Figure 2 - Illustration of an ISP network topology supporting ROMEO.

Within ROMEO, a network control will be assured by a server called Network Control

Decision Point (NCDP). In particular, an NCDP is responsible for maintaining a good

view of the network topology and the related link resource statistics, and for

controlling a proper distribution of resources among multiple Classes of Service

(CoSs) in a way to meet heterogeneous QoS demands with increased resource

ROMEO WP5 Page 9/40

utilization. In purely centralized networks, a single NCDP will take overall control of

the network. In hierarchical scenarios as in Figure 2, an NCDP is deployed per PoP

and per backbone for scalability reasons.

2.1.1.1 Resource and Admission Manager (RAM)

Besides the NCDP at server side, the IRACS mechanism is implemented using a

Resource Admission Manager (RAM) that is responsible for network access and

resource allocation to support IP transport with heterogeneous QoS requirements.

This is done without overwhelming networks with QoS reservation signalling, states

and processing overhead while guaranteeing Service Level Agreements (SLAs) in

terms of bandwidth. The RAM achieves this by interacting with network-related

modules such as a Control Information Base (CIB), an Admission Control Subsystem

(ACS), a Resource Reservation Subsystem (RRS) and a Resource Controller (RC),

which are explained in section 4.3.

Multicast Tree Manager (MTM) 2.1.2

The Multicast Tree Manager (MTM) module is responsible for the management of the

overlay multicast distribution trees. MTM’s operations are intrinsically connected with

the Topology Builder (TB) and IRACS modules. At ISP level, upon the definition of

appropriate multicast trees by the TB (see next section), the MTM uses ISP network

topology information provided by IRACS (RAM module) to define appropriate ISP

READY and SLEEP trees, which are then properly signalled and enforced at ISP

routers by the IRACS network-related modules (CIB and RC modules). A READY tree

would be the second best tree (using Dijkstra’s algorithm, as defined in [1]) after the

ACTIVE tree computed by the TB, and a SLEEP tree would be the best tree after that.

If multiple ACTIVE trees are needed, then the same process is repeated multiple

times. SLEEP trees will always be calculated after the last READY tree computations.

At access level (between edge router and served peers), the READY links are defined

by the MTM according to the algorithm illustrated in Figure 3. The READY links

computation takes in consideration that peer link failures or bad link performance are

most of the times related with the connection to the peer’s parent. When computing

READY links, the MTM algorithm always chooses links with peers that are not

connected to the same parent. The information on the READY state is provided by

the MTM to each peer’s Topology Controller (TC).

The transition from READY to ACTIVE is always commanded by the MTM and should

always be preceded by a set of checks done by the peer, as depicted in Figure 4. For

relatively minor problems such as lost packets (chunks), it is up to the peer’s Chunk

Selection module to solve the issue, as explained in section 3.1.4. If a major failure

occurs in stream reception, a peer first contacts its parent and if the parent has the

same problem, it is up to the parent to solve the problem. If the parent cannot be

contacted, then the peer should contact the TB at the super-peer who then triggers

the MTM module to send a request to the Topology Controller (TC) of selected peers

to activate READY links in order to achieve full peer connectivity.

It is important to note that the MTM periodically refreshes READY links based on the

periodic Network Monitoring Subsystem (NMS) reports (see section 3.4) received by

ROMEO WP5 Page 10/40

the TB. With this operation MTM manages to quickly adapt to changes occurred in the

network by switching among available links.

Available resources?

yesThis other peer

presents a READY link for the peer

For each other peer (sorted by

no

READY link for this peer is a direct link from edge router (TB/MTM signals IRACS to enforce this state – replicator is infomed of the peer’s IP address)

Last other peer?

yes

no

Go to next other peer

For each peer (sorted by ascending

evaluation)

Last peer?

yes

no

Go to next peer

End of READY links computation

Evaluation >= this peer’s father?

no

yes

ascending evaluation)

Maximum #streamsat edge router?

yes

no

No READY link for this peer

Multicast Tree Manager

Figure 3 - Preliminary SDL diagram for READY links computation algorithm at access

level by the MTM


Can parent be contacted?

Wait for parent to solve the situation

Contact parent peer

Peer does not receive media stream

yes

ContactTB/MTM at super-peer

no Upon timeout

Contact TC of peer and new parent to activate READY link

MTM (super-peer)

TC (peer)

NMS (peer)

Figure 4 – Simplified set of procedures performed by a peer upon detecting major

failure in the media stream delivery

Topology Builder (TB) 2.1.3

The Topology Builder (TB) is the module responsible for receiving new connection

requests, acting as a proxy for user authentication, collecting network monitoring data

from each of the peers, and creating multiple multicast trees that effectively construct

the P2P overlay network used for the distribution of the multiple streams associated

with the visualization of 3D content.

Upon a user connection request and authorization success, the corresponding peer is

redirected to its nearest super-peer (this decision is based on the peer’s IP address).

The TB on the super-peer will then receive this redirect/connection request and

collect the peer’s network monitoring data (as specified in section 3.4) to determine its

capabilities. To construct the P2P overlay the TB heavily depends on the information

provided by the IRACS (RAM module) to determine the full ISP network topology, to

know, for example, which edge routers feed which networks. The TB also needs peer

information (IP address and others, as described below) to determine where to insert

each peer in a stream specific distribution tree.

As depicted in both Figure 1 and Figure 2, at the top of the tree is the

Content/Authentication/ROMEO server. For the typical distribution scenario over the

Internet this server does not enter in the tree calculations, as these are performed by

the super-peers. Hence a super-peer will always put itself as the root of any

computed tree. For any given 3D media stream, the TB starts computing the tree by

using the shortest path in the ISP core network, using the mechanisms explained in

section 4.3, and for the branches it then uses the peer’s IP address to group them by

location. Once the grouping operation is done, joining peers are ranked based on a

composite metric that takes in to consideration the peer’s reported information.

Specifically, the evaluation is done considering the hardware (memory and CPU),


network capabilities (upload and download throughput) and stability (how stable is the

peer in the network – this is a cumulative metric), according to the following formula:

( ) ( ) ( ) ( ) ( ) (1)

Where:

K1 to K4 - weights that allow fine-tuning the peer evaluation metric.

U – upload bitrate

D – download bitrate

M – memory in gigabyte

C – number of CPU cores

S – peer’s stability as described in section 3.4

The sorted ranked list is then used by the super-peer to create a stream specific

multicast distribution tree with the highest evaluated peers at the top and the least

evaluated as leafs. Mobile terminals will always be leaf peers since they have

considerable restrictions in their download/upload capacity, memory and CPU, and

also traffic and battery. Higher hierarchy peers are attributed child peers according to

their upload capacity, never exceeding a threshold value of the total peer’s upload

capacity, needed for other non-related traffic – the threshold value will be dependent

on experimentation results (in the scope of Work Package 6). The algorithm is

optimized to provide a wide tree in order to minimize both the number of hops and the

path latency from the root of the tree to the leafs. A preliminary SDL diagram for the

tree construction algorithm is depicted in Figure 5. As it can be seen, different trees

are constructed, one per each edge router and per each stream. It’s important to note

that the maximum number of peers directly connected to the super-peer (k, in Figure

5) depends on the capabilities of the edge router that is feeding that specific zone.

That information is gathered by the IRACS, as explained in section 4.3, and then

provided to the TB.

This concept is also illustrated in Figure 6, where the IRACS mechanisms are used by

the TB to minimize the bandwidth consumption at the ISP network. Using these

mechanisms the TB creates a shared tree that efficiently distributes the content till the

ISP edge routers. From this point forward the multicast trees used for the P2P overlay

network are constructed using the algorithm depicted in Figure 5. For a single stream,

the correspondent P2P overlay network is given in Figure 7.

After the distribution of the 3D media stream has started, any new peers joining the

tree will be inserted as leafs (even if they have a good evaluation metric) unless there

are available positions to directly connect to the super-peer. When inserting a new

peer as a leaf, the peer evaluation will be used to move such peers to the right

position in the tree. The TB executes this process in an incremental fashion to

minimize changes in the distribution tree.


Peer evaluation

Peer

Connection request(includes peer capabilities)

Table

write

PeerID, evaluation, ...

List of peers grouped by requested stream, edge router, and sorted by

evaluationPeerID, evaluation, ...

Copy of Sorted Table

Copy

§ Adjust k size (according to marked candidates to level 1)

§ First k peers are child peers of super-peer

§ Mark potential peers for insertion at level 1

§ Make peer in copied table child of Peer[i]

§ Mark peer in copied table as not lost

§ Remove peer in copied table

For i=0 till total #peers

last peerin copied table

?

i++

no i=total #peers

yes

yes

End

Topology Controller

Server (Topology Builder)

Max childs at Peer [i]?

yes

§ Go to next peer in copied table & apply one of the policies below:

§ Change order from k + 1 to maximum table -1

§ Change order from maximum table – 1 to k + 1

no

Peer [i]resources above

thresh.?

Peer [i]Is marked as candidate?

yes

yes

no

no

no

· Start on k+1 position· Varies between k+1

and maximum table -1· Check for peer’s

download capacity

Figure 5 – Preliminary SDL diagram for the tree construction algorithm


ISP AnetworkInternet

Content/Authentication/ROMEO Server

Super-Peer

RR

R

R

ISP Bcore network

R

Edge routersR R

R

RRR

Customer networks

RR

R

R1

2 34

56 7

89

1011

12

ISP BServicesnetwork R

R(to other ISPs)

Figure 6 – Scenario for distribution of 3D real-time content over P2P networks

(detailed view)

Super-Peer

1 3 4 5 12

2 6 7 8 10 11

9

Figure 7 – Scenario for distribution of 3D real-time content over P2P networks

(overlay view)

P2P Packetisation Structure for ROMEO 2.1.4

In ROMEO, the MPEG-2 Transport Stream will be used for encapsulation of encoded

data since DVB-T2 also uses the same encapsulation method. The effective use of

MPEG2-TS built-in Program Clock Reference (PCR) facilitates the synchronisation

task of the streams received from DVB-T2 and P2P network as an addition to the

inherent advantage of synchronisation between video and audio. The generation of

chunks is performed on the encrypted MPEG2-TS packets that contain the encoded

content. These chunks are then distributed over the P2P network.

ROMEO P2P chunks will be small-sized (<MTU size) to avoid IP fragmentation.

Besides, variable sized chunks will be used to support content aware packetisation


scheme which takes into account the data boundaries. According to this scheme each

video frame is sliced during the encoding process into NAL units with variable size

limited by configurable value. Each Network Abstraction Layer Unit (NALU) is

encapsulated into a chunk with a unique ID. Splitting the video frames into more than

one NALU significantly improves the video quality because error concealment at the

decoding process works more efficiently. The resulting packetisation scheme is as in

Figure 8.

Figure 8 – P2P Chunk Structure

During the encapsulation, the data will be separated into different streams to be

distributed over different multicast trees. In two-layered coding using Scalable Video

Coding (SVC), each frame has a base layer bit-stream and an enhancement layer bit-

stream. It is possible to separate the original bit-stream and generate two bit-streams,

one for base and one for enhancement layer. Besides, audio data and depth

information will be considered as different streams as well. In addition, the P2P

header has to include mandatory data, in order to perform data distribution and

synchronisation tasks, as defined on Table 28 in ROMEO D2.2 [3].


3 Peer Components

3.1 P2P

Internet Resource and Admission Control Subsystem (IRACS) 3.1.1

At the peer side, this subsystem consists only of the Resource Controller (RC)

module. The RC module mainly operates in the routers at the ISP network and its

operation is explained in section 4.3.4. In most of the cases, the RC implementation

at the peers will not be needed, since the operator is providing resource reservation

control service and peers are connected through the network. The RC module,

however, can be implemented at peer level to enforce ROMEO application to

guarantee QoS requirements when peers share the same broadcast domain.

Topology Controller (TC) 3.1.2

The Topology Controller (TC) is responsible for establishing the initial connection to

the ROMEO server. It mainly sends and receives control messages from the TB, the

TCs of other peers, the RAM and the UI & Control modules. The TC also has internal

connection (meaning no network messages are exchanged), with the NMS running at

the peer – this relation allows the TC to access network monitoring data and peer

capabilities, relevant for the tree joining process. Figure 9 illustrates the TC building

blocks and its interactions with other components and modules

P2P

Topology BuilderP2P Topology Controller

Tree connectionmanager

QoS manager

P2P

IRACS-RAM

P2P

NMS

P2P

TC (other peers)

internal

(to be defined in D6.2)

309, 312

305, 306307, 313

305,306,307

313,308,1008

309,312

UI & Control 308, 1008

Communications interface

Message numbers defined in ROMEO D2.2

Figure 9 – Topology Controller blocks and interconnections with other ROMEO

components/modules

§ The Tree connection manager block interacts with the TB for requests to join

the overlay. This message would include capability information obtained by

internal query to the NMS module. This block also interacts with the UI &

Control component to allow user interactivity on the selection of parent peer(s)

to connect.

§ The QoS manager block interacts with the RAM every time it needs to connect

to the TC of a parent peer, in order to request the reservation of appropriate

resources for the media stream.

§ The Communications interface block is responsible for all communications

related to either configuring the blocks or sending the indicated control


messages to other components/modules of ROMEO platform. This block

listens on specific TCP and UDP ports, and acts as both server and client.

P2P Depacketisation 3.1.3

This module is responsible for extracting the content which is encapsulated in a form

to be distributed over the P2P network. The chunks received over the P2P network

are generated by P2P Packetisation module on the server. The necessary detail

regarding the packetisation is given in Section 2.1.4. The data decapsulated by

Depacketisation module consists of encrypted NALUs that contain the encoded

content and it is sent to the Decryption module to be decrypted to obtain the encoded

media to be synchronised.

P2P Chunk Selection 3.1.4

This module is responsible for the control of the flow of chunks towards the children

peers in each tree. In addition, chunk selection implements failover mechanisms in

case of missing chunks or short disconnection periods. Chunk Selection module

solves two combinatorial optimisation problems: a) finding a set of missing chunks to

be requested and a corresponding set of peers to be requested from and b) finding a

set of chunks to be forwarded to the children peers.

The following facts are considered:

§ The different importance of chunks. A chunk selection scheme may affect the

number of views, the number of descriptions and the video quality layers

received by a user.

§ Differences and variability of the upstream and downstream capacities of the

peers.

§ Chunks might get lost due to network partitioning or packet losses.

Based on the chunks received through the P2P Transmission/Reception module, the

Chunk Selection populates a buffer map for each tree. The buffer map includes the

received chunks and it is periodically shifted by a predefined period. The end of a

period in the received chunks buffer always precedes the video play-out time.

In case important chunks are missing, the Chunk Selection module tries to retrieve

them from parents in other trees than the tree through which the missing chunks are

supposed to have been delivered through. The criteria for defining the importance of

the chunks are: a) the quality layer to which they belong (lower-layer chunks are more

important than higher-layer chunks); b) the type of frame (IDR frames are crucial in

the decoding process) and; c) the play-out deadline (chunks of which the play-out

time is approaching gain priority). Given a) the downstream capacity of the peer, b)

the upstream capacity of each parent peer and c) the importance of missing chunks,

Chunk Selection exercises a greedy approach to retrieve missing chunks. This

failover mechanism is valuable not only in case of chunk misses but also in case of

short disconnections due to network partitioning induced by churn as a peer can seek

for alternative sources to retrieve important chunks until it is reconnected.

Upon reception of possibly missing chunks within a predefined deadline, the Chunk

Selection module forwards the received chunks to its children in each tree. Given a)


the upstream capacity of the peer, b) the downstream capacity of the children peers,

c) the importance of the received chunks and d) possible requests for missing chunks,

the Chunk Selection module applies a transmission scheme that offers sub-optimal

chunk delivery to the set of children peers in each tree. Figure 10 depicts the

functionalities and an architectural abstraction of the P2P Chunk Selection module,

while Figure 11 presents a flow chart of internal operations.

Tree 1 Tree 2 Tree 3

2

10

2

10

2

10

Request missing chunk

Schedule retrieval of missing chunks

P2P Chunk selection

Schedule forwarding of received chunks

Set of

parents

Missing

chunks

Upstream

of parents

Downstream

of peer

Set of

children

Received

chunks

Upstream

of peer

Downstream

of children

Figure 10 - Conceptual and functional representation of the P2P Chunk Selection

module

Start

Populate

buffer maps

with receiced

chunks

Initialize a buffer

map for each tree

Retrieve network

performance metrics in

the uplink (towards the

children peers) and the

downlink (from the parent

peers)

Identify missing

chunks

Find an optimal combination of

missing chunks to be requested

Chunk missing due to

network partitioning?Inform parentNO

YES

Request chunkProceed to next chunk

Proceed to next buffer period

End of

chunks?NO

Find an optimal combination

of chunks to be forwarded to

children peers

Dictate P2P

Transmission

to transmit

chunks

YES

Receive

requests from

other peers

Figure 11 - Flow chart of the operations performed by Chunk Selection


3.2 Synchronisation

In ROMEO platform synchronisation is required at several places. Simultaneous

reception of content by users requires the following synchronisations to be achieved:

§ Play-out synchronisation

§ Collaborative synchronisation

Play-out Synchronisation 3.2.1

3D content will be delivered through DVB and P2P networks. Multi-view 3D

experience will be achieved by collecting all data from these networks and by

rendering it synchronously on terminals. Play-out synchronisation module will be

responsible from this task. Firstly, it will receive transport stream data from DVB

reception and P2P reception modules. Secondly, it will parse the data as audio and

video content and check their timings with respect to DVB timing information. As a

third phase it will buffer audio and video content separately to send the content to the

related decoders without interruption.

Synchronisation is based on DVB signals. ROMEO platform presumes that DVB will

be always available. As a result, PCR information in DVB will be used as base timing

information for all views. Each view will be delivered with the corresponding timing

information and the synchronisation component will buffer all required data to

synchronise all views.

Transport stream data contains video, audio and metadata information.

Synchronisation block is expected to demultiplex these data and store them

accordingly. Video data from all views will be collected under video buffer whereas

audio data will be collected under audio buffer. All buffered data will be transmitted to

audio and video decoders. Each data packet will be stamped again with proper timing

information. As a result video and audio decoders will also know which packet is for

which timing interval.

Play-out Synchronisation module has several functional blocks to execute particular

tasks and also uses UDP ports for streaming and TCP ports for control

communication. Figure 12 summarises the concept.

§ Communication Interface block is responsible for all communications related

to either configuring the blocks or sending control messages to other

components of ROMEO platform.

§ Stream Input Interface blocks are mainly the front end of Play-out

Synchronisation module. They receive IP packets from DVB reception

component and Decryption component. DVB front end path has an extra block

to extract PCR info from received transport stream. This PCR information will

be used as base timing information through play-out synchronisation module.

§ Demux Block is mainly a demultiplexer to parse audio and video data from all

front ends. Demux block will feed video and audio buffers with active content.

§ Buffers are going to be used as synchronisation elements to keep all users to

have same content at the same time. There are possible risks of buffer

underrun and overrun scenarios. These blocks will have strong


communication with A/V adaptation component of ROMEO to have reliable

and continuous streaming.

§ PCR Sync Block will be the final control point before transmitting streams to

media decoding components. PCR sync uses Collaboration synch delay value

and buffer status. It combines with reference timing information and delivers

Video and Audio elementary streams to stream output Interface block.

§ Stream Output Interface is basically a UDP port for video and audio

elementary streams.

All streaming data will be IP packets with transport Stream (TS) packets as payload at

input side. On the other hand streaming data will be elementary streams on output

side. Besides streaming there will be communication also. These messages will be

Javascript Object Notation (JSON) messages. Coordination with other ROMEO

components will be handled through these messages.

Stream Input

Interface - DVB0507

0305

UI & CONTROL 1002/1003

MEDIA

DECODER

0704

AUDIO

DECODER

VIDEO

DECODER

Communication Interface

DVB Reception

A/V Adaptation 0701 0702

Decryption 1101P2P

A/V

Communication

Overlay

0914

Stream Output

Interface - Video

Demux Block

Stream Input

Interface – P2P

PCR Extract

Block

Video Buffer Audio Buffer

PCR Sync

BlockStream Output

Interface - Audio

Collaborative Sync.

Module

0703

0806

Synchronisation


Figure 12 – Play-Out Synchronisation Blocks

Collaborative Synchronisation 3.2.2

This module will be implemented as a configurable buffer unit between the network

components, P2P transmitter/receiver and DVB receiver, and media decoder units.

To achieve synchronisation among collaborating users, this module inserts delay

calculated by Collaborative Synchronisation Controller unit. This total delay will be

calculated per consumed content and not be changed during the consumption period

of the content.


3.3 A/V Communication Overlay

Video conferencing platform 3.3.1

A/V communication Overlay is going to enable users to enjoy the content with their

friends, family etc... Communication Overlay component will interact with end users

via Video Conferencing platform. Video conferencing platform will be able to:

§ Enable users to join conferences

§ Enable users to create conference

§ Let users share their feelings via audio and video interfaces.

These functionalities require some server-client operations:

§ A machine needs to create a conference to let users join.

§ A/V data of several users need to be collected at a place to share with every

active collaborator.

These kinds of events need a conference level decision. Another conference level

decision is to set a delay for each user to get the content at the same time. This is an

important feature and will enable collaborative usage of the content. Video

conferencing platform will work closely with Collaborative Synchronisation Controller

to achieve the performance level.

Collaborative Synchronisation Controller 3.3.2

This module, which resides in all ROMEO users, will be used to grab the delay

experienced by each collaborating group member. After that, the moderator will

compute the total delay that should be introduced to achieve a synchronous

consumption of the content among collaborating users. PCR will be used as a

reference among users. Then, it will distribute the computed delay to all the

collaborating users so that each user can set an extra delay to the incoming streams.

Depending on this total delay, any collaborating user receives the incoming views

synchronised as long as they are received within the total delay.

3.4 A/V Adaptation & Network Monitor

A/V Adaptation & Network Monitor module is responsible for the audio and video

adaptation management according to the peer’s network conditions and user

interactions. This module is composed of the Audio adaptation and Video adaptation

blocks, the User environment block and the Network Monitoring Subsystem (NMS).

Figure 13 illustrates the A/V Adaptation & Network Monitor building blocks and the

previously mentioned interactions.

§ The Audio and Video Adaptation blocks are responsible for generating

adaptation commands to audio/video decoder and renderers according to the

monitoring data collected by the NMS and the information received by the user

environment and the UI & control module.

§ The User environment provides information on the user environment, such as

the display type and audio capabilities of the peer.


Network Monitoring

Subsystem

P2P

Topology Builder

A/V Adaptation & Network Monitor

Collector&Report

Link tester

P2P

IRACS-RC

A/V Adaptation &

Network Monitor

NMS (other peers)

P2P

TCinternal

(to be defined in D6.2)

314,315

316,319,320,321

314-316,319-321, 913

tbd in D6.2UI & Control 1006,1007

Communications interface

libpcap libraby(monitoring agent)

VideoAdaptation

AudioAdaptation

User environment

1006,1007

A/V Communication

Overlay913

Synchronization806, 701,

702

806

701,702

1006,1007


Figure 13 – A/V Adaptation & Network Monitor blocks and interconnections with other

ROMEO components/modules

§ The Network Monitoring Subsystem collects three types of information: (i) peer

hardware capabilities; (ii) peer stability and; (iii) peer network information

regarding specific peer connections - towards a parent, a child or a super-

peer. For peer hardware capabilities the NMS uses OS specific methodologies

to retrieve such information (system access libraries in Windows or parsing

/proc/cpu(mem)info file in Linux). For the stability computation, the peer

performs the following calculation:

( ) ∑ (√

∑ ( ̅)

) (2)

Where, c refers to a predefined number of connections for which the duration

has to be memorized, represents the connected time for each connection

and ̅ is the mean value for the duration of the c connections. For network

monitoring data the collected information can be related to average delay,

jitter, download and upload bandwidth, packet loss or other, for a specific

destination. To execute such tests, the NMS uses the Link tester function,

which basically uses a set of predefined primitives (included in D6.2 [4]) to test

any established connections. The tests can be performed in the initialization

phase of any connection and also during the reception of the media stream. In

the last case, the NMS uses a monitoring agent that passively collects the

traffic statistics by exploiting the libpcap [2] library, which provides

implementation-independent access to the underlying packet capture facility

provided by the operating system. All monitoring data is collected and

formatted by the Collector&Report function, which then is periodically

uploaded to the peer’s parent or super-peer. The report can also be triggered

by a request or when the changes in the network conditions pass a specific

threshold. Following what was defined in D2.2 [3], to save bandwidth, the


periodic reporting aggregates NMS data from the peer’s children with its own

and then sends the aggregated data to the NMS of its father (peer). This

process goes on until the data gets to a super-peer. This information is then

used by the Topology Builder in the calculation of ACTIVE, READY, and

SLEEP Trees. The report template is expected to use protocol buffers – a

language and platform agnostic, extensible way of serializing structured data

for use in data storage (and others), which produces simpler, faster and

smaller codes then XML. This concept is illustrated in Figure 14. A complete

description of the NMS data structures will be provided in Deliverable 6.2.

Figure 14 – NMS aggregation capabilities – full data structure specifications will be

included in D6.2

§ The Communications interface block is responsible for all communications

related to either configuring the blocks or sending the indicated control

messages to other components/modules of ROMEO platform. This block also

listens on specific TCP and UDP ports, and acts as both server and client.

3.5 User Generated Content

This module will be responsible for user generated content. The main responsibilities

are (i) capturing content via 3D cameras; (ii) uploading the content to the main

content server to register and store; (iii) search/discover user generated content; (iv)

downloading discovered content from main content server. Even though the complete

specification of this module is expected to be provided in deliverable D5.4 (M24), the

following subsections provide a high-level description of its sub-modules.

User Generated Content Capture 3.5.1

This sub-module is responsible for capturing of user generated content. Main source

of user generated content is 3D/2D camera in mobile terminal device. Based on user

interface control actions, raw images and videos are captured, processed using

3D/2D processing algorithms, encoded in appropriate format and stored in internal


mobile terminal device memory. Other sources of user generated content are Internet,

communication channels – DVB, Bluetooth, others - external memory devices, PC or

other external devices. Collected user generated content can later be uploaded to the

main content server.

User Generated Content Upload / Download 3.5.2

This sub-module will be used to upload/download content to/from server. It is tightly

coupled with the security units in uploading and downloading process.

In the uploading process, the captured content will be sent to the main server with the

user name and his/her credentials such as a hash key generated via random

signature shared by the key management unit in the server. Only content with valid

hash keys will be uploaded to the server.

In downloading process, user sends the ID of content that he/she requests with

his/her credentials. After checking the credentials, based on the rights given to the

requesting user, the server lets ROMEO user to download the requested content.

User Generated Content Register and Store 3.5.3

This module is responsible for registering and storing the valid content, meaning that

the content uploaded with valid hash keys, to the server. It will store the files on a

specific folder inside the file system of the server whereas the registry information,

which includes the ID, location on the server and required rights to all ROMEO users,

will be stored on a local database inside the server.

User Generated Content Search and Discovery 3.5.4

This module is implemented for ROMEO users to be able to search content in the

server. Based on the search results and authorization rights, the ROMEO user

downloads the content.


4 Network-related Components

4.1 Mobility

Within the ROMEO architecture the Mobility module is regarded as a network related

module, responsible for ensuring seamless 3D video service continuity to mobile and

portable users across heterogeneous radio access networks. In addition, the Mobility

module is required to guarantee minimum QoE levels and ensure high quality of 3D

video perception to the mobile and portable users whenever the networking

conditions allow it, while the user roams between networks. The support of a QoE

driven mobility across heterogeneous wireless networking environments requires a

framework that incorporates the monitoring of link layer, network layer and application

layer specific parameters, as well as, an intelligent handover decision making policy.

Towards this end, the Mobility module has been designed as a synergy of Media

Aware Proxy (MAP), an enhanced version of IEEE’s 802.21 Media Independent

Handover (MIH) framework and a Proxy Mobile IP (PMIP) scheme. Figure 15

illustrates the components and functionalities residing in the Mobility module.

Mobile User

IP Traffic

Mobility Module

Proxy MIP

Enhanced MIHMedia Aware Proxy

Packet Receiver

Parsing /Filtering

Packet Forwarding

Radio Resource Management

Handoff Decision

Handoff Execution

LINK G

LINK ALINK D

LINK C

Database

LINK B

LINK F

LINK E

Home Agent

LTEWiFi 1 WiFi 2

Proxy Mobility Agent



Figure 15 Mobility module functional blocks and Information flow


The above figure shows the internal components of the Mobility module along with

their interconnections. Specifically:

§ Link A – Application Layer information and streaming parameters including the

bit rate, View_ID, Client_ID, source and destination IPs are stored in the

database (DB).

§ Link B – Physical Layer parameters and information is stored in the DB. The

best available access network is also suggested by the Radio Resource

Management (RRM) criteria and on the type of network interfaces that the

user has on its mobile terminal (MT).

§ Link C – The information that was made available in the database through

Links A and B, is now made available for the Handoff decision function.

§ Link D – The Handoff decision stores in the database new information

regarding the video adaptation decision (drop or forward specific packets),

based on the conditions of the target network and the streaming parameters.

§ Link E – The information made available in the database through Link D is

now made available for the filtering process of the MAP.

§ Link F – MIH triggers PMIP by issuing a Handover execution trigger directly to

the Local Mobility Anchor (LMA)/Home Agent.

§ Link G – MAP forwards the IP traffic to the PMIP.

A detailed analysis of the processes and algorithms involved in each component of

the Mobility module follows.

Media Aware Proxy 4.1.1

Media Aware Proxy acts as a transparent proxy of the P2P mobile client. Its

functionality extends from the Network layer to the Application layer. It is responsible

for receiving the IP packets that are destined for all mobile users over multiple ports.

Each received packet is forwarded in a queue and its header is parsed in order to

identify the information described on Table 28 in ROMEO D2.2 [3], but without

changing the header’s fields. The information is stored in a database, which is in fact

the MIH Information Service Database. MAP is responsible for regularly updating the

database with all client IDs (i.e. number of views, incoming data rate, etc.). These

updates will render the Handover Decision function of the MIH able on deciding

whether a handover is required based on timely information. From the same database

the MAP will read the flag regarding its filtering procedure. Therefore in case of a

handover to a new network, MAP (based on MIH output) will either drop packets that

carry specific views or forward them to the PMIP in order for them to be routed to the

receiving user.

It is important to underline the fact that the whole process is running at kernel level,

hence it is very quick and contributes very little to the overall end-to-end delay. Figure

16 shows an abstract level of the algorithmic process followed by MAP.


MIIS

Database

(DB)

Receive IP packet

Parse Headers

(IP, UDP, Chunk, NAL)

Write to MIIS DB

(Refresh information

regarding View_ID, Bit-

Rate, etc)

Read MIIS DB

(Drop Flag ON/OFF

Filtering Process

(Drop Packet)ON

Filtering Process

(Forward Packet)OFF

Repeat Process for each received packet

Proxy MIP

(Tunneling/ Routing)

Figure 16 – Flowchart datagram of the Media Aware Proxy

Media Independent Handover 4.1.2

IEEE has proposed IEEE 802.21 standard to enable handover and interoperability

between heterogeneous networks with context-awareness in mobile terminals [13].

One of the main ideas behind IEEE 802.21 is to provide a common interface for

managing events and control messages exchanged between networks devices that

support multiple interfaces, both wired and wireless as depicted in Figure 17. The

contribution of Media Independent Handover framework is centred on the following

objectives:

§ Inter-System Handover: The mobile node will be capable of performing vertical

and horizontal handovers between heterogeneous wireless access

technologies. The handover may be triggered / initiated either by the mobile

node or the access network. ROMEO considers only the second option of

system initiated handovers.

§ Seamless handover-service continuity: One of the main objectives of MIH

functionality is the continuation of the service during and after the handover

procedure.

§ Support for Multi-homing: Tackles issues regarding multi-interface operation

and application as well as flow mobility.

§ QoS aware handover: Provides QoS guarantees for both best effort and real-

time traffic. This is accomplished by determining the available bandwidth at

each access network.

§ QoE and session characteristics adaptation: Upon a handoff, session

characteristics may be updated to improve the perceived QoE of the video

streaming.


IEEE 802.21 MIH Function

Application

Connection Management

Handover Policy

Handover Management

Mobility Management Protocols

IETF

SmartTriggers

HandoverMessages

Information Services

Protocol and Device Hardware

WLAN Cellular WMAN

L2 Triggers & Events Handover Messages Information Service

IEEE 802.21

Link Layer TriggersState Change

Predictive Network Initiated

Network InformationAvailable Networks

Neighbor MapsNetwork Services

Handover CommandsClient Initiated

Network InitiatedVertical Handovers

Figure 17 IEEE 802.21 Media Independent Handover framework

In IEEE 802.21 multiple services are deployed to optimize handovers and Link Layer

intelligence and other network related information is provided to upper layers. The

services provided by MIH framework include:

§ Media Independent Event Service (MIES) – Detects and delivers triggers from

both local and remote interfaces corresponding to dynamic changes in link

characteristic, status and quality.

§ Media Independent Command Service (MICS) – Enables higher layers to

control lower layers (physical, link layer). Higher layers may control the

reconfiguration or selection of an appropriate link through a set of handover

commands.

§ Media Independent Information Service (MIIS) – Provides a framework and

corresponding mechanisms for discovering and obtaining information of

existing networks able to facilitate handovers. The MIIS provides link layer

parameters such as channel information, MAC address, etc.

The MIH function and its relationship with upper and lower layer elements are shown

in Figure 18.

Upper Layers(IP, MIP, Transport, Application)

MIH Function

MIES

MICS

MIIS

Lower Layers(802.11, 802.16, 3G, LTE)

MIE

S

MIC

S

MII

S

Figure 18 - Media Independent Handover key services


The Handover Decision function is illustrated in Figure 19. The decision is based on

network related information stored in the MIIS Database, as well as, information

collected from the Chunk headers of the received streams, as shown in Figure 16.

The MIIS database lies in the heart of the Mobility module. It constantly updated by

the MAP and the Radio Resource Management entities. In ROMEO two distinct

handover decisions are defined.

· Handover Hard Decision – is initiated when there is no other way than to

perform a horizontal or vertical handover. Such case is when the received

Signal to Noise Ratio has dropped below a predefined threshold. MIES

indicates the occurrence of such an event and the MIH function invokes the

handover decision process.

· QoE Driven Handover Decision – on the other hand handover may occur

when a Network Layer parameter (i.e. packet loss, delay, etc.), or an

Application Layer parameter (i.e. additional views become available, etc.)

exceed predefined thresholds. This handover decision is based on upper layer

information, hence is an extension to the standard IEEE 802.21 framework

and will ensure high QoE to the mobile and portable user by connecting the

user to the best network available.

Collect Radio Network Information

Refresh Information of Corresponding

Tables

Database

Read DatabaseUser Table

Current SNR < ThresholdHandover Hard

DecisionYES

Select Target Network

Define Link

Update Database

Trigger Proxy MIP

Network/Application Layer Parameters < Threshold

QoE Driven Handoff Decision

YES

Select Target Network

Define Link

NO

NO

UpdateDatabase

SNMP trapsFrom Access

Networks

Figure 19 - Preliminary flow chart diagram of the enhanced MIH function


In both cases, a Link Selection process is initiated after the handover decision in

order to select the specific link of the candidate network that the mobile user will be

using after the execution of the handover. The database is updated and handover

flags signal the MAP to perform filtering (video view and/or layer adaptation), while in

the same time a specific trigger is sent directly to the PMIP, in order to create the

tunnelling and execute the handover.

Proxy Mobile IP (PMIP) 4.1.3

This component is responsible to support IP Mobility for ROMEO mobile end users.

The involved entities in the PMIPv4 [12] domain are the Home Agent (HA) and the

Proxy Mobility Agent (PMA). The HA receives the 3D content delivered through P2P

and filtered by MAP on the ingress interface. A bi-directional tunnel between the HA

and the PMA allows packets to flow to the network where the Mobile Node (MN)

resides. The PMA de-capsulates any packets received on the tunnel from the HA

before forwarding to the MN on its link. The HA keeps a list of the mobility bindings

(i.e. MN – Visited Network) for every MN and updates the established tunnels based

on the MN’s location. Figure 20 illustrates the basic functionality of the PMIP.

Register to PMIP Domain

Update Mobility Binding List

Establish Tunnel

Packet Forwarding

Handover Execution TriggerOR

Update Binding

YES

NO

Figure 20 Preliminary flow chart diagram of Proxy Mobile IP scheme

Moreover, PMIP interacts with MIH component to support fast handover procedure

and seamless IP Mobility across the heterogeneous ROMEO platform. The handover

decision function sends a message which acts as a network-initiated handover trigger

to the new PMA to which the MN is moving to. In response, the new PMA sends a

Registration message to the HA to update the MN’s mobility binding entry and

establish the new tunnel. After completing these tasks HA informs the PMA about the

successful handover by sending an Acknowledgement message.


Within the context of ROMEO requirements, efficient techniques will be implemented

to ensure seamless video streaming to the MN. Specifically, packets destined to the

MN will be buffered during the handover procedure and will be delivered upon the

completion of the handover. Additionally, fast handover techniques will be exploited to

minimize handover delay by anticipating a handover and performing the PMIP

handover process before the establishment of the new link. As a result, IP-layer

procedures will not affect the perceived handover performance which will depend only

on the link layer operations. Finally, PMIP will allow a MN to get the video stream

through different wireless interfaces. New functionalities will extent the basic PMIP to

support multi-homing and enable a per flow routing at the HA.

4.2 Virtualisation

Virtualisation Platform 4.2.1

The virtualisation solution is employed within the ROMEO platform to reduce the

number of devices needed in the residential environment for the service delivery and

to reduce the number of incidences produced by these devices. Aiming a L2 access,

the functionalities performed by the current Residential Gateway (RGW) are shifted to

the access network. L3 related functionalities are shifted to the IP edge node and

execution capabilities are tackled by a Virtual Software Execution Environment

(VSEE) located in the Metropolitan Area Network (MAN).

The virtualisation platform includes the following modules in the access network:

§ Dynamic Host Configuration Protocol (DHCP) Server: this module is

responsible for the IP address allocation to all devices connected to the

Ethernet ports of the Optical Network Termination (ONT). All devices, no

matter what kind of service is envisaged to that particular device, will receive

an IP address belonging to the same addressing scheme. In addition, an

overlapped addressing scheme will be used to allocate the subnet

192.168.0.0/24 to all households.

§ Network Address Translation Implementer Equipment (NATIE): the IP edge

node, which acts as a Broadband Remote Access Server (BRAS) is

responsible for hosting the shifted L3 functionalities. A Virtual Routing

Forwarding (VRF) table will be set up for each household for routing purpose.

Network Address Translation (NAT) rules will be set up to differentiate the

service that is to be accessed.

§ VSEE: the VSEE is located in the MAN and is responsible for hosting the

execution capabilities that currently run within the RGW. Each virtual

environment instance within the VSEE will have a virtual network interface. In

order to differentiate user traffic from different households, each virtual

interface will be associated to a specific VLAN.

ROMEO QoS Enforcement 4.2.2

The QoS solution is employed within the ROMEO platform to ensure that the user

perception meets the expected QoE for all services subscribed to the residential

environment.


This solution will be provided using two modules: a Policy and Charging Enforcement

Function (PCEF) and a Policy and Charging Rules Function (PCRF):

§ PCEF: this module will be responsible for the QoS enforcement within the IP

edge node. In that case the PCEF module will be embedded within the NATIE.

§ PCRF: this module is responsible for defining the QoS rules that will be

applied to a particular user. It receives from the Topology Builder the physical

parameters that identify a certain user and communicates with the PCEF

(NATIE) in order to enforce the rules in the access network.

4.3 Internet Resource and Admission Control Subsystem (IRACS)

At the network side, the IRACS implements the RAM functionalities by embedding

four different modules at the ISP routers, a Control Information Base (CIB), an

Admission Control Subsystem (ACS), a Resource Reservation Subsystem (RRS) and

a Resource Controller (RC). Descriptions of these modules are given in sections 4.3.1

to 4.3.4. An explanation of how such modules operate at network initialization and

operation phases is given in sections 4.3.5 and 4.3.6 respectively.

Control Information Base (CIB) 4.3.1

The CIB is used by the RAM to maintain a good knowledge of underlying network

topology and the related resource statuses. It stores the ID of every existing multicast

tree and the IDs of the outgoing interfaces on the tree inside a network. Moreover, it

maintains the total capacity, the amount of bandwidth reserved and used in each

Class of Service (CoS) on each outgoing interface as well as active sessions’

information (e.g., Bandwidth, session ID, flows IDs, source ID, destination ID , ports

IDs, CoS ID, associated multicast tree’s ID and multicast channel).

Resource Reservation Subsystem (RRS) 4.3.2

RAM exploits the RRS to create and manage bandwidth-aware multicast trees to

connect peers inside a network under its control. It includes an aggregate bandwidth

over-reservation control scheme to dynamically define appropriate resource sharing

policies among various CoSs on each outgoing interface on trees upon need.

Aggregate over-reservation means that a CoS may be reserved more bandwidth than

it currently requires, according to the control policies, while traffic flows that belong to

a CoS must share the reservations destined to that CoS. This approach is used to

prevent excessive QoS control signalling, states and processing overhead to achieve

scalability and to reduce session setup time as well. Moreover, CoS starvation is

avoided by a proper readjustment of reservation parameters of CoSs dynamically

upon need, such that the performance is achieved without wasting resources.

Admission Control Subsystem (ACS) 4.3.3

The ACS enables RAM to accept or reject service requests to a network, depending

on the service requirements and the network resource availability on existing

multicast trees recorded in the CIB local database. For this purpose, the RAM

provides interface to receive service demands from the ROMEO server, super peer or

peers, and records active sessions’ information in the CIB. Whenever a service is

admitted, terminated or QoS requirements of a running flow are readjusted in a CoS


on a tree, the RAM implementing the admission process automatically updates the

resource status (e.g., the reservations and the bandwidth usage) on the related

outgoing interfaces in the local CIB without signalling the nodes in the network under

its control as long as the concerned over-reservation is not exhausted.

Resource Controller (RC) 4.3.4

The RC module implements elementary transport functions to enable UDP port

recognition (routers are permanently listening on a specific UDP port) or IP Router

Alert Option (RAO) [8] on nodes to properly intercept, interpret, process control

messages, and to assure QoS-aware data transport across a network. It interacts with

Resource Management Functions (RMF) [9] to configure schedulers on nodes [6][7]

to assure that each CoS receives the amount of bandwidth allocated to it. Moreover, it

interfaces with legacy protocols (e.g., routing protocols) and exploits appropriate

databases on nodes upon need, e.g., Management Information Base (MIB), Routing

Information Base (RIB) or multicast Routing Information Base (MRIB), Forwarding

Information Base (FIB), according to the control instructions received from RAM. The

RC is also used to enforce multicast trees on nodes on a tree. An example is: the RC

allows control messages to collect the IDs of outgoing interfaces and the interface

capacities on trees as Record Route Object (RRO) [10][11]. It also enables nodes to

record, upon instructions conveyed in control messages, the ID of the previous

outgoing interface visited by the message, and thus assists to avoid asymmetric route

issues in reverse direction of trees [5]. This way, the RC module only implements

basic functions required in all routers and control complexity is pushed to network

control decision points, leaving core nodes simpler for scalability reasons.

The interactions between RAM and RC modules during network initialization or

network operating phases to assure a proper QoS-aware service transport are

detailed in subsections (4.3.5) and (4.3.6) respectively.

Network Initialization Phase Management 4.3.5

At network initialization, when nodes boot up, the RAM gets network topology

information by either importing such information from existing (resident) link state

routing protocols or by using an IRACS flooding mechanism. The RAM then

computes all possible edge-to-edge routes inside the network under its control, and

selects the best routes that can be used for service delivery. A route can be selected

based on its number of hops and bottleneck capacities. Afterwards, the RAM signals

each route with a unique multicast channel (S, G) where S is the ID of the source

edge router in the control domain and G is the IP multicast address allocated by the

RAM. When the control message is travelling on a route, every visited router exploits

its RC module and configures its local multicast routing table accordingly. Source

routing is used with RRO to force each control message to follow a desired route so

that multicast trees and multicast replicators are properly enforced in the network at

the initialization phase. Also, every router configures initial resource over-reservation

parameters for each CoS on each of its outgoing interfaces. This way, each edge-to-

edge route is initialized as an un-branched bandwidth-aware tree while a combination

of edge-to-edge routes leads to branched bandwidth-aware trees. In a pure

centralized scenario, a single RAM maintains knowledge on the entire network and


related trees. In a hierarchical control scenario, an end-to-end route may be a

concatenation of trees from each of the domains that lie on the route. In such

scenario, each RAM maps traffic to its local trees independently of the other RAMs

and a packet from one end to another must be encapsulated at the entrance and

decapsulated at the exit of each network domain on its route. This way, it is ensured

that packets will be pinned to desired routes so they receive the bandwidth reserved

to them.

Network Operating Phase Management 4.3.6

As the network is initialized and set to run, every QoS-sensitive service request is

sent to a local RAM. This implies that best-effort services may not be subject to such

admission control, depending on local control policies. Hence, when a RAM receives

a request and realizes that there is sufficient over-reservation on its candidate trees, it

checks its admission to true and automatically forwards the request to the RAM in the

next network domain on the route. Otherwise, the RAM invokes the RRS over-

reservation scheme to decide new reservation parameters readjustment policies

based on the resource information in its local CIB database. In case reservation

readjustment computation is successful, it signals the relevant local tree with the new

parameters which are enforced by the RC on the nodes on the trees. This way, each

RAM is able to dynamically readjust reservation parameters and to prevent CoS

starvation or waste of resources and end-to-end admission is granted only when a

minimum required bandwidth is available in all domains on a route. When existing

resource is not enough to admit a service in a domain, the request is denied or

mapped to a lower QoS CoS according to the Service Level Agreements (SLAs)

between the provider and the customer. This way, an admission control decision

process is fast and scalable since it does not always involve reservation signalling

messages while reservation states are maintained aggregately.


5 CONCLUSIONS

This deliverable has presented an interim report on 3D media networking and

synchronisation of networks. As such, it has focused on ROMEO components related

with networking operations only. Since this is the first deliverable within WP5, a high-

level description of each component and their modules are presented and for some of

these modules, interim technical details on their operation are also provided.

Tasks related with Synchronization and A/V Communication Overlay components at

peer side, and Virtualization component at network side, will be further updated and

more details on these components are expected in next WP5 deliverables.

The task related with the User Generated Content component has not yet started;

nevertheless this report has provided the first guidelines and ideas towards its

functionality and modules.

This document will be used as reference document for next WP5 deliverables.


6 REFERENCES

[1] Moi, J., “OSPF version 2”, RFC2328, Abril 1998.

[2] The libpcap project. url: http://sourceforge.net/projects/libpcap/

[3] ROMEO Deliverable 2.2, “Definition of the initial reference end-to-end system

architecture and the key system components”; 2011;

[4] ROMEO Deliverable 6.2, “First Report on server, peer, user terminal, security

and content registration modules development”; 2012

[5] R. Braden, L. Zhang, S. Berson, S. Herzog, “Resource ReSerVation Protocol

(RSVP) --Version 1 Functional Specification”, RFC 2205, Sept. 1997.

[6] A. Demers, S. Keshav, S. Shenker; “Analysis and simulation of a fair queueing

algorithm”, ACM SIGCOMM’89, V.19, Pages 1-12.

[7] S.J. Golestani; “A self-clocked fair queueing scheme for broadband

applications”, INFOCOM’94, Networking for Global Communications, Vo. 2,

Pages: 636-646, Canada.

[8] D. Katz, “IP Router Alert Option”, RFC 2113, February 1997.

[9] R. Hancock, G. Karagiannis, J. Loughney, S. Van den Bosch; “Next Steps in

Signaling (NSIS): Framework”, RFC 4080, June 2005.

[10] Manner, J., Karagiannis G., A. McDonald; “NSLP for Quality-of-Service

Signaling”, draft-ietf-nsis-qos-nslp-16 (work in progess), February 2008.

[11] J.-P. Vasseur, Z. Ali, S. Sivabalan; “Definition of a Record Route Object (RRO)

Node-Id Sub-Object”, RFC 4561, June 2006.

[12] K. Leung, G. Dommety, P. Yegani, K. Chowdhury,” WiMAX Forum / 3GPP2

Proxy Mobile IPv4”, RFC5563, February 2010

[13] IEEE 802.21-2008, “IEEE Standard for Local and Metropolitan Area Networks—

Media Independent Handover Services”, January 2009

http://sourceforge.net/projects/libpcap/


7 APPENDIX A: GLOSSARY OF ABBREVIATIONS:

A

AAC Advanced Audio Coding

ACS Admission Control Subsystem

ALSA Advanced Linux Sound Architecture

AP Access Point

AVC Advanced Video Coding

AU Access Units

A/V Audio-Visual

B

BRAS Broadband Remote Access Server

C

CIB Control Information Base

CLD Channel Level Differences

CPC Channel Prediction Coefficients

CPE Consumer-Premises Equipment

CPU Central Processing Unit

CoS Class of Service

CUDA Computer Unified Device Architecture

D

DBIR Depth based Image Rendering

DHCP Dynamic Host Configuration Protocol

DPX Digital Picture Exchange

DVB Digital Video Broadcasting

DB Database

E

eNodeB Enhanced Node B

ER Edge Router

ES Elementary Stream

F

fps Frames per Second

FTTH Fiber to the Home


G

GbE Gigabit Ethernet

GOP Group of Pictures

GPL General Public license

GPON Gigabit Passive Optical Network

GPU Graphics Processing Unit

GUID Global Unique Identification

H

HA Home Agent

HD High Definition

HDMI High Definition Multimedia Interface

HGW Home Gateway

I

ICC Inter-channel Coherences

IEEE Institute of Electrical and Electronics Engineers

IP Internet Protocol

IRACS Internet Resource and Admission Control Subsystem

ISP Internet Service Provider

J

JSON-RPC Javascript Object Notation – Remote Procedure Call

K

L

L2 Layer 2 (LLC and MAC level)

L3 Layer 3 (Routing, IP level)

LAN Local Area Network

LGPL Lesser General Public license

LMA Local Mobility Anchor

LTE Long Term Evolution

M

MAG Mobile Access Gateway

MAN Metropolitan Area Network

MANE Media Aware Network Element

MAP Media Aware Proxy

MIH Media Independent Handover

MIP Mobile IP

MME Mobility Management Entity


MN Mobile Node

MPEG Motion Picture Experts Group

MPS MPEG Surround

MTM Multicast Tree Management

N

NACF Network Atachment Control Functions

NALU Network Abstraction Layer Unit

NAT Network Address Translation

NATIE Network Address Translation Implementer Equipment

NCDP Network Control Decision Point

NMS Network Monitor SubSystem

NTFS New Technology File System

O

OLT Optical Line Terminator

ONT Optical Network Termination

OS Operating System

P

P2P Peer-to-Peer

PCEF Policy and Charging Enforcement Function

PCM Pulse Coded Modulation

PCR Program Clock Reference (MPEG2-TS related)

PCRF Policy Charging and Rule Function

PES Packetised Elementary Stream

PMA Proxy Mobile Agent

PMIP Proxy Mobile IP

Q

QoE Quality of Experience

QoS Quality of Service

R

RAM Resource and Admission Manager

RC Resource Controller

RF Radio Frequency

RGW Residential Gateway

RRM Radio Resource Management

RRS Resource Reservation Subsystem

RTP Real Time Protocol


S

SBC Session Border Controller

SDI Serial Digital Interface

SDL Specification and Description Language

SI Service Information

SIP Session Initiation Protocol

SLA Service Level Agreements

SNR Signal to Noise Ration

SVC Scalable Video Coding

T

TB Topology Builder

TC Topology Controller

TCP Transmission Control Protocol

TS Transport Stream

U

UDP User Datagram Protocol

UI User Interface

UMTS Universal Mobile Telecommunications System

USB Universal Serial Bus

V

VCL Video Coding Layer

VoDSAR Video on Demand Service Access Router

VRF Virtual Router Forwarding

VSEE Virtual Software Execution Environment

W

WFS Wave Field Synthesis

WiFi Wireless Fidelity

WLAN Wireless - LAN

X

Y

Z

Numbers

Documents

Remote Collaborative Real-Time Multimedia Experience … · virtualisation. 1.2 Scope of the ... that is responsible for network access and resource allocation to support IP ... routers