13.4.1 Smartphone Profiling

Smartphone profiling consists of the analysis of multiple protocol layers and their inter-related behavior in complex end-to-end systems. Promoting network friendly smart devices and applications can help operators avoid unnecessary capacity expansions, as well as improve user experience – which will in turn result in better customer loyalty. As will be discussed in more detail in the next section, the user experience depends on various factors, including network performance and the specific application being used. Even the battery life time of a mobile device can be impacted by network features, as well as by well designed and implemented applications. Figure 13.10 illustrates the various components that need to be considered when analyzing smartphone performance.

Some of the features that need to be taken into account when analyzing smartphone performance are standardized by 3GPP. Those features are implemented at the modem chip set level and are either fully controlled by its firmware or partially by the mobile OS. On the network side, the 3GPP features are split between access stratum (i.e., radio access network) and non-access stratum (i.e., core network). A good example of one such feature is the so called “network controlled fast dormancy” or 3GPP Release 8 fast dormancy: when properly utilized, this feature can help optimize the amount of signaling caused by RRC state changes, at the same time that the device battery life is extended by making a better use of the CELL_PCH state.

There are also important features that are implemented outside of the 3GPP domain, such as the operating system of the device. One example of this is the implementation of OS keep-alive messages required for push notification services. Always-on applications use push notification services, which send messages from the network servers to clients in mobile devices. These notifications require persistent TCP connections, which again require periodical keep-alive messages to keep the TCP connection established. The lower the keep-alive frequency is, the fewer transactions that generate additional RRC state changes and signaling.

The implementation of specific applications also plays an important role in user experience and network resource consumption. For example:

• An application that displays advertisements can decide how frequently it fetches new ads from the network. A badly designed ad-funded application generates frequent network transactions, and in the worst case synchronized transactions over the whole user base.
• The coding and packetization used to transmit Voice over IP (VoIP) data can impact the load in various packet forwarding network elements.
• Audio and video streaming apps can select different protocols to deliver the content over the mobile network, and depending on the selected method user experience and battery life time varies. This specific example will be discussed in more detail in Section 13.5.6.5.

13.4.2 Ranking Based on Key Performance Indicators

To analyze smartphone performance, the devices will be profiled based on a set of key performance indicators that rank the network-friendliness of applications and smart devices with regards to key network domains like mobile device, radio, packet core, transport, and IP edge (firewalls, NATs, etc.).

The advised ranking-based methodology presented in this section enables mobile operators to find the ideal balance between the best user experience and the lowest impact on network performance.

Smart devices are tested with real applications or services such as Voice over IP (VoIP), mobile video, and social media in order to emulate as close as possible the behavior of a typical smartphone user. The smartphone profiling provides essential insight into the interaction between factors such as smartphone battery life and applications or operating systems. For example, Figure 13.11 illustrates a comparison between two different smartphones running a social networking application.

The profiling of smartphones provides a relative ranking for applications or devices, based on their behavior in a real environment. This enables mobile operators to make performance comparisons systematically and quantitatively.

13.4.3 Test Methodology

The profiling of a smartphone device is performed both for single applications and with multi-application profiles – in which the device is loaded with multiple commercial smartphone applications such as Facebook, Skype, email, and so on. Both test methodologies will utilize busy – typical use of the applications – and standby test profiles. The standby mode is used to characterize background activity, that is, when the device is powered on, but not actively used. Both profiles are equally important to understand the performance of the devices and applications, as illustrated in Figure 13.12.

• Standby testing reveals specific issues related to OS or applications, like too frequent keep-alive messages or lack of synchronization with keep-alive messages. It also helps to better understand why certain smartphones drain their battery faster than others.
• Tests with busy profiles provide information about busy hour signaling and power consumption of the device as well as protocol behavior of the applications.

The busy profile test cases are application specific and emulate the typical usage of the application. The example in Figure 13.13 is taken from a VoIP application testing with alternating Mobile Originated (MO) and Mobile Terminated (MT) calls, with periods of inactivity between calls to capture all necessary signaling. Call length can be operator specific, but the breaks need to be long enough to capture inter-call signaling.

The standby profile test is simply a one hour test in which the application is activated, although not actively used. This same test case can be used for any application category, and provides understanding of the keep-alive process of the application, as well as useful insight about specific app behavior; for example, in the case of a VoIP call, it explains how presence signaling works in the background.

Figure 13.14 shows an example of a multi-application test.

The multi-application test case in this example includes six different applications, and its main goal is to emulate the typical smartphone user's busy hour behavior. Applications can be operator specific (e.g., top 10 applications), but this profile should not change too often to be able to compare several smartphones over time.

