Implementing ETSI standardised RTCP-based Interdestination Media Synchronization
- Art: MA-Thesis / Master
- Autor: Torsten Löbner
- Abgabedatum: August 2011
- Umfang: 141 Seiten
- Dateigröße: 7,0 MB
- Note: 1,0
- Institution / Hochschule: Deutsche Telekom Fachhochschule Leipzig Deutschland
- Bibliografie: ca. 55
- ISBN (eBook): 978-3-8428-2046-3
- Sprache: Englisch
- Prämierung:
- Arbeit zitieren: Löbner, Torsten August 2011: Implementing ETSI standardised RTCP-based Interdestination Media Synchronization, Hamburg: Diplomica Verlag
- Schlagworte: IMS, IPTV, Synchronization, UCT IMS Client, Media
48,00 €
PDF-eBook Download: 48,00 €
MA-Thesis / Master von Torsten Löbner
Introduction:
This thesis 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 thesis possible. First of all these are my supervisors Oskar van Deventer and Michael Maruschke, who supported me 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.
This work was done at TNO Information and communication technology. The part of TNO this thesis is placed 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.
The purpose of this thesis 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.
This thesis 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 thesis 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 completes the theoretical part of the thesis. Chapter five shows these software planing.
Chapter six gives and overview of the measurements for proving, that the created implementation works sufficient. This is completed by the summary in chapter eight.
Table of Contents:
| Abstract | I | |
| Glossary | VI | |
| Nomenclature | X | |
| List of Figures | XI | |
| List of Tables | XIV | |
| 1. | Introduction | 1 |
| 1.1 | Preface | 1 |
| 1.2 | Research Purpose and Related Work | 1 |
| 1.3 | Subject of this Thesis | 1 |
| 1.4 | Thesis Outline | 2 |
| 1.5 | Document conventions | 2 |
| 2. | Theoretical framework | 3 |
| 2.1 | Next generation TV service | 3 |
| 2.1.1 | Watching TV together | 3 |
| 2.1.2 | Evolution of TV | 3 |
| 2.1.3 | Quality needs for Social TV | 4 |
| 2.2 | Protocols | 6 |
| 2.2.1 | Network Time Protocol | 6 |
| 2.2.2 | Session Initiation Protocol | 8 |
| 2.2.3 | Session Description Protocol | 9 |
| 2.2.4 | Real-Time Transport Protocol | 10 |
| 2.2.5 | MPEG-TS | 11 |
| 2.2.6 | Real-Time Transport Control Protocol | 13 |
| 2.2.6.1 | Sender Report | 13 |
| 2.2.6.2 | Receiver Report | 14 |
| 2.2.6.3 | Receiver Summary Information | 14 |
| 2.2.6.4 | Session Description | 16 |
| 2.2.6.5 | Extended Report | 16 |
| 2.2.6.6 | BYE Message | 19 |
| 2.2.6.7 | Measuring QoS values using RTCP | 19 |
| 2.2.6.8 | RTCP architecture for multicast streaming | 20 |
| 2.3 | Internet Protocol Multimedia Subsystem | 22 |
| 2.3.1 | Basic call | 25 |
| 2.4 | IMS-based IPTV | 27 |
| 2.4.1 | Overview of the Architecture | 27 |
| 2.4.2 | Watching TV using IMS-based IPTV | 28 |
| 3. | Social TV made with IMS-based IPTV | 32 |
| 3.1 | Interdestination Media Synchronization | 32 |
| 3.2 | Synchronization of multiple media streams | 33 |
| 3.3 | Synchronization in IMS-based IPTV | 34 |
| 3.3.1 | Architecture | 34 |
| 3.3.2 | Data flow for synchronization | 38 |
| 3.3.3 | RTCP part of synchronized IMS-based IPTV | 39 |
| 3.4 | Getting the clients in sync | 40 |
| 3.4.1 | Finding non-synchronized clients | 40 |
| 3.4.2 | Calculation of the Presentation Timestamp | 43 |
| 3.4.3 | Calculation of the presentation delay | 44 |
| 4. | Existing Software | 45 |
| 4.1 | IMS Environment (Open IMS) | 45 |
| 4.2 | Application Server | 46 |
| 4.3 | Multimedia players and libraries | 47 |
| 4.4 | SIP-Client | 49 |
| 4.4.1 | linphone | 49 |
| 4.4.2 | UCT IMS Client | 49 |
| 4.5 | NTP Client | 49 |
| 4.6 | Library for mathematical calculations (GSL) | 50 |
| 5. | Structure of the Implementation of IDMS for IMS-based IPTV | 51 |
| 5.1 | Library for sending RTP and RTCP data | 51 |
| 5.1.1 | Set local address | 52 |
| 5.1.1.1 | rtp synced session set local addr | 52 |
| 5.1.1.2 | msas session set local addr | 53 |
| 5.1.2 | Set remote address | 53 |
| 5.1.2.1 | msas session set server addr | 53 |
| 5.1.2.2 | rtp synced session set remote addr full | 54 |
| 5.1.3 | Create RTCP reports | 55 |
| 5.1.3.1 | rtcp xr idms init | 55 |
| 5.1.3.2 | make sr xr | 56 |
| 5.1.3.3 | make rr xr | 57 |
| 5.1.3.4 | make xr | 58 |
| 5.1.4 | Send RTCP messages | 59 |
| 5.1.4.1 | msas session rtcp send | 59 |
| 5.1.4.2 | rtp session rtcp sync send | 60 |
| 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 |
| 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 |
Text Sample:
Chapter 2, Theoretical framework:
This chapter will give a summarized overview of the background of the thesis and the theoretical 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) 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 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 used, no delay was recognized by the viewers.
The following generation of TV systems used digital system, which need special preprocessing before sending and preprocessing before presentation. One of these systems is Digital Video Broadcast (DVB). There are three main systems: Digital Video Broadcast – Terrestrial (DVB-T), Digital Video Broadcast – Satellite (DVB-S), Digital Video Broadcast – 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 system 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 oriented lower layer. Data connections where made as data links in synchronized networks like Synchronous Digital Hierarchy (SDH) and have now to 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.
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 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 be 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. These networks are not very cost-efficient and scalable. For that reason 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 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 as important as the delay between the receivers, because mostly multicast 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 chatters 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 active text chatters and all voice chatters, we recommend synchronization of approximately 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 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 [...]’.
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 thesis.
48,00 €
PDF-eBook Download: 48,00 €
Link zur Arbeit:
http://www.diplom.de/ean/9783842820463
Arbeit zitieren:
Löbner, Torsten August 2011: Implementing ETSI standardised RTCP-based Interdestination Media Synchronization, Hamburg: Diplomica Verlag
Schlagworte:
IMS, IPTV, Synchronization, UCT IMS Client, Media



