4.5 Performance Issues of Mobile Streaming

When implementing a PSS services, the underlying mobile network brings requirements and constraints that must be taken into consideration. To understand how a multimedia session is started and handled end-to-end, Figure 4.10 shows a possible scenario for an example session (here and in the following, we consider only the usage of packet switched bearers, rather than circuit switched bearers). ^[76]

click to expand
Figure 4.10: Message exchange of a typical basic mobile streaming session.

The session is started by a mobile user getting a URI to the specific content that suits the user's terminal. The URI comes from a WAP (Wireless Application Protocol)/Web browser, or it is typed in. The URI specifies the streaming server and the address of the content on that server. A PSS application that establishes the multimedia session must understand an SDP file. The SDP file may be obtained in a number of ways. In the example described here, it is obtained through RTSP signaling via the DESCRIBE message. The SDP file contains the description of the session (session name, author, and other parameters), the type of media to be presented, and the bit rate.

The session establishment is the process in which the mobile user invokes a streaming client to set up the session with the server. The mobile device is expected to activate a PDP context that enables IP packet transmission, with an appropriate QoS profile for streaming media.

The setup of the streaming service is done by sending an RTSP SETUP message for each media stream chosen by the client. This returns, among other information, the UDP and TCP port to be used for the respective media stream. The client sends an RTSP PLAY message to the server that starts to send one or more streams over the IP network.

At the end of the session a TEARDOWN message is sent by the client and the PDP context can be deallocated.

The following sections introduce some QoS issues in mobile multimedia streaming.

4.5.1 Bearer Considerations

The PDP context activation described in Figure 4.10 must be activated with an adequate set of parameters. SDU error rates and transfer delay are key parameters and must be tuned according to the RLC mode chosen. If acknowledged mode is selected, the streaming client can rely on lower error rates because the lost blocks are retransmitted. As a downside, the delay jitter perceived at the PSS client may be rather high, especially if fully persistent acknowledged mode transmission is chosen. On the other hand, when unacknowledged mode is selected, the delay jitter is supposedly limited, but no retransmissions are occurring at the RLC layer. Consequently, the PSS client cannot benefit from a much higher level of data delivery reliability.

Particular attention must be paid to RTP packet sizes. When using RLC acknowledged mode, using bigger packets produces higher delay jitters at the PSS client, because there is a higher probability that more RLC blocks have to be retransmitted in order to deliver a single RTP packet. On the other hand, when using RLC unacknowledged mode, larger packets are more susceptible to losses than smaller packets, because the loss of a single RLC block produces the loss of the entire RTP packet. In this case using small packets is recommended. Too-small packets would cause too much RTP/UDP/IP header overhead. It is clear that the best settings are found when considering all the mentioned issues at the same time.

4.5.2 RTCP

The RTP (Real-Time Transport Protocol) specifies its control protocol RTCP ^[77] that allows monitoring of the data delivery or, in other words, the quality of service. The main function of RTCP is to convey feedback information about the participants in an ongoing session. The information provided includes packet losses and interarrival jitter information. In a point-to-point connection, such as a multimedia streaming session, RTCP can offer a valid means for adjusting the error resilience properties of the media streams carried over mobile networks. In such networks the quality of the connection may vary all the time, and prompt action is crucial for guaranteeing the best possible quality of service at any instant. An example of action to be taken by a streaming server is the dynamic change of the packetization parameters to provide an increased level of error resilience. However, the utility function for repairing media is decreasing over time, because an action taken too late can be useless or it may even worsen the quality of service. Normally, RTCP feedback is sent at an interval of at least 5 seconds. The recommended fraction bandwidth reserved for RTCP is 5 percent of the RTP session bandwidth. However, at low bit rates (up to 64 kbps), if the minimum RTCP transmission interval is 5 seconds, it is impossible to reach the full 5 percent bandwidth.

The PSS specifications of Release 5 ^[78] define two working modes for PSS clients that intend to send more-frequent feedback to the PSS server:

Mode 1 (normal feedback) uses the rule defined in reference ^[79], where feedback is sent at intervals of at least 5 seconds.
Mode 2 (more frequent feedback) fills the 5 percent bandwidth reserved for RTCP to send feedback information.

Mode 2 allows feedback to be sent at a higher rate (the RTCP transmission interval is much smaller than 5 seconds), and it allows QoS-enabled PSS servers to take appropriate actions to guarantee good QoS at the PSS client. If 5 percent bandwidth is costly in terms of bearer allocation, Mode 1 can be used. It consumes less network resources, but the feedback capability is limited (on average) to one RTCP feedback report every 5 seconds.

4.5.3 RTSP Signaling Issues

Session setup time is one of the most important factors to determine the efficiency of a PSS service. RTSP is the protocol that handles session setup, and it supports both TCP and UDP transport. TCP is the mandatory transport mechanism for RTSP. For TCP, two types of connections are possible:

Persistent, where a connection is used for several RTSP request/response pairs
Nonpersistent, where a connection is used for a single RTSP request/ response pair

Every nonpersistent connection starts with a three-way handshake (SYN, ACK, SYN) before any RTSP message can be sent. This increases signaling time considerably. For this reason, the use of persistent TCP connections is recommended in order to keep the signaling time as low as possible. ^[80]

4.5.4 Link Aliveness

In mobile networks, connection can be lost because of low network coverage, fading, shadowing, loss of battery power, or turning off the PSS client even if the streaming session is active. In order for the streaming server to understand the client aliveness status, the PSS client should send periodic wellness information to the PSS server. The default period to send this information is 1 minute, as described in reference ^[81]. For this purpose RTCP or RTSP can be used to signal link aliveness to the PSS server.

^[76]3GPP TSGS-SA, Transparent end-to-end packet-switched streaming service (PSS). General description (Release 5), TS 26.233, v.5.0.0 (2002–03).

^[77]Schulzrinne, H. et al., RTP: a transport protocol for real-time applications, IETF (Internet Engineering Task Force) RFC 1889, January 1996.

^[78]3GPP TSGS-SA, Transparent end-to-end packet-switched streaming service (PSS). Protocols and codecs (Release 5), TS 26.234, v.5.3.0 (2002–12).

^[79]Schulzrinne, H. et al., RTP: a transport protocol for real-time applications, IETF (Internet Engineering Task Force) RFC 1889, January 1996.

^[80]3GPP TSGS-SA, Transparent end-to-end packet-switched streaming service (PSS). Protocols and codecs (Release 5), TS 26.234, v.5.3.0 (2002–12).

^[81]Schulzrinne, H., Rao, A., and Lanphier, R., Real-time streaming protocol (RTSP), IETF (Internet Engineering Task Force) RFC 2326, April 1998.