13.4.4 KPIs Analyzed during Profiling

Figure 13.15 illustrates the most typical measurement points and KPIs used for smartphone profiling. It is important to define a set of standard KPIs together with standard test procedures, to facilitate the comparison of applications within the same application category.

The following KPIs are typically used to measure network impact and end user experience. All network KPIs are collected for both busy and standby profiles to understand the impact to different network domains.

• Total radio state change signaling frequency in RNC

  This KPI is used to evaluate the impact on the RNC control plane load. The total number of external (Uu/Iub, Iur, Iu) signaling messages due to radio state changes is measured over time and reported as frequency (msg/min).

• RAB establishment frequency

  This KPI is used for evaluating the impact on RNC and SGSN control plane load, as well as the impact of direct tunnel. The total number of successful RAB establishments per minute (RABs/min) is measured.

  Note that this KPI is not that significant with modern Release 8 fast dormancy smartphones that tend to stay always RRC connected. However, if there are still old devices in the network, then legacy fast dormancy impacts on this KPI.

• Total IP volume

  Total IP volume (bytes) is measured separately for uplink and downlink. When the measurement period is taken into account, the average IP throughput (bits/s) can be calculated. The data volume includes the UE endpoint-specific IP headers.

• TCP/UDP data sessions

  This KPI is relevant for network elements and functions that handle IP flows such as firewalls (FW), network address translation (NAT) and deep packet inspection (DPI) functions. Total number of TCP and UDP sessions is measured.

• Current consumption

  Average current (mA) is measured over the test period. In the case of a smartphone (or a tablet), the total UE current is measured. In the case of a USB dongle, only the dongle current is measured. The current consumption (mAh) is calculated by multiplying the measured average current and elapsed time.

13.4.5 Use Case Example: Analysis of Signaling by Various Mobile OSs

This section presents the results of a smartphone profiling exercise that involved multiple devices using Android, iOS, and Windows Phone. The objective of this test was to analyze the relative performance of each Operating System (OS) in terms of radio network signaling, in particular.

Figure 13.16 illustrates the standby traffic pattern of three different smart devices from three different mobile OSs and highlights the impact of synchronized keep-alive messages. All devices were tested against a multi-application profile, that is, there were several applications installed and activated in each of the tested smartphones.

During the standby tests, most times a new packet needs to be sent, it will trigger a transition in the channel state involving a number of RRC message exchanges. Frequent signaling will impact device current consumption negatively, because every transaction will require several seconds of RRC connection in the Cell_DCH or Cell_FACH channel.

As Figure 13.16 illustrates, there is a significant difference in the standby transfer profile of the operating systems analyzed: iOS and Windows Phone devices tend to transmit less data, and the data transfer is performed in a synchronized manner. By aligning the messages, more data can be transmitted within the same state, for example, Cell_DCH, and fewer RRC state transitions are required.

Figure 13.17 illustrates the number of state transitions for the same multi-application test case. Test results are grouped by non-Android (cases 2 and 3 from the previous example) and Android devices to highlight the difference between operating systems. Both “stand by” and “busy” profiles are analyzed.

As explained earlier, the main difference can be explained by the lack of coordinated keep-alive messages in the Android operating system. The difference is obviously bigger in the “standby” case where keep-alive messages are contributing most of the traffic, but it can be also seen in the “busy” case. The performance variation within Android devices can also be explained by the lack of use of Release 8 fast dormancy in some of the devices.

13.5.1 User Experience KPIs

In a world dominated by data services, defining the right measurements is a key step towards understanding and maintaining proper customer experience. Previously used KPIs, such as access failures and drops, are not so meaningful when referring to data services, as in many cases a data drop will not even be noticed by the consumer. It is therefore important to define a new set of metrics that “make sense” from a data utilization point of view; these metrics will have to be defined at the application level, such as the “time to access video content,” “time to download a web page,” or the “number of rebuffering events” during a video playback.

These complex KPIs cannot be captured using typical counters, and require the deployment of new elements, such as network probes, that can capture per-session data to extract the necessary information. To complicate things further, the KPIs should be able to tell, in the case of a performance issue, whether the problem lies in a specific radio network element or in other part of the communication path. There are various alternatives to implementing these new KPIs, including the use of network probes, leveraging special UE reports provided by applications (Real User Measurements – RUM), and the use of custom UE clients, such as carrier IQ.

