Menu

Video as a Basic Service of LTE Networks: Mobile vMOS Defining Network Requirements


2015-7-27 mLAB

Huawei released the Mobile Video Service Performance Study Whitepaper at the 2015 Huawei User Group Meeting which garnered much attention in the industry. The whitepaper illustrated the process and methodology for researching the mean opinion score (MOS) of mobile video and pointed out that video content quality and initial buffering latency are the key factors that affect user experience of video services. In addition, the whitepaper presented video MOS evaluation based on mobile networks and human factor engineering, an innovative methodology in MOS study. The sixth episode (MBB Explorer HD Video Certification System) of the Video as a Basic Service of LTE Networks series was released on WeChat. As the seventh episode, this document further discusses how the mobile vMOS defines network requirements. This document provides guidelines on network planning and optimization implementation and reports that the user experience is the primary productive force.

The following describes the key findings of the seventh episode.

1. Principles of Video Play

(1) Video play generally consists of three stages: initial buffering preparation, initial buffering download, and video playback.

(2) Major over the top (OTT) streaming media transmission protocols include HTTP Progressive Download (HPD), HTTP Live Streaming (HLS) proposed by Apple Inc., and Dynamic Adaptive Streaming over HTTP (DASH). Both HLS and DASH support adaptive streams. DASH is proposed by Moving Picture Experts Group (MPEG), a committee formed by the ISO to set standards for digital compression of full-motion video. DASH is the only international standard among HTTP-based adaptive stream solutions and is adopted by popular video websites outside China, such as YouTube (Android), Netflix, and Hulu.

(3) It is commonly accepted that videos based on HLS or DASH generate small amount of buffered data at the initial buffering and downloading phase. However, HPD-based videos generate a large amount of buffered data at this phase. The large amount of buffered data allows for smooth media data playback even if the network is slightly congested.

• In HPD-based mode (one request for one download), the media container format is MP4 and a media file consists of long metadata/data box. The media file size is large and can be played only after the media header information file is parsed and a certain amount of media data is buffered. In this mode, the initial latency is long and user experience is poor. The data volume for initial buffering equals the data volume of an 8s video source.

• In HLS mode (multiple requests for multiple downloads), the media container format is MPEG2-TS, where media stream and metadata are combined to be saved. Each video segment is requested as an independent unit, with the segment duration being 2 to 10 seconds. Each segment corresponds to a uniform resource locator (URL). The segment index file in m3u8 format must be requested before the first video segment is requested. The data volume for initial buffering equals the data volume of a 2s video source.

• In DASH mode (multiple requests for multiple downloads), the media container format is Fragment MP4 (FMP4). FMP4 splits large media data into segments, which consist of groups of metadata/data boxes. Each fragment can be decoded and played independently. The data of each segment is requested through range. The data volume for initial buffering equals the data volume of a 2s video source.

2. Video Code Rate of Different Resolutions

(1) The results in Table 2 are mainly based on mobile video data from YouTube (DASH) and apply to mobile networks. The code rates of video services on fixed networks are higher because of higher video encoding level used on fixed networks.

(2) The recommended code rates in this table are average values.

• The code rates for videos with the same resolution are different because OTT providers use different video encoding profiles.

• The code rates for videos with the same resolution may fluctuate around 35% due to varying video sources.

(3) This document uses a standard way to describe the definition, xp and xK.

• The video definition in the industry is quite unclear, such as LD, HD, ultra HD, original definition, and extreme HD.

• The aspect ratio of the output picture adopts 16:9. The recommended values need to be adjusted for videos with other aspect ratios.

(4) Relationship between definition and video code rate

• Under the same coding algorithm and level, the relationship between definition and video code rate is as follows: 8K ≈ 4 x 4K ≈ 16 x 1080P ≈ 32 x 720p.

• For the same video source, the H.265-based code rate is about 0.6 times that of H.264-based code rate.

(5) The mobile video data of mainstream OTT websites in China (Youku Tudou, iQIYI, Sohu, Tencent, and LeTV) is similar to that described in Table 2. However, the code rates for videos with the same resolution are different because OTT websites use different video encoding profiles. For details about code rate data of various OTT websites, contact mLAB.

