Server Driven Streaming

In a conventional streaming standard, the majority of the functions needed to support multimedia content delivery are handled in the server-side. These include the approach to access the multimedia components and handling the conversion between storage and delivery formats. Client is supposed to be the recipient of the service while it may process its local status to provide the required information for delivery format management (e.g. based on the channel status or buffer occupancy). Server actually remains the decision maker for delivery format adaptation and control during the session of the service. In this subsection, RTP/RTSP as an example of the protocols which can be used in a mobile communication paradigm and MMT as an emerging alternative will be discussed in more detail.

Real Time Protocols (RTP/RTSP)

Real Time Protocol (RTP) was introduced in the mid-1990s as an application layer protocol for delivery over IP networks [30]. This was a response to the shortcoming of the existing transport layer standards such as TCP and UDP in delivering real-time video and audio services. RTP compensates the simplicity of UDP protocol which is used in its Transport layer, while avoiding the inadequacy of the retransmission mechanism of TCP protocol for real-time streaming. Figure 2.7 depicts the customized structure of the overheads in RTP for multimedia streaming. As an example, the required synchronization for a real-time video data is provided by RTP timestamp. Furthermore, the format of the application layer data is defined by the marker and payload type overheads.

Real Time Streaming Protocol (RTSP), as a control protocol over IP networks, is suggested by the 3GPP standards for packet streaming in mobile communication alongside RTP for the delivery

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TCP is usually more preferable in the case of RTSP. With the help of RTSP the main control commands (such as setup and play) as well as the information of delivery mechanism (such as application type and delivery method) can be exchanged.

Figure 2.8 shows an example of the schematic view of a streaming session establishment and control in PSS. Service starts by invoking the required content from web server. Then RTSP is used to fetch the content description file as well as to run the initial setup and play procedures. Content is delivered toward the end-user through RTP over UDP. Finally, RTSP is used to shut down the service.

MPEG Media Transport (MMT)

MPEG Media Transport (MMT) is an example of contemporary server-driven streaming protocols which are under development as alternatives to the conventional real-time protocols such as RTP. MMT integrates a wide-ranging set of functionality and usages in one all-IP standard. This includes storage, delivery, stream multiplexing and other required functionalities for a comprehensive media transport protocol. This is a very robust design for a protocol compared to the conventional real-time protocols such as RTP. It is also intended to be used as a high efficiency media delivery in heterogeneous environments. MPEG has initiated the development of MMT considering the new challenges of the digital broadcasting and streaming over IP [31]. A client- driven adaptive streaming standard (i.e. MPEG-DASH) is also under development by MPEG and alongside MMT, which will be explained later in this chapter [32].

Figure 2.8 Schematic view of a basic streaming session using RTP/UDP for main content and RTSP for streaming control [9]

Web server Description (RTSP server) Media server End-user (3GPP-client)

Get Web Page (URI)

Get content description (RTSP)

Setup (RTSP)

Play (RTSP)

content (RTP/UDP/IP)

MPEG-DASH and MMT are designed for two different paradigms: in DASH the client manages the session and it should work with the existing infrastructure (e.g. HTTP). MMT is designed to be a replacement of RTP where the server manages the session and a specific server (similar to the RTP server) is needed to handle the procedure. It must be noted that the existing delivery network (i.e. CDN) doesn’t support MMT at the moment.

As it has been depicted in Figure 2.9, MMT covers three major functionalities required for the delivery of multimedia content. This architecturally can be explained as encapsulation, delivery and signalling functions.

Encapsulation function: Using the ISO Base media file format, the encapsulation function

defines the logical and physical structure of the content (i.e. mpeg4). This will be either cached at a network node for delivery preparation or will be packetized to be delivered over the network.

Delivery function: As an application layer protocol, the packetized data required to support the

multimedia streaming through a heterogeneous network environment as well as the structure of the payload for encapsulated data will be defined by delivery function.

Signalling function: The configuration and format of the above mentioned protocol and payload

structures will be managed by the signalling function.

Figure 2.9 Functional areas of MMT

Delivery Function Coded Media TCP/UDP Encapsulation Function Signalling Function Functional areas of MMT IP