Network probes require significant infrastructure and expense to instrument. To manage scalability and cost, they are often deployed near the GGSN/PGW, or only at a few locations. Due to this placement well before the radio interface, they are often limited to connected user experience and cannot measure the impact of connection setup latency or failures. This lack of visibility is significant as the setup latency and failures may have a much large impact on user experience than round-trip delay. Core network probes are therefore good at detecting service failures, or massive numbers of errors, but do not provide an accurate picture of user experience. Alternatively, probes can be deployed at the last mile transport connection, which can capture the effects from the radio access network. This information can be combined with control plane traces from the RAN elements to provide an end-to-end picture of the data connection.

UE reports, also known as Real User Measurements (RUM), are often collected by web sites, applications, and video services. These reports are often very specific to the service and can include time spent on a web page, application launch time, web page launch time, video start time, and various client parameters, to list a few. Since these are done directly on the device, they sometimes include both connecting and connected latency; however, it really depends on the service's goals. This information is not normally available to the carrier so they must instrument their own RUM measurements.

Special UE clients, such as carrier IQ, can also be used to capture the customer experience at the device side. This type of client can provide unique information, such as battery performance, that is otherwise not visible to the operator; these clients can also be developed to capture certain data level KPIs; however, they are typically limited in the amount of information they can capture.

13.5.2 Battery Performance

The battery consumption in smartphones is one of the key aspects affecting customer perception of the device. No matter how fast the device performs, if it can't survive at least one day with a full charge, it will be a nuisance to the consumer, who will need to be continuously looking for ways to charge the phone. Such was the case with early HSPA+ smartphones, and has happened as well to current LTE devices. Apart from the fact that customers tend to use their smartphones much more extensively than previous feature phones, there are clear outliers that have a significant impact on battery performance, some of which can be mitigated by proper device and operating system design.

Figure 13.18 illustrates the result of lab test performed by the T-Mobile validation team, considering a 24-h drain on an active user profile. The key elements involved in battery drain in this particular example are ordered from higher to lower.

As the figure illustrates, the primary source of battery drain is the phone screen. Unfortunately, the screen technology plays a major role here and there are no quick wins to improve this item, apart from playing with dimming and other areas that are really not related to the cellular technology. Next, in this case, is the talk time, which has been extensively optimized as compared to early 3G phones and it is expected to see little improvement in the future.

On the other hand, the chart shows some opportunity to improve the cellular performance when using certain applications, such as web browsing, email, and YouTube. Section 13.5.6 will discuss the impact that app design can have on battery life, through the analysis of various streaming services.

As discussed in Section 13.4.5, it should be noted that keep-alive packets can have much more relevance than is reflected in this chart, due to the fact that lab profiles tend to be less “chatty” than real life situations. There are several possible techniques to mitigate the impact from chatty apps, including special mobile clients that can be used to reshape the signaling behavior of the device. Table 13.2 illustrates the test results of one of these clients, from SEVEN Networks, that shows the potential to optimize the standby mode battery drain. In this particular case, a mixed profile of apps was used and left in background (standby) mode for two consecutive hours in a live network. The device using the optimization client experienced a battery drain of less than half as compared to a regular device.

Another method to improve battery drain is to optimize the use of RRC states: Cell_PCH, Cell_FACH and Cell_DCH, for which the use of Release 8 fast dormancy can play an important role. In particular, devices that spend more time in PCH state tend to fare better in terms of battery life. The charts in Figure 13.19 illustrate the difference in RRC state utilization in two comparable high-end smartphone devices; as the figure on the right shows, the device that makes better use of the RRC states consumes around 25% less battery than the non-optimized device.

The Continuous Packet Connectivity (CPC) feature can also be utilized to reduce the battery drain on smartphones, thanks to the Discontinuous Transmission (DTX) and reception (DRX) features. The gain of CPC depends to a large extent on the type of traffic that is being transferred: for example, it can be quite effective for bursty, interactive applications, such as web browsing or video streaming, but it will not help much in the case of FTP downloads. Figure 13.20 shows the test results from a lab experiment using YouTube video streaming for two different devices.

As the results illustrate, CPC in this case is providing overall battery savings in the order of 6–10%. The apparent low gains from the feature are due to the higher drain caused by the screen, as previously discussed in Figure 13.18.

Finally, it should be noted that the most optimized devices aren't always the best in terms of battery life as perceived by the customer. During our analysis it was surprising to see less optimized devices that were equipped with high capacity batteries, which in the end resulted in a better battery life in the eyes of the consumer.

13.5.3 Coverage Limits for Different Services