3. Principles for Evaluating Bandwidth Requirements of Initial Video Buffering

(1) Impact of RTT and Packet Loss Rate on the Rate in TCP Stable State

• A lower packet loss rate leads to a higher rate in TCP stable state. Under the same packet loss rate, a smaller RTT leads to a shorter slow initiation duration and higher rate in TCP stable state.

• The rate in TCP stable state with 20-ms RTT is twice that with 40-ms RTT and the slow initiation duration shortens by 50%.

• Due to the air interface bandwidth restriction, the TCP throughput must not exceed the bandwidth available from the air interface. Therefore, under the same air interface bandwidth, it is a good practice to improve user experience by reducing the RTT.

• RTT and air interface rate can be converted under certain experience requirements.

(2) Bandwidth Requirement Evaluation for Video Services Under Certain Target Initial Buffering Latency

4. Bandwidth and Delay Requirements of Typical Mobile vMOS Values

(1) The bandwidth requirements for the initial buffering phase can serve as the objective for cell edge coverage planning. The requirements map the HD Coverage Rate KPI. Carrier aggregation (CA) can effectively solve this scenario.

(2) The bandwidth requirements for the playback phase can act as the minimum rate requirement for a single video user bandwidth requirement in the multi-user concurrency scenario under a certain call loss rate. The requirements can be used as the input for rate and bandwidth when planning for xMbps and video coverage solutions.

Note:

(1) In traditional LTE network planning, coverage is generally planned at a 4 Mbit/s rate for a single cell edge user under 50% load conditions.

(2) Three core KPIs are used when video acts as a basic service of LTE networks: HD Coverage Rate (coverage-oriented, with special attention paid to cell edge), HD Experience Success/Congestion Rate (capacity-oriented), and HD vMOS (video-quality-oriented). For details about the KPIs, see Video as a basic service of LTE networks: Core KPIs.

5. vMOS from 3.0 to 4.0 - Typical xMbps Target Rate

(1) To increase the target vMOS from 3.0 to 4.0, OTT providers must upgrade video quality from 720 p to 1080 p and upgrade the video transmission protocol from HPD to DASH.

(2) The video bandwidth requirement increases from 2 Mbit/s to 5 Mbit/s. Accordingly, the xMbps target rate increases by 85%, from 2.59 Mbit/s to 4.80 Mbit/s. For details about the xMbps target rate (average single-user rate and traffic model), see the following *Note.

((3) According to the grid iteration planning methods for xMbps anytime and anywhere, the network capacity expansion dimension must increase by about 100% to satisfy the experience requirement.

*Note:

(1) The traffic model in Table 4 is based on the live network data from a leading European operator. The following describes the information:

• Traffic per user during busy hours: 5MB

The following table lists traffic proportion of each service.

• The proportions of HD video (720p) and SD video (480p) videos are 75% and 25%, respectively.

(2) Assuming that:

• The service baseline rate is listed in the following table.

• The current video baseline rate is 1.0 Mbit/s, which is calculated as follows: 1.5 x 25% + 0.7 x 75% = Mbit/s

• The duration increment factors for video service and other services are 2.0 and 1.0, respectively.

• Average number of concurrent services per user: 1.30

(3) The results are as follows:

Service concurrency rate:

• Video duration: It is assumed that during peak hours, all 5MB traffic for each user is used for video playback. In this case, the peak-hour video duration of a single user is 40s (5 x 8/1.0 = 40s). In the assumption, the peak-hour video duration of a single user is doubled, reaching 80s.

Mobile vMOS provides a comprehensive set of video quality evaluation methods. The sixth episode (MBB Explorer HD Video Certification System) of the Video as a Basic Service of LTE Networks series describes how Mobile vMOS applies to high-definition video quality certification scenario. The document is available on the MBB Explorer mobile clients. As the seventh episode, this document further discusses how the mobile vMOS defines network requirements (bandwidth and latency). This document provides guidelines on network planning and optimization implementation, thereby forming a closed-loop for user experience improvement using video services.