Assumptions

Rate Controls

Streaming

Server Internet BSQ Transmitter BTS

Signaling Air-link Rate control Source

Rate Control

Data

Control Signaling

BSC probing

Streaming

Server Internet BSQ Transmitter BTS

Signaling Air-link Rate control Source

Rate Control

Data

Control Signaling

BSC probing

Figure 3-4. Two rate controllers in the transmission path for video streaming application

Source Rate Controls

There are typically two rate controllers in the transmission path for scalable video streaming, one is the source rate controller, and the other is the air-link rate control (rate assignment), as illustrated in Figure 3-4. The source rate controller should send out data

based on the channel condition of the subsequent network, including the Internet, base-station queue (BSQ), and available data throughput provided by the Base Station Controller (BSC). Typically, these two rate controllers are located within different devices in the network. If there are no negotiation protocols between source and air-link rate controllers to communicate with each other, or the round-trip delay is relatively large compared to the required response time, the behavior of source rate controller could be assumed to be independent from that of the air-link rate controller. The determination of source transmission rate would therefore be according to the result of probing the channel condition of Internet in the streaming server. We assume that the probed available channel bandwidth follows a uniform process, which is the upper bound of the highest data throughput that the cdma2000 1x-RTT system could support. This assumption may cause some inconsistency from practical streaming case; however, this simple assumption would give us fundamental observations for an end-to-end system perspective.

Air-link Rate Assignment

For the radio rate assignment, the data throughput that could be supplied by the system depends on two major factors: the first one is the amount of backlogged data in the BSQ, and the other is the available radio resource. The interaction among techniques of radio resource management such as call admission control, burst allocation, burst admission control, and rate assignment, would be rather complex. To simplify this problem, we assume that the rate assignment follows a Markov chain probability model with static transition probabilities. The assigned rate arises periodically and the corresponding RLP frame error rate is monitored. Once the current RLP frame error rate exceeds the target threshold, the assigned rate drops to lower bit rate levels instantly to ensure the transmission quality.

Figure 3-5 depicts the state diagram that accommodates the state transition to the additive-increase multiplicative-decrease (AIMD) concept. Once steady state is reached, the probability of rate assigned to each level should approach a Gaussian distribution, where its mean should be close to the average source rate to support a reasonable streaming.

9.6kbps

Figure 3-5. Markov-chain rate assignment for data transmission over air interface

Buffer sizes

There are mainly two buffers in the transmission path for video streaming. In this paper, we assume that the BSQ assigned for each video streaming user is large enough such that there is no overflow case for BSQ. As to the mobile-station buffer (MSB), the internal application memories in the state-of-the-art 3G handsets could be several megabytes. For example, there are 3.4MB internal dynamic memories in the Nokia 3650 handset [34].

However, this memory is shared for all applications in the handsets, such as phone books, messages, and photos. Therefore, the buffer size for video streaming application may vary.

Allocation of larger dynamic memory for streaming buffer could reduce outages since it lowers the probability of buffer overflow. Similarly, increase of the buffer size causes longer time for bitstream pre-rolling and reduces the probability of buffer underflow.

However, a large pre-roll time makes video streaming less relevant because it degenerates to the case of offline file downloading which is insensitive to the channel variation. In addition, for real-time content such as live news, large pre-roll time incurs undesirable long latency

for video playback. Initially, we assume that the effective buffer size is 200kB for video streaming application in the heterogeneous multitasking environment of the Real-Time Operation System (RTOS) in a mobile station.

Header Compression

For low-rate video streaming, the protocol overhead occupies a significant portion of available channel bandwidth. Specifically, if the protocol stack of interest are RTP (as session-layer protocol), UDP (as transport-layer protocol), IP (as network-layer protocol), and PPP (as link-layer protocol), the size of overhead for each encapsulating video access unit would be 50 bytes. Assume that the packetization follows the recommendation of RFC 3016 [27], the total amount of overhead per second would reach several kilobits.

Nevertheless, the typical per-session throughput for video streaming users of cdma2000 1x-RTT system is around 30~40kbps [26]. Table 3-1 compares the occupied percentage of overhead to the channel throughput for streaming MPEG-4 FGS video with and without header compression, at various frame rates. Obviously, the overhead occupies a large portion of channel throughput for low-rate streaming. Hence, the header compression is necessary for this kind of streaming scenario. Existing header compression technique such as Robust Header Compression (ROHC) [35] could provide both high compression efficiency and robustness to error. Furthermore, the standard development group such as 3GPP currently takes the issue about header compression into account while providing the packet switched streaming services [36] due to the similar reason.

Table 3-1. Comparison of occupied percentage of protocol overhead on the channel throughput among various frame rates

Overhead

Frame rate Without compression With compression

(Compression ratio = 5)

Channel throughput (kbps) 30 40 30 40

10 fps 26.7% 20 % 5.3 % 4 %

15 fps 40 % 30 % 8 % 5 %

20 fps 53.3 % 40 % 10.6 % 6 %