The availability of proper signal coverage is a key factor to offer a good service experience: if the signal is too weak, or there's too much interference, the radio layer will drop packets frequently and the connection may be intermittently dropped, which results in delays in the upper layers. In extreme cases, the application data transfer will not be possible and the device will show an error or the application will simply not respond to user actions.

As discussed earlier, not all data services are equal, and some are more resilient than others with regards to radio coverage. In Figure 13.21 we illustrate the results of a lab test in which we executed various smartphone applications at different combinations of signal strength (RSCP) and interference (Ec/No). The objective of the tests was to find the minimum RSCP and Ec/No at which each service could operate. The app behavior at this point depends on the type of service: for example, for web browsing it would mean that the browser provides an error or doesn't show the page at all; for YouTube, the point where extreme rebuffering occurs, and for Skype, the point at which the call is dropped.

As the test results show, data services can generally operate at very weak levels of signal strength, as long as the interference levels are low; on RSCP levels under −100 dBm, the services require a more stringent Ec/No. It should be noted that these were lab tests, and the absolute values can only be taken as indicative.

In general, web browsing is the most resilient data service. It can operate at the lowest signal levels, and can also endure higher levels of interference: it can operate at about 1 dB lower than YouTube, and several dBs below the Skype levels in certain conditions. The behavior of Skype is quite interesting, since it requires a cleaner signal than the other services; this difference is clearer in areas with mid signal strength, in which other services can operate with 3–4 dB higher interference levels than Skype can endure.

This information is particularly interesting to operators when planning the network, or during troubleshooting efforts. Typically, operators can get a relatively good estimate of the RF conditions of specific locations; however, it is much harder to understand what those mean in terms of customer experience. By using simple methods like the one described here the operator can get a feeling for what services are available at which locations.

13.5.4 Effect of TCP Performance

The TCP protocol is the most popular transport protocol used in the IP stack. This protocol ensures lossless, in-order delivery of data between two endpoints, and incorporates error recovery mechanisms, as well as congestion avoidance, to limit the packet loss in periods of heavy load conditions in the link. The TCP protocol was not originally designed for wireless environments, characterized by long and variable packet delays, and if not properly optimized can limit the potential offered by the HSPA+ technology.

To ensure correct packet delivery, TCP requires sending packet acknowledgements from the receiver, which also indicates to the sender the available buffer size in the receiver, called the “receive window.” Similarly, the sender keeps a “transmission window” also known as “congestion window” on its side until the packets have been properly acknowledged, in case they need to be retransmitted. In networks with high latency, a small transmission window can result in a slower speed than the actual link could provide, since packets can take a long time to be acknowledged by the receiver, thus resulting in the queuing of packets in the transmitter. To help avoid this situation, the TCP parameters (in particular, the TCP window size of the receiver) should be adjusted according to the “bandwidth-delay product,” which indicates the effective amount of bytes that the network is able to transmit at any given time. Some OS/TCP implementations, such as Windows Vista and Windows 8, have a built-in TCP windows autotuning function which adjusts the TCP window size based on the end-to-end TCP flow and RTT. This approach has positive aspects, but it can also have side effects: such algorithms do not take the physical medium into account and could conflict with some radio resource scheduling algorithms which try to optimize the data throughput.

Another important effect introduced by TCP is the adaptation of the transmission window to help mitigate congestion situations. To achieve this, the protocol includes two different mechanisms: a probing mechanism called “TCP slow start” by which the transmission window is increased as the initial set of packets get proper acknowledgment, and a congestion avoidance mechanism that adjusts the transmission window when packet losses are detected. The TCP slow start is used at the beginning of the transmission and after a packet has timed out. Figure 13.22 shows how the mechanism works during the FTP download of a file in a HSPA+ network.

Considering the latency in typical HSPA+ networks, TCP slow start will limit the actual bitrates, especially in the case of transmission of small objects in which there is not sufficient time to increase the window size before the file is transferred.

The TCP congestion avoidance mechanism, which is triggered when packet losses or timeouts are detected, can also introduce unwanted effects in wireless. Packet losses, and especially packet timeouts, are frequent in wireless environments, in which small fluctuations of signal or load can cause significant delay variations on the link. When these occur, the TCP protocol responds by reducing the bitrate, however the transient effect may already be gone and the connection speed will suffer unnecessarily.

In the last few years there has been a significant effort to optimize the performance of TCP over wireless, and multiple TCP versions have been developed: TCP Vegas, New Reno, Hybla, BIC, Cubic, and Westwood, among others. In addition to these protocol implementations, many operators have installed wireless proxies that implement proprietary TCP versions specially designed for wireless. Given that operators do not have control over the TCP stack in the Internet servers, the use of wireless proxy is a practical approach to mitigate the challenges from TCP. Furthermore, these proxies have shown better performance in practice than the aforementioned protocols, as the next analysis illustrates.

