Warenkorb
0 Artikel | US$ 0,00
Contents
IV
5.1.4.3
msas rtcp send . . . . . . . . . . . . . . . . . . . . . . . .
61
5.1.5
Receive RTCP messages . . . . . . . . . . . . . . . . . . . . . . . .
62
5.1.6
Parse content of an XR report block
. . . . . . . . . . . . . . . . .
63
5.1.7
Get pointer to the content of an XR IDMS report block . . . . . . .
63
5.1.8
Parse RTCP payload . . . . . . . . . . . . . . . . . . . . . . . . . .
64
5.1.9
Insert content into linked lists . . . . . . . . . . . . . . . . . . . . .
65
5.1.9.1
push to timestack
. . . . . . . . . . . . . . . . . . . . . .
65
5.1.9.2
insert ts to tcs . . . . . . . . . . . . . . . . . . . . . . . .
66
5.1.9.3
insert into tcs . . . . . . . . . . . . . . . . . . . . . . . . .
67
5.1.9.4
set tcs item . . . . . . . . . . . . . . . . . . . . . . . . . .
67
5.1.9.5
msas session add client . . . . . . . . . . . . . . . . . . . .
68
5.1.9.6
msas session insert tcs item . . . . . . . . . . . . . . . . .
69
5.1.9.7
msas session insert tcs item msci . . . . . . . . . . . . . .
70
5.1.10 Get contents of linked lists . . . . . . . . . . . . . . . . . . . . . . .
71
5.1.10.1 get item from timestack . . . . . . . . . . . . . . . . . . .
71
5.1.10.2 get item from tcs . . . . . . . . . . . . . . . . . . . . . . .
71
5.1.10.3 get last item from tcs . . . . . . . . . . . . . . . . . . . .
72
5.1.10.4 msas session get clients
. . . . . . . . . . . . . . . . . . .
72
5.1.10.5 msas session get client by ssrc . . . . . . . . . . . . . . . .
72
5.1.10.6 msas session get client by msci . . . . . . . . . . . . . . .
73
5.1.10.7 msas session get tcs item
. . . . . . . . . . . . . . . . . .
73
5.1.10.8 msas session get last tcs item . . . . . . . . . . . . . . . .
74
5.2
Media Delivery Function - RTP-sender part
. . . . . . . . . . . . . . . . .
75
5.2.1
GStreamer Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
5.2.2
Thread for media encoding . . . . . . . . . . . . . . . . . . . . . . .
76
5.2.3
Graphical user interface
. . . . . . . . . . . . . . . . . . . . . . . .
77
5.2.4
RTP-sender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
5.2.5
Primary function of the application . . . . . . . . . . . . . . . . . .
79
5.3
Media Delivery Function - MSAS part
. . . . . . . . . . . . . . . . . . . .
80
5.3.1
Graphical user interface
. . . . . . . . . . . . . . . . . . . . . . . .
80
5.3.2
RTCP server thread
. . . . . . . . . . . . . . . . . . . . . . . . . .
81
5.3.3
Primary function of the application . . . . . . . . . . . . . . . . . .
83
5.4
SC application on user side . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
5.4.1
GStreamer Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
5.4.2
Callback function for starting IPTV-Session . . . . . . . . . . . . .
85
5.4.3
Callback function for terminating IPTV-Session . . . . . . . . . . .
85
5.4.4
Function for starting the Decoder . . . . . . . . . . . . . . . . . . .
86
5.4.5
RTP receiver
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
5.5
SC application on provider side . . . . . . . . . . . . . . . . . . . . . . . .
88
5.5.1
RTP receiver
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
5.5.2
RTP sender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
5.5.3
Graphical user interface
. . . . . . . . . . . . . . . . . . . . . . . .
91
5.5.4
Primary function of the application . . . . . . . . . . . . . . . . . .
92
5.6
Transcoder application . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
Contents
V
5.6.1
GStreamer Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
5.6.2
RTP receiver
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
5.6.3
RTP sender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
5.6.4
Media transcoder . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
5.6.5
Graphical user interface
. . . . . . . . . . . . . . . . . . . . . . . .
96
5.6.6
Primary function of the application . . . . . . . . . . . . . . . . . .
97
5.7
Multistream source transcoder . . . . . . . . . . . . . . . . . . . . . . . . .
98
6
Evaluation
100
6.1
Evaluation of the protocol implementation . . . . . . . . . . . . . . . . . . 101
6.2
Evaluation of the applications . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.2.1
Timestamp estimation . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.2.2
Measuring using one PC . . . . . . . . . . . . . . . . . . . . . . . . 105
6.2.3
Measuring using two PC . . . . . . . . . . . . . . . . . . . . . . . . 106
6.2.4
Measuring between two clients using VLC . . . . . . . . . . . . . . 107
6.2.5
Measuring the IDMS implementation . . . . . . . . . . . . . . . . . 108
6.2.5.1
Measurment with enabled pausing
. . . . . . . . . . . . . 108
6.2.5.2
Measurment with disabled pausing . . . . . . . . . . . . . 111
6.2.5.3
Synchronization of two SC on one PC
. . . . . . . . . . . 112
7
Conclusion and Future Work
117
7.1
The IDMS implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
7.2
Recomandations for the protocol description . . . . . . . . . . . . . . . . . 117
7.3
Possible Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.3.1
Library
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.3.2
Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.3.3
RTP-Sender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.3.4
Transcoder
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.3.5
MSAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
7.4
Research questions for future work
. . . . . . . . . . . . . . . . . . . . . . 119
Bibliography
v
Declaration
vi
VI
Glossary
Notation
Description
3GPP
3rd Generation Partnership Project
A
Authentication
AAC
Advanced Audio Coding
AS
Application Server
BC
Broadcast Session
BGCF
Breakout Gateway Control Function
CoD
Content on Demand
CRS
Content Recommendation Services
CSCF
Call Session Control Functions
CSRC
Contributing Source Identifier
CSV
Comma-Separated Values
DLRR
Delay Since Last Receiver Report Block
DLSR
Delay Since Last Sender Report
DVB
Digital Video Broadcast
DVB-C
Digital Video Broadcast - Cable
DVB-T
Digital Video Broadcast - Terrestrial
DVD-S
Digital Video Broadcast - Satellite
ECF
Elementary Control Function
EFF
Elementary Forwarding Function
ETSI
European Telecommunications Standards Institute
FT
Feedback Target
Glossary
VII
Notation
Description
GSL
GNU Scientific Library
GUI
Graphical User Interface
HD
High Definition
HSS
Home Subscriber Server
HTTP
Hypertext Transfer Protocol
I-BGF
Interconnect Border Gateway Function
I-CSCF
Interrogation - Call Session Control Functions
IDMS-RB
Inter Destination Media Synchronization Report
Block
IMS
Internet Protocol Multimedia Subsystem
IMS MGW
Internet Protocol Multimedia Subsystem Media
Gateway
IP
Internet Protocol
IPTV
Internet Protocol Television
LSR
Last Sender Report
MCF
Media Control Functions
MDF
Media Delivery Function
MF
Media Function
MGCF
Media Gateway Control Function
MPEG
Moving Picture Experts Group
MPEG-TS
Moving Picture Experts Group - Transport Stream
MRF
Media Resource Function
MRFC
Media Resource Function Controller
MRFP
Media Resource Function Processor
MS
Media Sender
MSAS
Media Synchronization Application Server
MSCI
Media Stream Correlation Identifier
Glossary
VIII
Notation
Description
NGN
Next Generation Networks
NTP
Network Time Protocol
NTP TS
Network Time Protocol Time Stamp
OWD
One-Way Delay
P-CSCF
Proxy - Call Session Control Functions
PC
Personal Computer
PRACK
Provisional Response Acknowledgment
PT
Payload Type
PTP
Precision Time Protocol
PVR
Personal Video Recorder
QoE
Quality of Experience
QoS
Quality of Service
RR
Receiver Report
RRT
Receiver Reference Time Report Block
RSI
Receiver Summary Information
RTC
Real Time Clock
RTP
Real-Time Transport Protocol
RTP TS
RTP Timestamp
RTSP
Real Time Streaming Protocol
RTT
Round Trip Time
S-CSCF
Serving - Call Session Control Functions
SC
Synchronization Client
SC'
Transcoder
SCF
Service Control Function
SD
Standard Definition
SDES
Session Description
SDF
Service Discovery Function
SDH
Synchronous Digital Hierarchy
Glossary
IX
Notation
Description
SDP
Session Description Protocol
SIP
Session Initiation Protocol
SLF
Service Locator Function
SPST
Synchronization Packet Sender Type
SR
Sender Report
SS#7
Signaling System No. 7
SSF
Service Selection Function
SSRC
Synchronization Source Identifier
TAI
Targeted Advertisement Injection
TCS
Time Correlation Stack
TISPAN
Telecommunications and Internet Converged Ser-
vices and Protocols for Advanced Networks
TNO
Nederlandse organisatie voor toegepast natuurweten-
schappelijk onderzoek
UA
User Agent
UE
User Equipment
UPSF
User Profile Server Function
VLC
Video Lan Client
VLM
Video Lan Media Server
VoIP
Voice over Internet Protocol
XML
Extensible Markup Language
X
Nomenclature
i
number of the client
n
amount of clients
RT P T S
11i
RTP timestamp of the first packet used for approximation
RT P T S
12i
RTP timestamp of the second packet used for approximation
RT P T S
1i
RTP timestamp that belongs to the time that is approximated
RT T
1i
RT T
i
of first packet used for approximation
RT T
2i
RT T
i
of second packet used for approximation
t
11i
t
1i
of first packet used for approximation
t
12i
t
1i
of second packet used for approximation
t
0
time of send the RTP-packet by media server
t
2
time of send SR
1
in multicast mode to the clients
t
6
time of send SR
1
in unicast mode to MSAS
t
7
time of reception of SR
1
by MSAS
t
1i
time of reception the RTP-packet by Client
i
t
3i
time of reception of SR
1
by Client
i
t
4i
time of send RR
1
by Client
i
t
5i
time of reception of RR
1
by MSAS sent by Client
i
XI
List of Figures
2.1
TCP/IP-stack and the protocols for IPTV . . . . . . . . . . . . . . . . . .
6
2.2
Typical clock synchronization using NTP[6]
. . . . . . . . . . . . . . . . .
7
2.3
NTP frame[6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.4
Basic message format of the Session Initiation Protocol[7, page 264] . . . .
9
2.5
SDP contents for a TV session . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.6
RTP frame [14, 15] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.7
Frame structure for mpeg-ts frames [16] . . . . . . . . . . . . . . . . . . . .
12
2.8
RTCP-message: Sender Report[14]
. . . . . . . . . . . . . . . . . . . . . .
13
2.9
RTCP-message: Receiver Report[14]
. . . . . . . . . . . . . . . . . . . . .
14
2.10 RTCP-message: Session Description[14] . . . . . . . . . . . . . . . . . . . .
16
2.11 RTCP-XR-message: Receiver Reference Time Report Block[20] . . . . . . .
17
2.12 RTCP-XR-message: Delay Since Last Receiver Report Block[20] . . . . . .
17
2.13 RTCP-XR-message: Inter Destination Media Synchronization Report Block[20] 18
2.14 RTCP-message: BYE[14] . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.15 Structure for a RTCP multicast environment[22] . . . . . . . . . . . . . . .
21
2.16 Structure for a RTCP multicast environment [22] extend for usage with a
Transcoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.17 IMS overview [27] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.18 Basic call flow for a audio and video session using IMS [27] . . . . . . . . .
25
2.19 Overview of IMS-based IPTV architecture [2]
. . . . . . . . . . . . . . . .
27
2.20 Start-up of User Equipment[27][2] . . . . . . . . . . . . . . . . . . . . . . .
28
2.21 Initialization of Broadcast Session[27][2]
. . . . . . . . . . . . . . . . . . .
29
2.22 Establishing of the delivery channel[27][2] . . . . . . . . . . . . . . . . . . .
29
2.23 Modification of the Broadcast Session[27][2]
. . . . . . . . . . . . . . . . .
30
2.24 Release of the Broadcast Session[27][2] . . . . . . . . . . . . . . . . . . . .
31
3.1
Packet flow and presentation overview for group synchronization [31]
. . .
32
3.2
Synchronization done between SC and MSAS without Transcoder [27, 2] .
34
3.3
Synchronization done between SC and MSAS with Transcoder [27, 2] . . .
35
3.4
Synchronization done on provider side without Transcoder [27, 2]
. . . . .
36
3.5
Synchronization done on provider side with Transcoder [27, 2] . . . . . . .
37
3.6
Synchroniyation in IMS-based IPTV[2] . . . . . . . . . . . . . . . . . . . .
38
3.7
Packet flow for synchronization in IMS-based IPTV . . . . . . . . . . . . .
39
3.8
Additional packet flow for finding unsynchronized clients . . . . . . . . . .
40
4.1
overview of the Open IMS structure[35] . . . . . . . . . . . . . . . . . . . .
45
List of Figures
XII
5.1
Function: rtp synced session set local addr . . . . . . . . . . . . . . . . . .
52
5.2
Function: msas session set local addr . . . . . . . . . . . . . . . . . . . . .
53
5.3
Function: msas session set server addr . . . . . . . . . . . . . . . . . . . .
53
5.4
Function: msas session set server addr . . . . . . . . . . . . . . . . . . . .
54
5.5
Function: rtcp xr idms init . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
5.6
Function: make sr xr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
5.7
Function: make rr xr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
5.8
Function: make xr
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
5.9
Function: msas session rtcp send . . . . . . . . . . . . . . . . . . . . . . .
59
5.10 Function: rtp session rtcp sync send
. . . . . . . . . . . . . . . . . . . . .
60
5.11 Function: msas rtcp send . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
5.12 Function: msas session rtcp recv . . . . . . . . . . . . . . . . . . . . . . . .
62
5.13 Function: xr report block parse . . . . . . . . . . . . . . . . . . . . . . . .
63
5.14 Function: rtcp XR sync get report block . . . . . . . . . . . . . . . . . . .
63
5.15 Function: rtp session parse rtcp payload . . . . . . . . . . . . . . . . . . .
64
5.16 Function: push to timestack . . . . . . . . . . . . . . . . . . . . . . . . . .
65
5.17 Function: insert ts to tcs . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
5.18 Function: insert into tcs . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
5.19 Function: set tcs item
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
5.20 Function: msas session add client . . . . . . . . . . . . . . . . . . . . . . .
68
5.21 Function: insert into tcs . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
5.22 Function: msas session insert tcs item msci . . . . . . . . . . . . . . . . . .
70
5.23 Function: get item from timestack
. . . . . . . . . . . . . . . . . . . . . .
71
5.24 Function: msas session insert tcs item msci . . . . . . . . . . . . . . . . . .
71
5.25 Function: get last item from tcs . . . . . . . . . . . . . . . . . . . . . . . .
72
5.26 Function: msas session get clients . . . . . . . . . . . . . . . . . . . . . . .
72
5.27 Function: msas session get client by ssrc . . . . . . . . . . . . . . . . . . .
72
5.28 Function: msas session get client by msci . . . . . . . . . . . . . . . . . . .
73
5.29 Function:msas session get tcs item
. . . . . . . . . . . . . . . . . . . . . .
73
5.30 Function: msas session get last tcs item
. . . . . . . . . . . . . . . . . . .
74
5.31 GStreamer pipeline for server application . . . . . . . . . . . . . . . . . . .
75
5.32 Media server - media encoder thread . . . . . . . . . . . . . . . . . . . . .
76
5.33 Media server - gui thread . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
5.34 Media server - RTP sender thread . . . . . . . . . . . . . . . . . . . . . . .
78
5.35 Media server - main function . . . . . . . . . . . . . . . . . . . . . . . . . .
79
5.36 Media server - gui thread . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
5.37 RTCP server thread of the MSAS . . . . . . . . . . . . . . . . . . . . . . .
82
5.38 Main function of the MSAS . . . . . . . . . . . . . . . . . . . . . . . . . .
83
5.39 GStreamer pipeline for decoding and presentation . . . . . . . . . . . . . .
84
5.40 Callback function for starting the IPTV functions . . . . . . . . . . . . . .
85
5.41 Callback function for stoping the IPTV functions . . . . . . . . . . . . . .
85
5.42 Function for starting the Decoder . . . . . . . . . . . . . . . . . . . . . . .
86
5.43 RTP receiver
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
5.44 RTP receiver of provider side SC
. . . . . . . . . . . . . . . . . . . . . . .
89
List of Figures
XIII
5.45 RTP sender of provider side SC . . . . . . . . . . . . . . . . . . . . . . . .
90
5.46 Provider side SC - GUI thread . . . . . . . . . . . . . . . . . . . . . . . . .
91
5.47 Main fucntion of provider side SC
. . . . . . . . . . . . . . . . . . . . . .
92
5.48 Gstreamer pipeline of the transcoder . . . . . . . . . . . . . . . . . . . . .
93
5.49 RTP receiver of the transcoder
. . . . . . . . . . . . . . . . . . . . . . . .
94
5.50 RTP sender of the transcoder . . . . . . . . . . . . . . . . . . . . . . . . .
95
5.51 Transcoder function of the transcoder application . . . . . . . . . . . . . .
96
5.52 Transcoder - GUI thread . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
5.53 Main function of the transcoder . . . . . . . . . . . . . . . . . . . . . . . .
97
5.54 GStreamer pipeline for multisource transcoder . . . . . . . . . . . . . . . .
99
6.1
XR IDMS reports measured with Wireshark . . . . . . . . . . . . . . . . . 101
6.2
Estimation of the received presentation timestamps . . . . . . . . . . . . . 103
6.3
Estimation of the received presentation timestamps (zoomed)
. . . . . . . 104
6.4
Test set for proving the instantiation of library and client . . . . . . . . . . 105
6.5
Measurement results for two instances of the SC . . . . . . . . . . . . . . . 105
6.6
Test set using two PC for measuring
. . . . . . . . . . . . . . . . . . . . . 106
6.7
Measurement without MSAS on two PC . . . . . . . . . . . . . . . . . . . 106
6.8
Reference measurement with VLC on two PC . . . . . . . . . . . . . . . . 107
6.9
Measurement with MSAS on two PC - pausing enabled . . . . . . . . . . . 108
6.10 Results IDMS measurement 1 . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.11 Reference measurement 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.12 Reference measurement 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
6.13 Reference measurement 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
6.14 Estimation Error - disabled NTP client . . . . . . . . . . . . . . . . . . . . 116
XIV
List of Tables
2.1
Synchronization Packet Sender Type . . . . . . . . . . . . . . . . . . . . .
18
4.1
GStreamer Modules for ETSI IDMS infrastructure . . . . . . . . . . . . . .
48
6.1
Useful Wireshark filters for IDMS XR reports . . . . . . . . . . . . . . . . 102
6.2
Absolute error between received timestamps and estimated timestamps . . 104
6.3
Measurement results using two clients with enabled pausing
. . . . . . . . 109
6.4
Measurement results using two clients with dissabled pausing . . . . . . . . 111
6.5
Results of measurement 3 and 4 . . . . . . . . . . . . . . . . . . . . . . . . 113
1
1 Introduction
1.1 Preface
This book represents the results of my research in synchronization of television during my
graduation project. I will describe a solution, which is actually standardized and give a
solution on how to implement it in this document.
It is a pleasure to thank the people who made this book possible. First of all these are my
supervisors Oskar van Deventer and Michael Maruschke, who supported my by reviewing
my work and discussion on content. I also would like to thank Ray van Brandenburg and
Hans Stokking, who were always open for discussion.
1.2 Research Purpose and Related Work
This work was done at TNO Information and communication technology. The part of
TNO, where this research was done, has its main research topic in media technologies and
content delivery systems. Research is done in cooperation with Dutch and international
companies as well, as with international research groups. TNO is also a member in the
NGNLab project, which main purpose is Next Generation Networks and topics related to
that.
1.3 Subject of this Thesis
The purpose of this book is to create a proof of concept of the synchronization system for
IPTV described by ETSI TS 182 027 [2] and ETSI TS 183 063 [1] by using the protocol
extension to RTCP from ETSI TS 183 063 Annex W. During planing, implementation
and evaluation specifications have to be proofed and requirements, for a sufficient work
have to be generated, if the standardized environment is not clear defined on some part
of the implementation or not sufficient.
This document should give the reader an overview of the necessary requirements and the
way of development of the proof of concept.
1.4 Thesis Outline
2
1.4 Thesis Outline
This book is divided into seven chapters. The first chapters are the theoretical base,
followed by the planing and evaluation of the prototyped IDMS system.
In chapter two an overview of the books background and necessary protocols needed for
communication is given. This is completed by a description of the network framework,
which will be the platform for the synchronization approach. The extension for television
usage of the network described in chapter two is explained in chapter three.
The Software analyzed for the usage in the prototyped implementation is described in
chapter four. The necessary modifications and extensions to this software and structure
of the applications used to build the environment for the described implementation com-
pletes the theoretical part of the book. Chapter five shows these software planing.
Chapter six gives and overview of the measurements for proving, that the created imple-
mentation works sufficient. This is completed by the summary in chapter eight.
1.5 Document conventions
This book follows the following conventions:
· Important terms are italicized when first used, like Quality of Service (QoS).
· All code fragments are highlighted like function or in an verbatim environment.
· Names of functions are marked with trailing parentheses. Example: function().
· References are made like chapter 2, or figure 2.19, which indicates the type and level
the reference points to.
· Figures and tables are numbered on a per chapter basis.
· References to figures and tables are made without page numbers, except the figure
or table in question is more than 3 pages away from the reference.
· Footnotes are numbered consecutively from the beginning to the end of the docu-
ment.
3
2 Theoretical framework
This chapter will give a summarized overview of the background of the book and the the-
oretical basics needed for planing and implementation of the prototyping implementation.
2.1 Next generation TV service
2.1.1 Watching TV together
With the progress made in the communication systems around the world, we are now able
talk or chat with people on the other side of the world in a high quality. TV broadcasts
with sports, movies or TV shows brought people from the past till now to talk about the
seen things. Bringing this together to a solution, where the client gets TV and is able to
communicate about the contents with friends is the main goal of research on social TV.
The Telecommunications and Internet Converged Services and Protocols for Advanced
Networks (TISPAN) group, as a part of the European Telecommunications Standards
Institute (ETSI) has specified IMS-based Internet Protocol Television (IPTV) (see: [2] and
[1]) as an addition to the Internet Protocol Multimedia Subsystem (IMS). This framework
supports services for communication and presence as well as services needed for television.
These frameworks are discussed later in section 2.3. First of all some background on how
TV systems have evolved till now are given in the next point, which is finalized by a
summary on quality descriptions for social TV.
2.1.2 Evolution of TV
At the beginning of television broadcasts, the content was delivered by as radio signals.
Later these signals were also broadcasted via satellite and cable systems. By using these
systems there was no need for the content provider to think about quality differences
between the receivers. The hole structure was using analog signals and at the clients was
no need for a preprocessing. Users of that TV systems got to know that it is possible to
talk about the things happened on TV, almost during the show they saw. If there was
the same system
1
used, no delay was recognized by the viewers.
The following generation of TV systems used digital system, which need special prepro-
cessing before sending and preprocessing before presentation. One of these systems is
1
radio signal, satellite system or cable system as broadcast system
2.1 Next generation TV service
4
Digital Video Broadcast (DVB). There are three main systems Digital Video Broadcast -
Terrestrial (DVB-T), Digital Video Broadcast - Satellite (DVD-S), Digital Video Broad-
cast - Cable (DVB-C) used, which have different preprocessing. This fact leads to a higher
delay between these systems and a delay between different receiver types of the same sys-
tem could also have a different playout time.
In the mean time data services reached the main bandwidth in communication. At this
point the telecommunication networks of the next generation were planed. One of them
is IMS, which is a framework inside of the Next Generation Networks (NGN). IMS is
a very flexible framework for implementation of services and their administration. This
high flexibility makes this framework the perfect choice to give the users of such networks
the ability to watch TV from the same network as they got voice, chat internet and other
services. It also leads to a high interoperability between content providers at low costs.
IMS is described in detail in section 2.3.
The usage of NGN depends on a IP-based network, which runs best with a packed ori-
ented lower layer. Data connections where made as data links in synchronized networks
like Synchronous Digital Hierarchy (SDH) and have now be moved to a packet oriented
network. Such networks have one big disadvantage for television services. Data streams
are divided into packets, which are transmitted with different delays. This is a result of
the per packet scheduling witch is done in packet oriented networks. For further informa-
tion on that topic see [3].
TV over the internet is called IPTV, which was first used as a simple broadcast of TV
content over the internet. At this point it is possible, that users are not viewing the
content at the same time. Talking about the content has become a worse, because the
opponent of the talk knows things, that will happen later. To face this problem a network
has to be designed, that gives the users the known experience of viewing. This makes
it necessary to find values for the quality, that could measured and compared to fixed
values. As a result there should be a indication of good or bad quality. Two well known
quality parameters to solve this problem are described in the next point.
2.1.3 Quality needs for Social TV
The main description for quality in communication networks is described by Quality of
Service (QoS). This is not only one value it is a complete description of parameters of
the service. In the past telecommunication networks used synchronous networks, which
are optimized for realtime communication. This networks are not very cost-efficient and
scalable. For that reasons modern communication networks are packet oriented, which
makes them flexible and effective in the usage of their bandwidth. For the usage of
telecommunication services over this packet oriented networks new systems for realising
QoS are needed and QoS has become one of the most important factors during network
development. Delay between sender and receiver, jitter and bandwidth are not only in
2.1 Next generation TV service
5
telecommunication networks important to solve these problems. For television services
these values are also important, with the difference that the delay between sender and
receiver is not that important then the delay between the receivers, because mostly mul-
ticast systems are used.
Quality of Experience (QoE) is related to the in the last section described QoS. QoE is
no description of the parameters needed by the service, it is the experience the user has
during the usage of the service. This could differ between the content of the same service.
In practice mostly QoE is measured and QoS parameters are generated as a result of such
a measurement.
For social TV the important value for Quality is the delay in presentation between each
receiver. This value should lead to the QoS requirements.
"While currently telecom operators are aiming at the synchronization level
found in telecommunication tests (150ms) our results show that voice chat-
ters only start noticing differences above 2 seconds delays. Most text chatters
do not notice synchronization differences between 0 and 4 seconds, however
active text chatters notice synchronization differences similar to when using
voice chat. As the highest levels of togetherness were also observed with ac-
tive text chatters and all voice chatters, we recommend synchronization of
approximately 1 second (which was not noticeable by this group) for a seam-
less shared experience. These results put into doubt the 150ms value from
telecommunications research as the target synchronization bound required for
social video watching applications. A first implication for software designers
is that they can concentrate on implementing simpler mechanisms that aim at
a synchronization level of 1 second (which was not noticeable by this group)
for a seamless shared experience. These results put into doubt the 150ms value
from telecommunications research [...]"[4]
This leads to a maximum delay between each receivers presentation of the same video
frame of 1s, that has to be evaluated with the solution described in this book.
2.2 Protocols
6
2.2 Protocols
IMS uses a packet oriented network, based on Internet Protocol (IP). The necessary
protocols for describing an establishment, modification, termination and the main point
of view the synchronization are shown in figure 2.1.
Ethernet
MAC
IP
TCP
UDP
SIP
HTTP
RTSP
RTP
RTCP
MPEG-TS
XCAP
Layer 1
Layer 2
Layer 3
Layer 4
Layer 5
NTP
Figure 2.1:
TCP/IP-stack and the protocols for IPTV
These protocols are described in the following subsections.
2.2.1 Network Time Protocol
An important step in synchronization is time measurement. To get a correct timestamp
all clocks have to be synchronized. One solution for that purpose is Precision Time Pro-
tocol (PTP) as described in [5]. It describes a solution for clock synchronization with a
low error in smaller networks. For synchronizing larger networks Network Time Protocol
(NTP), as described in [6], is mostly used, because it supports asymmetric delays between
server and client. Another advantage to PTP is, that client and server are available as
open source software. For the IDMS, described by ETSI TISPAN, it is also mandatory to
synchronize all clients clocks using NTP and signaling the source to the application level
Media Synchronization Application Server (MSAS). How these clocks are synchronized is
described in figure 2.2.
2.2 Protocols
7
Reference Timestamp
Origin Timestamp
Receive Timestamp
Transmit Timestamp
Timestamp generated
org
rec
xmt
Reference Timestamp
Origin Timestamp
Receive Timestamp
Transmit Timestamp
Timestamp generated
org
rec
xmt
t1
t2
t3
t4
t5
t6
t7
t8
t1 = clock
t4 = clock
t5 = clock
t8 = clock
t2 = clock
t3 = clock
t6 = clock
t7 = clock
0
0
T1
t3<>0?
T4
t1==T1?
T3
T4
T5
t7<>T3?
T8
t5==T5?
T1
T2
0
T1
T2
T3
t5<>T1?
T6
t3==T3?
T5
T6
T7
t1
0
0
t3
t1
t2
t5
t4
t3
t5
t6
t7
T0
T0
T0
t1
0
0
T0
t3
t1
t2
T0
T0
t5
t4
t3
T0
t5
t6
t7
T0
Figure 2.2:
Typical clock synchronization using NTP[6]
First the clients sends a packet with its local time (Reference Timestamp - see figure 2.3)
and the time of sending the packet (Origin Timestamp - see figure 2.3). The server adds
the time of reception (Receive Timestamp - see figure 2.3) and the time of sending the
packet back to the client (Transmission Timestamp - see figure 2.3) to the packet and
sends it back to the client. The client is now able to calculate a new local time, which is
used to do all the step a second time. With all these times the client is able to calculate
the new local time, the clock drift and the average computation time of the server. This
algorithm is explained in RFC1305[6]. For the IDMS implementation it only necessary
to know, that the usage of NTP improves the clock accuracy but it could not be used for
every timestamp, because of the bandwidth usage, which leads to an error made, because
of the existing clock drift every Real Time Clock (RTC) has.
2.2 Protocols
8
0
7
15
23
31
LI
VN
Mode
Stratum
Poll
Precision
Root Delay
Root Dispersion
Reference ID
Reference Timestamp
Origin Timestamp
Receive Timestamp
Transmit Timestamp
Extension Field 1
Extension Field 2
Key Identifier
dgst
Figure 2.3:
NTP frame[6]
Figure 2.3 shows the NTP frame used for clock synchronization. A more detailed
description and the description of the necessary local registers (variables) of server and
client can be found in RFC1305[6].
2.2.2 Session Initiation Protocol
The Session Initiation Protocol (SIP) is described by RFC3261 - RFC3265 ([7, 8, 9, 10,
11]). It is mostly used for creation, modification and termination of multimedia sessions.
SIP is encapsulated in UPD-datagrams, because of its Three-Way-Handshake, but it is
also possible to use it in combination with TCP.
SIP is used for signaling in Voice over Internet Protocol (VoIP) based telecommunication
systems as well as modified in the IMS. It is the replacement of Signaling System No. 7
(SS#7) for internet based communication.
2.2 Protocols
9
INVITE sip:alice@open-ims.test SIP/2.0
VIA:SIP/2.0/UDP10.10.125.123
Call-ID:1234567890@testbed.open-ims.test
From:<sip:bob@open-ims.test>
To:Alice<sip:alice@open-ims.test>
CSeq:1 INVITE
Subject: Alice, come here.
Content-Type:application/sdp
Content-Length:885
<CRLF>
Start Line
General Header
Entity Header
Request Header
SDP Daten
Figure 2.4:
Basic message format of the Session Initiation Protocol[7, page 264]
Figure 2.4 shows the INVITE message of SIP. It is like Hypertext Transfer Protocol
(HTTP) a text based protocol, which makes it flexible in usage. The figure shows the
parts of such a message. A detailed description on SIP messages and its contents could
be found in [7]. The important part for IDMS, is the content of the session description,
which is described in Session Description Protocol (SDP) part of the message.
2.2.3 Session Description Protocol
For a description of the session the SDP is used. It is described by [12]. This protocol
could be used very flexible, because of its ASCII-based architecture it could be modified
without modification of the core protocol.
2.2 Protocols
10
v=0
o=- 15115003341359513177 15115003341359513177
IN IP4 mdf.open-ims.test
s=Unnamed
i=N/A
c=IN IP4 224.0.0.9/255
t=0 0
a=tool:vlc 1.1.8
a=recvonly
a=type:broadcast
a=charset:UTF-8
a=control:rtsp://mdf.open-ims.test:8080/channel1.sdp
m=video 8000 RTP/AVP 33
b=RR:0
a=rtpmap:33 MP2T/90000
a=control:rtsp://mdf.open-ims.test:8080/channel1.sdp/trackID=0
a=rtcp-xr grp-sync,:sync-group=<SyncGroupId>,
Figure 2.5:
SDP contents for a TV session
Figure 2.5 shows an example description for an IPTV session. The important line of the
shown message is a=rtcp-xr grp-sync,:sync-group=<SyncGroupId>, which contains
the SyncGroupId value, which is equal to the Media Stream Correlation Identifier (MSCI)
used as value for the RTCP communication. A detailed description of the values could
be found in [13] and [1].
2.2.4 Real-Time Transport Protocol
The Real-Time Transport Protocol (RTP) (see: [14]) is used to encapsulate multimedia
contents for transmission from the sender to the receiver. For IMS-based IPTV this
0
7
15
23
31
V
P X
CC
M
PT
SEQ_NUM
RTP_TS
SSRC
CSRC
Header Extensions
Payload
V: Version
P: Padding
X: Extension
CC: CSRS Count
M: Marker
PT: Payload Type
RTP_TS: RTP Timestamp
SSRC: Synchronization Source Identifier
CSRC: Contributing Source Identifier
Figure 2.6:
RTP frame [14, 15]
protocol is also used to transmit the TV contents.
Figure 2.6 shows a typical RTP
frame. RTP Timestamp (RTP TS) and Synchronization Source Identifier (SSRC) are
2.2 Protocols
11
the important values for IDMS in IMS-based IPTV. The RTP TS is the common base
for synchronization between the receivers, because this is the unique identifier for the
packet. The packet sender is identified by the SSRC. The Contributing Source Identifier
(CSRC) field is not used in IPTV, because there is only one media sender. this results in
a shortened header without this field.
2.2.5 MPEG-TS
Moving Picture Experts Group (MPEG) is one of the groups, which standardizes digi-
tal formats for video and audio encoding. These formats are used for all DVB systems
as well as for IPTV. All these formats could be encapsulated in RTP directly, but this
leads to separate data streams for audio and video. For television that could lead to a
decrease in performance, because synchronization of audio and video has to be done at
the receiver
2
. This problem could be solved by Moving Picture Experts Group - Trans-
port Stream (MPEG-TS), which encapsulates audio, video and subtitle streams to a joint
stream. The receiver is now able to decapsulate these streams with now need of synchro-
nization
3
.
2
The problem of synchronization of separate RTP-streams is described in section 3.2
3
The synchronization of playout has to be done and is not meant by this.
2.2 Protocols
12
Figure 2.7:
Frame structure for mpeg-ts frames [16]
For IMS-based IPTV
4
the MPEG-2 transport MUX packet is used, because error recogni-
tion, the advantage of the other frame formats, is done by cheksum in the Ethernet frame
(see: [3] for a detailed description).
4
For a detailed description of the packet format see [1]
2.2 Protocols
13
2.2.6 Real-Time Transport Control Protocol
The missing hand-shake system from UDP[17], requests a separate signaling to the sender
about the quality of the transmission. RTCP closes this gap, by giving the opportunity
to send information of packet sending to the receiver and giving feedback of the recep-
tion to the sender. Some of the messages sent by RTCP are described in the following
subsections. These are the most interesting ones for synchronization and quality of the
session. Important for every RTP / RTCP implementation is the way the packets take in
the network. This has to be the same for RTP and RTCP and should not change during
the session for best performance, because every route change will lead to inter arrival
jitter. This jitter is never zero, because every routing decision takes time, which changes
depending on the network traffic (see [18]).
2.2.6.1 Sender Report
The Client is able to measure the one-way delay of the transmission, if the sender is
configured to send Sender Report (SR) messages to the client. These messages are send
regularly, but not for every RTP packet.
0
7
15
23
31
NTP_TS
V
P
RC
PT
Length
Sender SSRC
RTP_TS
Sender's Packet Count
Sender's Byte Count
SSRC1
Fraction lost
Cumulative Number of Packets lost
Extended highest Sequence Number received
Interarrival Jitter
LSR
DLSR
RTCP Header
Report 1
SR Header
Packet-specific extensions
Figure 2.8:
RTCP-message: Sender Report[14]
For IPTV only the SR header is interesting, because it contains the combination of
RTP TS and Network Time Protocol Time Stamp (NTP TS), which indicates the ex-
act sending time of the RTP packet it reports on. In a two-way RTP connection, the
Sender Report could also be used to send information about the reception to the other
participant. Report Blocks are added to the message for each sender to report on. One of
the goals for these reports is the measurement of the round trip time. The time stamps
Last Sender Report (LSR) and Delay Since Last Sender Report (DLSR) are used for that
calculation. LSR represents the lower 16 Bits of the seconds and the higher 16 Bits of
the fractional part of the NTP TS of the last received SR. The delay between reception
2.2 Protocols
14
of a SR and sending of the current report is represented by the DLSR, that contains
the seconds in the higher 16 Bit and the 1/65365 part of a seconds lower 16 Bits. A
more detailed description of this delay measurement is described later. A more detailed
description about the other contents of this message and there use could be found in
RFC3550[14].
2.2.6.2 Receiver Report
The Receiver Report (RR) contains a report block as described in section 2.2.6.1.
0
7
15
23
31
V
P
RC
PT
Length
Sender SSRC
SSRC1
Fraction lost
Cumulative Number of Packets lost
Extended highest Sequence Number received
Interarrival Jitter
LSR
DLSR
RTCP Header
Report 1
RR Header
Packet-specific extensions
Figure 2.9:
RTCP-message: Receiver Report[14]
This message is used in a one-way RTP connection like IPTV, because its one purpose is
to report about reception of RTP and RTCP messages.
2.2.6.3 Receiver Summary Information
In a multicast environment, the sender sends its RTP stream and RTCP messages to a
multicast group with an unknown amount of receivers. If the receiver transmits its RR to
the same multicast group, all the other receivers will also receive this message. To save
bandwidth it is possible to aggregate receiver information of several receivers to only one
message. This avoids sending of unneeded RR to receivers. IP multicast is described by
RFC3171[19]. The Receiver Summary Information (RSI) is the message which should be
used to send aggregated receiver information to the sender.
2.2 Protocols
15
0
7
15
23
31
V
P
RC
PT
Length
Sender SSRC
Summarized SSRC
RTCP Header
Report 1
RR Header
Packet-specific extensions
NTP_TS
Sub-report blocks
The supreport could be one of the following:
· Loss Sub-Report Block,
· Jitter Sub-Report Block,
· Round-Trip Time Sub-Report Block,
· Cumulative Loss Sub-Report Block,
· Feedback Target Address Sub-Report Block,
· Collision Sub-Report Block,
· General Statistics Sub-Report Block,
· RTCP Bandwidth Indication Sub-Report Block or
· RTCP Group and Average Packet Size Sub-Report Block
2.2 Protocols
16
2.2.6.4 Session Description
The participants of the session are able to identify to each other by sending a Session
Description (SDES). The contents of the chunk, shown in figure 2.10 are all possible
values. These values are mandatory, this means they do not need to be included all in
the chunk. This message is described in detail in RFC3550[14].
0
7
15
23
31
V
P
SC
PT
Length
SSRC1
RTCP Header
CNAME=1
length
user and domain name
length
length
length
length
length
length
NOTE=7
note about the source
TOOL=6
name and version information about the tool
LOC=5
geographic location of site
PHONE=4
phone number of source
EMAIL=3
email address of source
NAME=2
common name of source
Chunk 1
Figure 2.10:
RTCP-message: Session Description[14]
2.2.6.5 Extended Report
RTCP was designed to transmit status and connection information between sender and
receiver of the media content. This behavior does not solve all problems in realtime media
systems. Extending these message system is the main goal of RFC3550 [14]. For IDMS
some of these messages are important as well. These will be described in the following
subsections, finalized by the XR IDMS block described by ETSI TS 183 063 Annex W
[1]. The usage of the following report blocks is described later to show their function in
common to the used network.
2.2 Protocols
17
2.2.6.5.1 Receiver Reference Time Report Block
One of the functions, that are interesting for IDMS is the delay measurement between
non-senders of media described in RFC3611 [20]. RFC3611 describes this as a delay
measurement between RTP receivers, but it is also possible to use it in a multicast en-
vironment with a feedback target as RTCP receiver for RR. Measurement of the round
trip time between feedback target and the receivers is now possible. The Receiver Refer-
0
7
15
23
31
V
P
RC
PT
Length
Sender SSRC
RTCP Header
BT
block length
Resrv
NTP_TS of packet reception
RRT Block #1
Figure 2.11:
RTCP-XR-message: Receiver Reference Time Report Block[20]
ence Time Report Block (RRT) is the first XR-block sent for that measurement. It only
contains the time of packet sending with a most precise timestamp. This block is shown
in figure 2.11 as a full RTCP packet. The other values of that packet are the same as
described in section 2.2.6.1 for the SR.
2.2.6.5.2 Delay Since Last Receiver Report Block
For the answer of a RRT, as described in
a Delay Since Last Receiver Report Block
(DLRR) is used. Figure 2.12 shows such a Block in a complete RTCP message.
0
7
15
23
31
V
P
RC
PT
Length
Sender SSRC
RTCP Header
BT
block length
Resrv
DLRR Block #1
SSRC1
LRR
DLRR
Figure 2.12:
RTCP-XR-message: Delay Since Last Receiver Report Block[20]
The SSRC1 values contains the SSRC of the sender of the RRT, to which this DLRR
belongs to. The other values are the same as described in section 2.2.6.1 for an RR.
2.2 Protocols
18
2.2.6.5.3 Inter Destination Media Synchronization Report Block
As described in section 2.1.3, the delay in presentation of the media content delivered by
RTP is the most important value for the quality of the IPTV system. This leads to the
need of sharing the time of presentation between the receivers of the media stream. ETSI
TS 183 063 [1] Annex W describes an XR block for sending the time of reception and
presentation of the RTP packet.
0
7
15
23
31
V
P
RC
PT
Length
Sender SSRC
RTCP Header
BT
block length
SPST
Resrv
P
PT
Resrv
MSCI
SSRC of media source
NTP_TS of packet reception
RTP_TS
NTP_TS of packet presentation
IDMS Block #1
Figure 2.13:
RTCP-XR-message:
Inter Destination Media Synchronization Report
Block[20]
This Inter Destination Media Synchronization Report Block (IDMS-RB) as shown in fig-
ure 2.13 contains the MSCI of the sync group the client belongs to, the SSRC of the
RTP sender, RTP TS of the packet this reports belongs to and the NTP timestamps of
reception and presentation. These are the values that are needed to calculate the de-
lay between several receivers. The Payload Type (PT) filed is the same as described by
RFC3550 [14] for all RTCP reports. The sender type id identified by the Synchronization
Packet Sender Type (SPST) field of this message. Table 2.1 shows the allowed SPST for
the IDMS reports.
SPST
Sender type
1
Synchronization Client (SC)
2
MSAS
3
Transcoder (SC') - receiver
4
SC' - sender
Table 2.1:
Synchronization Packet Sender Type
Ende der Leseprobe aus 142 Seiten
- nach oben
Details
- Arbeit zitieren
- , 2011, How to synchronize the next generation of IPTV: Explantion of the ETSI standardized version, Hamburg, Bedey Media GmbH, https://www.bachelor-master-publishing.de/document/296554
Service
Bei Fragen steht euch unser Lektoratsteam gerne zur Verfügung:
Per E-Mail: bmp@diplomica.de
Telefonisch Dienstag und Donnerstag zwischen 10:00 und 12:00 Uhr sowie Mittwoch 14:00 bis 15:00 Uhr: +49(0)176-85996762
Per E-Mail: bmp@diplomica.de
Telefonisch Dienstag und Donnerstag zwischen 10:00 und 12:00 Uhr sowie Mittwoch 14:00 bis 15:00 Uhr: +49(0)176-85996762
Kommentare