Figure 13.23 summarizes a study performed in a live HSPA+ network with dual carrier. The test consisted in a single download of a HTTP file under good and poor radio conditions, using various versions of the TCP protocol: BIC, Cubic, Hybla, and FIT. A wireless proxy, implementing a proprietary version of TCP, was also tested as one additional test scenario.

As the results show, the wireless proxy provides the best results in both test scenarios, with a wide difference in good RF conditions and only marginal improvement in poor RF. Additional tests were conducted in a congested area, in which the proxy also offered the best performance, only with a marginal gain. Another interesting TCP protocol is TCP Westwood, which showed good potential in other tests conducted, beating the proxy performance in poor radio conditions.

In addition to the TCP version, an important parameter to adjust is the maximum TCP window size in the terminal device. As discussed before, this window can effectively limit the amount of data that is transmitted to the device, wasting the potential of networks with higher speeds. Figure 13.24 shows the result of a test campaign in a city equipped with dual-carrier HSPA+, in which three different window sizes were tested. The tests were performed in 35 different locations to ensure that they covered many possible combinations of load and signal strength.

In this particular example, the results suggest that the higher window sizes work better for dual-carrier devices. Beyond a certain point (512 kB) the performance differences were not significant, especially in terms of average throughput.

13.5.5 Web Browsing Performance

Figure 13.2b in Section 13.2 illustrated how HTTP traffic accounts for the majority of the data transactions in the network, either directly through the browser or through a specialized app. It is therefore very important to understand the behavior of these services and their performance in a wireless network.

Web services are offered through the Hypertext Transfer Protocol (HTTP) that is typically built on top of the TCP/IP stack. The HTTP protocol facilitates the download of web content, which may include text, images, audio, and video. The web content is uniquely identified and placed in the network using a Uniform Resource Locator (URL).

The HTTP transaction typically involves the download of a main object that contains links to other resources, and the subsequent download of each of those resources. The transfer of each resource is initiated with a “HTTP GET” and finalized with a “HTTP 200 OK” message. Each of the objects on the main page download following the same procedure. Figure 13.25 shows a simplified diagram with the relevant transactions in a smartphone, assuming that in these devices the PDP context is always on:

• First, the UE needs to transition out of the idle or PCH state and initiate a DNS query to resolve the IP address corresponding to the required web page address (URL).
• Once the destination IP address is known, the UE will establish a TCP connection, which is performed using a three-way handshake: the UE sends a “connection request” packet (SYN), the server responds with a “connection response” (SYN-ACK) and the UE confirms that the server's response has been received (ACK).
• After the TCP connection is established, the UE requests a web page object (HTTP GET) and the network sends multiple TCP packets with the relevant information. When the full web page is sent, the server sends a “web page complete” message (HTTP 200 OK).
• The multiple objects indexed in the original web page will also be downloaded following the same HTTP GET/200 OK scheme. The download of these objects can be sequential (in older versions of HTTP), or in parallel if the browser and server supports pipelining (HTTP 1.1).

Figure 13.25 highlights two instances that are relevant to the consumer, a first time (T1), when the first object is downloaded – typically corresponding to the browser indicating some action in the screen – and T2, when the web page is completely loaded, typically corresponding to the time the browser has finished rendering the full page on the screen.

In order to provide a satisfying user experience, the different actions that take place should happen relatively quickly. The study in [2] provides some high-level guidelines that could be applied to web browsing response times:

• Provide some feedback to the user within 2 s. By this time, the browser should have indicated that an action is occurring
• The customer will perceive a good service experience if the task takes less than 5 s. If it takes longer than that, the browser should provide some feedback to let the user know that the system is still at work
• Beyond 10 s, even when there's feedback, users' patience wears thin and the system is perceived as slow.

Considering these guidelines, it is very important to ensure that the network and device are well tuned to provide a responsive web browsing experience. The main challenges to achieve this in HSPA+ are both the connection latency, which is the time to transition from IDLE/PCH to DCH, and the connected latency, or the packet round-trip delay once in DCH state.

The connected latency affects the speed at which packets are acknowledged in the network: the lower the latency, the faster the TCP ACK process, which results in an overall faster download time. Interestingly, in many high speed wireless networks the packet latency can become the bottleneck for interactive services such as web browsing, rather than the actual link speed.

The connection latency plays a major role in the perceived web experience. When the phone is in idle or PCH state, the system needs to spend some time to transition into the high speed mode, which is only possible in the DCH state unless the E-FACH/RACH feature is active. As web browsing transactions are initiated by UE, the very first packet is sent in the uplink direction. When the UE requests radio resources for uplink transmission, it can set a “traffic volume indication,” which is a trigger used for direct transition from PCH to DCH. Since the web browsing session starts with either a DNS query or TCP SYN packet, both of which are small packets, the traffic volume indication is not set. Therefore, transition normally happens in two steps via FACH, which takes a longer time. Chapter 12 provides some measurements of the various transition times, and Figure 13.26 shows the impact on web browsing times on a few example sites.

As Figure 13.26 shows, the additional delay caused by RRC state transitions can be up to 2 s, often representing a significant amount of the overall web download time. This impact can be minimized using different techniques:

• Extending DCH hold timers, however this has negative impacts on battery life and potentially degradation of network KPIs, such as baseband resource consumption and access failures. The use of CPC should help counter these negative impacts.
• Extending FACH hold timers and activating the E-FACH/E-RACH feature if available.

RNC can furthermore use traffic profiling techniques and predict browsing transactions based on recent user activity, and use direct transition from PCH to DCH even if the UE does not set the traffic volume indicator.

Other important factors affecting the web experience are the performance of the device, the operating system (including the default browser), and, to a lesser extent, the terminal category. Figure 13.27 shows a web download comparison for various popular web sites across multiple mobile operating systems: Android 4, iOS 5, and Windows Phone 8. Note that, at the time of the tests, the iPhone could not be tested with dual carrier in the trial network.

The web download results show how the operating system has a significant influence on performance, often beyond the impact of the device category. In this example, the iOS device tested didn't support dual carrier, however it offered a better experience than the dual-carrier devices while in good radio conditions. The effect of dual carrier can be noticed in the poorer RF conditions, where throughput becomes a limiting factor. The Windows Phone 8 device is the one offering a better performance when considering both scenarios.

There are various reasons why Android presented a slower response in these tests, probably the most relevant is the fact that the amount of data downloaded with Android was larger than with other OS since different contents were served for different browsers. Also, the default browser included in Android phones (WebKit) is not well optimized for JavaScript, as Figure 13.28 (left) shows. On the other hand, Android OS offers an alternative browser, Chrome, which presents a significantly improved performance, as the same figure on the right illustrates.

In summary, analyzing and optimizing the web experience is foundational to provide an optimum service experience on smartphones, since many of the apps are based on web content. Achieving the best web browsing experience is not just a matter of optimizing the network, or selecting the best modem for the device; there are other factors like the OS and the browser that play a very important role and also need to be carefully analyzed and optimized.

13.5.6 Video Streaming

Streaming services – in particular video streaming – are perhaps the services that were truly enabled with high-speed radio technologies such as HSPA+. These services require a significant bandwidth that older technologies could not offer, at least not consistently across the network coverage area. Furthermore, as discussed in Section 13.2, video streaming services today represent the main source in terms of data volume in networks dominated by smartphone traffic, with increasing relevance in the coming years – as forecasted by Cisco in their Visual Networking Index analysis [3]. As such, this service represents one of the most relevant and, at the same time, challenging traffic type to be served by the HSPA+ network.

In addition to the high bandwidth demands, streaming services also present significant challenges to the battery life of the device. While playing streaming video, the device will make use of two of the main sources of battery drain in a smartphone, during extended periods of time: the screen and the radio modem.

Video streaming services consist of the constant transmission of video frames over a period of time. The quality of the video source is determined by the frame rate and the resolution of the video frames: in general, the higher the frame rate, and the higher the resolution, the better the quality. There are typically two types of video frames:

• p frames, with a larger frame size, contain the full information required to decode the video image.
• i frames, of a smaller size, contain differential information in reference to the previous p frame.

During a video stream, i frames are typically sent with a higher frequency than p frames; this results in a variable bitrate profile, with instantaneous peaks – corresponding to the transmission of p frames – followed by a lower speed transfer of the subsequent i frames.

To allow time to decode the frames, and to account for possible fluctuations on the air interface, the receiver client implements a decoding buffer that can introduce several seconds of playback delay. This ensures a smooth video playback compensating for differences in delay arrival between packets or temporary packet loss.

13.5.6.2 Video Start Time

Twenty percent of mobile users will abandon a video if it does not start within 10 s [5]. The faster the network, the higher the abandonment rate, so in order to maintain customer satisfaction, it is important that video start time decreases as mobile network speeds increase.

Video Start Time (VST) is an important KPI, but is difficult (costly) to measure from a carrier perspective due to the complexity of the transaction, and it has to be tailored to the specific service that one wants to be monitored. In this section we will discuss two of the most popular video services: YouTube and Netflix.

A YouTube progressive video stream has between four and eight transactions before the video starts. A delay in any of these transactions can have a significant impact on video start time so it is important to include all the transactions in the video start time metric:

1. DNS query for redirector.c.youtube.com.
2. HTTP request for video from redirector and HTTP 302 redirect to nearest YouTube cache.
3. DNS query for redirected address.
4. HTTP request for video from redirected address and either starts downloading the video or receives another HTTP 302 redirect.
5. Steps 3 and 4 can be repeated multiple times depending on the popularity of the video and the location of the YouTube caches.

At the moment of writing this book, the Android YouTube player required at least 5 s of video in buffer before the video will start playing. While this is the minimum required to start the video, the client can store up to 30 s of video buffered by the time the video starts playing. This is due to how YouTube bursts 1 MB (240P) before throttling the connection to 1.25x the video encoded bitrate.

If, however, the initial burst of video is throttled or is slowly downloaded, the client will start the video as soon as it has 5 s of video in buffer. This situation will often trigger video buffering events as the client does not have enough video in buffer to handle the variations in conditions and video bitrate. If buffering occurs, the video start buffer increases to 8 s for the remainder of the video; however, this value is reset when the next video is started.

Figure 13.29 illustrates the YouTube video start time measured with different devices under good and poor radio conditions. As can be observed, the main factors affecting the YouTube performance are the operating system and the device type (single vs. dual carrier).

Netflix uses an adaptive stream: it adjusts the quality automatically based on measurements taken by the client while downloading chunks of video data. The delivery mechanism for Netflix varies based on the operating system of the smartphone; this example illustrates the case of an Android client:

1. DNS query for Netflix Content Distribution Network (CDN).
2. HTTPS session where client sends capabilities.
3. HTTPS session where server sends video bitrates and qualities based on #2.
4. DNS query for Netflix CDN.
5. Multiple HTTP sessions for isma and ismv files – isma are audio files and ismv are video files.
6. HTTP session for index file (.bif), which contains image previews used for fast forward and rewind.

The Android Netflix player requires at least 120 s of video in the buffer for the video to start.

13.5.6.3 Impact of Network Proxy on Video Start Time

Network proxies are often introduced to manage and improve data user experience; however, they can have a degrading impact on video performance. Since video services can vary greatly across the same delivery technology, and proxies often apply the same policy per technology, these policies can negatively impact certain users, devices, and sometimes whole services or technologies. Testing for all scenarios to prevent this is not practical with such a broad range of variables so issues often go undetected for extended periods of time.

Two popular ways to manage video from the carrier side are just in time delivery (JIT) and transcoding. These methods can be used together or separately and both aim to reduce overall video volume, but often have unintended tradeoffs.

Just in Time (JIT) delivery throttles the rate at which a video is downloaded to the client so that just enough video is held in the client's buffer to theoretically prevent buffering. Just in Time delivery's main goal is to manage video “wastage,” or video downloaded and not consumed, but has tradeoffs such as higher battery consumption, more rebuffering, longer video start time, and less efficient delivery leading to spectral inefficiencies.

An extreme example of this is shown in Figure 13.30. In this example, video start time was delayed up to 30 s for longer videos as the proxy was applying buffer tuning before the video metadata was fully transferred. This caused over 50% of the impacted videos to be abandoned before the videos were able to start. It also caused buffering every few seconds once the video started as the buffer tuned rate did not allow for any variation in video bitrate. This is an extreme example but highlights the challenges faced when trying to apply a blanket policy across technologies.

As revealed by the study in [5], JIT does not play an important role in high-speed networks, therefore its gains may be questionable in modern HSPA+ networks.

Transcoding reduces the video bitrate while attempting to keep a similar perceived quality. There are various techniques to accomplish this, including dropping frames, re-encoding the video into multiple formats, and so on. Transcoding requires significant hardware to process the videos and store the content, but can help maintain a decent level of video quality under varying network conditions.

Video services have recognized the need for managing wastage and have implemented client and server buffer management schemes for progressive streams. As mentioned before, many services are also transitioning to an adaptive streaming format, which will capture the benefits of current transcoding techniques. These new schemes of managing wastage, the move to adaptive streams, and the ever increasing speeds of networks have made traditional proxy techniques less relevant for video delivery on HSPA+ networks.

13.5.6.4 Video Quality (MOS)

In addition to video start time, the quality offered during the video playback is a key element to characterize the video service. Video quality is typically measured in terms of video Mean Opinion Score (MOS), and considers items such as frame rate, artifacts due to packet losses, and video interruptions.

One of the challenges associated with video MOS measurements is that, as is the case with voice MOS measurements, the measurement setup requires the transmission of a pre-defined pattern file that will be evaluated by the MOS tool upon reception. This means that video MOS measurements are not possible with on-the-fly content, and the measurements are restricted to spot tests performed by the operator. There are tools that try to estimate video MOS based on real-time measurements from the network, however we won't discuss those in this chapter.

Figure 13.31 illustrates the lab setup configured by T-Mobile's product realization team to perform video quality measurements.

This setup can be used both for video streaming and video calling services. The received video is captured with a camera from the screen of the receiving device, and processed at the video controller device. The test setup provides a controlled environment in which to test various aspects of the video service. Figure 13.32 shows the impact on video MOS from encoding the content with a higher frame rate (left); the chart on the right shows that hardware codecs are able to deliver better performance than software codecs for video calling services.

Another important factor affecting video quality is the transfer rate, which is limited by the radio conditions. Figure 13.33 illustrates the impact on MOS at various test conditions; the chart shows a dramatic video quality degradation beyond a certain point.

13.5.6.5 Streaming Resource Consumption

Until recently, video delivery on mobile networks was treated the same as wired networks – often keeping the radio in an active state for the whole duration of the video consumption. Considering that video is about 50% of network traffic (and growing), developing efficient video applications and delivery is key for both the carrier and user experience: video delivery that is not optimized for mobile networks will increase battery consumption and decrease spectrum efficiencies.

Each video service and technology has their own unique way of delivering video. Progressive streams are delivered in three basic ways – each with their own benefits and tradeoffs:

1. Download the whole video as quickly as possible
   1. Pros: Battery, spectrum, signaling
   2. Cons: High potential wastage.
2. Download the video in chunks every few minutes
   1. Pros: Battery, spectrum
   2. Cons: Small potential wastage, signaling.
3. Download the video at slightly above the encoded bit rate.
   1. Pros: Wastage, signaling
   2. Cons: Battery, spectrum.

Adaptive streaming (e.g., HLS or MSS) downloads each chunk as fast as possible, that is, servers do not throttle the download rate. This is the case, for example, with Netflix (HLS for iOS and MSS for Windows Phone). This results in efficient battery and spectrum usage, while eliminating wastage and ensuring the best video quality given the conditions. Adaptive streams may or may not save on signaling – depending on the chunk delivery pattern and the carrier's T1 and T2 timers. For example, if the video is delivered every 10 s and the T1 timer is 5 s and T2 timer is 5 s, it will create additional signaling for every chunk of data delivered.

Carriers and video service providers often focus on one item while ignoring the others. This leads to non-efficient video delivery for mobile networks. The key for both is to find the right mix to ensure the proper user experience. A video service provider is less concerned with spectrum efficiencies and signaling, and more concerned with battery usage, wastage, and user experience. Luckily, these are related to spectral efficiencies and signaling on the carrier side so there are benefits for both sides from optimizing video delivery.

An example of the above can be seen in Figure 13.34. The same 104-min long movie of standard quality was downloaded in the three ways listed above. Service 1 downloaded chunks of video every 3 to 5 min and consumed 27% of battery on device A. Service 2 downloaded the video throughout the duration of the consumption, which consumed 52% of battery on Device A. By adopting a delivery mechanism like Service 1, the consumer can do more with their device since their battery lasts longer, and the network is able to serve more customers.

Table 13.3 provides the detailed battery consumption for the tested video services.

Device	Service	Consumption of battery life (%)
Device A	Service 2	52
Device A	Service 1	27
Device B	Service 2	80
Device B	Service 1	35

Adaptive streams may have their video and audio combined into one stream, or they can be delivered in two separate streams. This kind of delivery can have a significant impact on user experience and resource consumption, so there is benefit to both the video service and carrier to working together to optimize delivery.

An example of the benefits to the carrier, consumer, and video service are shown in Figure 13.35. Before optimization, this video service delivered video in chunks of video every 6 to 10 s. It also delivered audio and video in two different streams and these streams were not delivered in sync.

The video service changed their video delivery by increasing the chunk duration to 24 s and syncing the audio and video streams together. This decreased battery consumption by 23%, and reduced the time spent on DCH by 54%. This approach resulted in an increase in radio signaling, but the impact was minimal compared to the battery and spectrum efficiency improvements.