University of California Los Angeles
A Study of Mobile Messaging Services
A thesis submitted in partial satisfaction of the requirements for the degree Master of Science in Computer Science
by
Vidyut Samanta
2005
c Copyright by
Vidyut Samanta 2005
The thesis of Vidyut Samanta is approved.
Lixia Zhang
Jens Palsberg, Committee Co-chair
Songwu Lu, Committee Co-chair
University of California, Los Angeles 2005
ii
Table of Contents
1
2
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.1
Background and Popularity of SMS
. . . . . . . . . . . . . . . .
1
1.2
Main Characteristics of SMS behind its success . . . . . . . . . .
3
1.3
Technical Contributions of this Thesis . . . . . . . . . . . . . . .
4
The SMS Network and Architecture
. . . . . . . . . . . . . . .
6
. . . . . . . . . . . . . . . . . . . . .
7
3 Trace Collection and Datasets . . . . . . . . . . . . . . . . . . . .
10
2.1
4
SMS Network architecture
3.1
Call Data Records (CDR) . . . . . . . . . . . . . . . . . . . . . .
10
3.2
SS7 Traces
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
Results of SMS Trace Analysis . . . . . . . . . . . . . . . . . . .
13
4.1
Message Characteristics . . . . . . . . . . . . . . . . . . . . . . .
13
4.1.1
Messages Transmitted . . . . . . . . . . . . . . . . . . . .
13
4.1.2
Message Size . . . . . . . . . . . . . . . . . . . . . . . . .
16
4.2
User Characteristics . . . . . . . . . . . . . . . . . . . . . . . . .
18
4.3
System Characteristics
. . . . . . . . . . . . . . . . . . . . . . .
19
4.3.1
Message Service Time . . . . . . . . . . . . . . . . . . . .
19
4.3.2
Retries . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
4.3.3
Storage Requirements
. . . . . . . . . . . . . . . . . . . .
21
Value-Added, Alert and Application Services . . . . . . . . . . .
22
4.4
iii
4.5
. . . . . . . . . . . . . . . . . . . . . . .
24
Failure Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
5 MMS, Video Streaming and Dynamic Video Transcoding . . .
30
4.6
Conversational Threads
5.1
Previous Work
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
5.2
Design and Implementation . . . . . . . . . . . . . . . . . . . . .
33
5.2.1
Three-tier Architecture . . . . . . . . . . . . . . . . . . . .
33
5.2.2
Transcoding Parameters . . . . . . . . . . . . . . . . . . .
34
5.2.3
Implementation Details . . . . . . . . . . . . . . . . . . . .
36
Measurements of the Transcoding Server . . . . . . . . . . . . . .
38
5.3.1
Testbed Setup . . . . . . . . . . . . . . . . . . . . . . . . .
38
5.3.2
Q-scale Measurements . . . . . . . . . . . . . . . . . . . .
40
5.3.3
Frame Scale Measurements . . . . . . . . . . . . . . . . . .
42
5.3.4
Gray Scale Measurements . . . . . . . . . . . . . . . . . .
43
5.3.5
Energy Measurements . . . . . . . . . . . . . . . . . . . .
45
6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
5.3
iv
List of Figures 1.1
World SMS Market Growth . . . . . . . . . . . . . . . . . . . . .
1
2.1
SMS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2
SMS Interface with Corporate Information Servers . . . . . . . . .
9
4.1
Number of messages per user vs. ranking of users (log-log scale) .
14
4.2
CDF of all Messages vs. Message Size . . . . . . . . . . . . . . . .
16
4.3
Messaging Characteristics of Users (log-log scale). . . . . . . . . .
18
4.4
Message Processing Time . . . . . . . . . . . . . . . . . . . . . . .
19
4.5
CDF of messages vs. retries per message . . . . . . . . . . . . . .
21
4.6
Outstanding Messages in the SMSC . . . . . . . . . . . . . . . . .
22
4.7
Application Services . . . . . . . . . . . . . . . . . . . . . . . . .
23
4.8
Mobility of users while in participating in a thread
. . . . . . . .
25
4.9
Overload during period around December 31, 2004 . . . . . . . . .
29
5.1
Transcoding architecture . . . . . . . . . . . . . . . . . . . . . . .
33
5.2
Frame Scaling for width and height by 50%
. . . . . . . . . . . .
35
5.3
Transcoding operation with a high Q-scale. . . . . . . . . . . . . .
36
5.4
Transcoding Algorithm . . . . . . . . . . . . . . . . . . . . . . . .
37
5.5
CPU usage for different values of Qscale. . . . . . . . . . . . . . .
40
5.6
Throughput for different Q-scales. . . . . . . . . . . . . . . . . . .
41
5.7
CPU usage for different frame size. . . . . . . . . . . . . . . . . .
43
5.8
Throughput for different frame scales. . . . . . . . . . . . . . . . .
44
v
5.9
Energy consumption for different transcoder parameters. . . . . .
vi
45
List of Tables 4.1
SMS Alert Servies . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
4.2
SMS Failure Statistics . . . . . . . . . . . . . . . . . . . . . . . .
28
vii
Acknowledgments When starting a new venture, whether a journey, business or thesis, assistance provided by more experienced travelers is invaluable. I therefore owe an unpayable debt of gratitude to advisors, Dr. Songwu Lu, and Dr. Jens Palsberg, who have adroitly led me through what for me was unchartered territory. My sincerest thanks to Dr. Vinod Kumar Bhudiraja. His cheerful willingness to accommodate my request to collect traces from the SMS network made this work possible. I would also like to thank Nitin Khosla, Girish Thite and Yatin Gujar for providing all the necessary equipment, their insight and support in India. My thanks are also due to Petros Zerfos who has been my mentor and worked with me on the analysis of Chapter 4. I also appreciate the efforts of Ricardo Oliveira, Advait Dixit and Parixit Aghera, in developing the video transcoding server with me, which I present in Chapter 5.
viii
Abstract of the Thesis
A Study of Mobile Messaging Services by
Vidyut Samanta Master of Science in Computer Science University of California, Los Angeles, 2005 Professor Songwu Lu, Co-chair Professor Jens Palsberg, Co-chair
In recent years, cellular networks have witnessed tremendous growth in the use of Short Messaging Service (SMS). In the near future, Multimedia Messaging Service (MMS) is expected to surpass SMS in popularity, traffic, and revenue due to its richer multimedia content such as audio, image and video and greater flexibility. Yet, research in this area has generally been limited, and little is known about the user behavior and system characteristics of mobile messaging. This thesis presents a study of SMS user behavior, and system characteristics based on traces that were collected over the course of three weeks from a nation-wide cellular provider in India that serves over 10 million subscribers. Both message-level and conversation-level messages are characterized, and measurements are presented for person-to-person as well as value-added applicationto-person, and person-to-application services. A statistical study on the failure of SMS messaging is also presented. Last, a dynamic video transcoding system for MMS video messaging and mobile TV, which takes into consideration the
ix
traffic that MMS servers would expect to encounter in the future, is presented and evaluated.
x
CHAPTER 1 Introduction
Number of SMS users (in billions)
1.1
Background and Popularity of SMS
24 21 18 15 12 9 6 3 JAN-00
MAY-00
SEP-00
JAN-01
MAY-01
SEP-01
JAN-02
MAY-02
Figure 1.1: World SMS Market Growth The past decade has witnessed tremendous growth in mobile subscribers, which sequentially has increased awareness of the data capabilities of mobile phones in the market. This can be seen by the widespread success of SMS (Short Messaging Service), downloadable ringtones, and downloadable games [Net05]. Although MMS (Multimedia Messaging Service) and GPRS (General Packet Radio Service) based IM (Instant Messaging) are becoming popular, SMS is the most popular data service for cell phones. Figure 1.1 (from the European SMS Guide [Net03]) shows the growth of the SMS Market since 2000. Today over 200
1
billion messages are exchanged among worldwide subscribers each month[Net05]. In essence, SMS is a service that permits the transmission of short messages (up to 160 characters in length) between mobile phones, handheld devices, and properly equipped landline telephones. SMS was originally designed for GSM (Global System for Mobile Communications) network operators to send their subscribers voice mail, billing, and other network notifications over the network’s signaling channel [PCG00]. These messages were unidirectional; the subscribers could not reply to the sender of the messages. The messages, which terminate at a mobile phone, are called MT (Mobile Terminated) messages. Next came the launch of MO (Mobile Originated) messages that allowed mobile users to send messages among one other for a fee. This caused SMS to evolve and become one of the most successful mobile data services [PCG00, Net03]. More recently SMS networks have converged with IP networks. This convergence has made it possible to send messages from phones to IP networks and visa-versa. It is now widely believed that SMS is the wireless data ”killer app”, because of the endless applications that are now available for SMS in areas of entertainment, marketing, and information sharing, etc. Broadly speaking, most of the applications can be classified into two categories: 1. Alert and notification services: They include news, sports alerts and stock alerts (where users receive SMS alerts whenever the stock price they are monitoring rises or falls above a value that they specify). Email alerts are also provided by many wireless services that can tell the user the subject and the sender’s information of the new email that is received. Weather updates, travel updates from airlines and horoscopes are also alert services that are available.
2
2. On-demand services: They include wireless banking [BCD03], where clients are able to obtain bank balance information through SMS upon request, or they can use SMS to make micro-payments [MRT04]. Google SMS is an excellent on-demand service that allows a user to get precise answers to his/her questions about business locations, driving directions, show times for movies, word definitions, etc., by sending the question to GOOGL and the service sends back an SMS to the user with the answer. Customization service is another type of on-demand service through which users can customize their mobile devices by requesting ringtones, screen savers, games, and pictures. There are also some other applications like Participation-TV. Broadcast graphics companies like [viz] are coming up with new applications in Participation-TV that TV shows use for quizzes and games, so that the audience interacts with the TV show through SMS. Dating services, auctions, and SMS voting are also popular applications. Companies also use SMS for Marketing, by sending promotions in SMS messages to prospective customers. Many cellular providers also allow you to send and receive instant messages on AIM, MSN and Yahoo messenger via SMS. Finally, because of the pervasiveness of SMS, some applications for mobile phones that are written in J2ME and WindowsCE environments also use SMS to send and receive messages from other nodes in the network using SOAP envelopes[BF05].
1.2
Main Characteristics of SMS behind its success
The SMS method of communication exhibits a number of characteristics that can be attributed to its increased popularity:
3
1. Firstly, device support for sending and receiving short messages is almost ubiquitous, ranging from low-end mobile phones and wireless devices like the BlackBerry to Web-interface gateways that can be accessed using ordinary PCs over the Internet. Additionally, the majority of cellular networks around the world support delivery and routing of SMS messages. 2. Second, it follows a “push” model of operation. Messages are delivered to the mobile device in near real-time, making the service the wireless counterpart of Internet-like instant messaging applications such as ICQ and AIM. 3. Finally, it follows the store-and-forward communication paradigm similar to email, in which a message is not discarded if it cannot be immediately delivered, and instead is stored on the server for later retransmission. This makes this type of communication more immune to intermittent connectivity scenarios that are frequently encountered in wireless communication.
1.3
Technical Contributions of this Thesis
This thesis presents an analysis of SMS data traffic based on logs of Call Data Records (CDRs) [3GP03] and SS7 traces [IS497] that were obtained from a nationwide cellular carrier in India. The logs were collected over three weeks, during which more than 10 million mobile users exchanged over 59 million short messages. Although mobile messaging has become very popular with the public and commercially, research in this area has generally been limited. The results of the analysis in this thesis will benefit future messaging systems that will deliver SMS, MMS, email, and instant messaging services in a unified network. The measurement results presented here can also be used as a benchmark for protocol design,
4
performance evaluation, traffic generators, and in provisioning and dimensioning of mobile messaging systems. For example in [Hua03], the authors analyzed the optimal buffer size in SMS, but their results are based on untested assumptions about the message arrival and service times. In another SMS study [Nao04], web traffic traces are used instead of real SMS traces. Both studies could benefit by applying the results presented here to evaluate their models. Finally, the analysis results can be used in planning and provisioning of MMS systems. MMS is believed to follow the trend of SMS in terms of popularity; however MMS messages are substantially larger than SMS messages (about 350 times the size of SMS messages). This implies that the traffic of MMS systems will be much heavier, and it will be necessary to find better techniques for optimization, provisioning and providing improved quality of service for these systems. One such technique is transcoding [STR04, HBL98, FGB96]. Chapter 5 presents a dynamic transcoding proxy for streaming video. This can be used for video clips sent through MMS messages, which are streamed to the recipient’s cellular phone from the MMS server. It can also be used in transcoding for mobile television and streaming movies on cellular phones, which are also expected to become exceedingly popular in future. The rest of this thesis is organized as follows. Chapter 2 introduces the SMS network and its architecture. Chapter 3 presents details about the traces. The results of the trace analysis are presented in chapter 4, including message characteristics, user characteristics and system characteristics, followed by analysis of value-added services, conversational threads, failure of the messages. Chapter 5 describes MMS messaging and presents the design and implementation of the dynamic video transcoding proxy, followed by measurements of the proxy server. Chapter 6 concludes this thesis.
5
CHAPTER 2 The SMS Network and Architecture This chapter describes the protocols and standards used by SMS. It also presents the SMS architecture and explains how a SMS message is transmitted. There are two SMS standards defined by the ETSI (European Telecommunications Standards Institute), i.e., the SMSCB (Cell Broadcast) and the SMSPP (Point to Point): 1. SMSCB (Cell Broadcast): This deals with transmitting a message to all active Mobile Stations (MS) in a network cell that have subscribed to this particular information service. This is a one-way service, and no acknowledgment is sent back. This can be used for transmission of alert services and for network operators to broadcast messages to customers. 2. SMSPP (Point to Point): This deals with sending messages from one mobile to another, or from a computer to a mobile and vice versa. These are the majority of messages stored and transmitted by an SMS Center (SMSC)[IS497, Net03, PCG00]. SMS messages are transmitted over SS7 (the Common Channel Signaling System 7). SS7 is a protocol suite that is adopted globally across telecommunications networks (both wireline and wireless) to provide signaling. It is used to provide control information for call setup, routing, mobility management, supplementary
6
services and subscriber authentication, etc. SMS also makes use of SS7 for signaling and the SMS messages are carried on the SS7 in the Mobile Application Part (MAP)[SMS99]. There are two distinct types of SMS transmission: 1. Mobile Originated SMS (MO): The ability of an SMS network to transmit a message that was sent by a mobile phone. The SMS network can transmit this message to either another mobile phone or an application service. 2. Mobile Terminated SMS (MT): The ability of an SMS network to transmit a message to a mobile phone. The messages could have been sent to the SMS network as an MO SMS or from some application server[IS497, Net03]. The next section describes the network architecture and how mobile-originated and mobile-terminated messages are transmitted.
2.1
SMS Network architecture
Figure 2.1 shows the main SMS network elements and architecture. The system works as follows: 1. A user types a message on his/her Mobile Station (MS) and enters a destination number where it should be sent and sends the message. This number can be another MS or a number for an application server. 2. The message is received by the Base Station System (BSS). The main purpose of the BSS is to transmit voice and data traffic between mobile stations. The BSS forwards the message to the Mobile Switching Center (MSC). 3. The purpose of the MSC is to perform the switching function of the system and to controls calls to and from telephone and data systems [New99]. Upon
7
BSS 1
BSS 2
BSS 3
VLR
HLR
MSC
SMS GMSC/ SMS IWMSC
SMSC
Network Subsystem
BSS: Base Station System MSC: Mobile Service Switching Center VLR: Visitor Location Register, For MO messages it collects end-user information and for MT messages it provides the information about subscribers. HLR: Home Location Register, records all routing information and provides it to GMSC SMSC: SMS Center is responsible for routing and store-and-forward of messages. SMS GMSC: Gateway MSC, receives messages from SMSC, interrogates HLR for routing information and forwards message to appropriate MSC. SMS IWMSC: Inter-networking MSC, receives messages form MSC and relays it to SMSC
Figure 2.1: SMS Architecture
receiving an MO messages, it sends the end-user information to the VLR and checks whether the message violates the supplementary services invoked or the restrictions imposed or not. Then it forwards the SMS messages to the SMSC through SMS-IWMSC. 4. The SMSC stores the message in a queue, instantly records the transaction in the network billing system [Net03], and sends a conformation indicating that it has received the message to the MSC which forwards it to the MS. The billing system uses Call Data Records (CDR), described in Section 3.1. 5. The status of the message changes from MO to MT at this point.
8
6. The SMSC forwards the SMS to the SMS-GMSC, which queries the HLR for routing information and sends the message to the MSC [PCG00].
Traffic Updates Weather Updates SMS Banking
Corporate Servers
Stock Quotes
Connection Gateway
SMSC
Directory Serivces
Figure 2.2: SMS Interface with Corporate Information Servers
7. The MSC receives the subscriber information from the VLR and transmits the SMS to the appropriate MS through the BSS it is connected to. 8. The SMSC is also connected to external systems outside the SMS Network Subsystem. Figure 2.2 shows how Corporate Servers that provide entertainment information, financial information, weather reports, directory services, etc., connect to the SMSC.
9
CHAPTER 3 Trace Collection and Datasets The previous chapter explains how SMS networks work. SMS messages are transmitted over the common channel signaling system 7 (SS7). For every SMS message that is transmitted through the SMS network, there are two types of records which are logged: 1. CDR records, and 2. SS7 records
3.1
Call Data Records (CDR)
Call Data Records (CDR) [3GP03], which are sometimes referred to as Charging Data Records (because they are used for billing and charging purposes), are maintained for every short message that is transmitted through the SMS network. In fact, there are two records for every message sent from one cellular phone to another. One (MO-CDR) is for the Mobile Originating part of the communication (from the originating cellular device to the SMSC), and the other (MT-CDR) is for the Mobile Terminating part of the communication (from the SMSC to the destination cellular phone). Each record logs the information such as timestamp of the event using second-level granularity, Mobile Identification Number (MIN) and Mobile Directory Number (MDN) for the sender and the receiver, number of
10
re-transmissions, the address of the MSC with which the sender (for MO-CDR) and receiver (for MT-CDR) is associated, the result of the delivery, as well as a reference value that can be used to associate the MO and MT records of an SMS. CDR traces were obtained over a period of 24 days that started on 04/04/2005, 15:01:02 and ended on 04/26/2005, 00:00:04. Unfortunately, some periods are missing in the collection process, which accounts for 544,521 seconds.
The
trace consisted of 48,573,312 MO records and 59,612,388 MT records (a total of 108,185,700 records). 5.206G characters were sent and 5.198G characters were received in short messages by 10,854,135 mobile phones. The CDR traces were in a proprietary binary format used by the billing system of the carrier, and were about 16GB in the binary format. Reverse engineering was required to retrieve ASCII values for the fields. In the reference file, each record was 4,816 bytes, which would mean that for the 108,185,700 records, one would need about 500GB. So, a more compact representation of the records, where each record is about 200 bytes was used to make the analysis more efficient. This was done in two ways, first by removing fields that were unnecessary for analysis and second by representing the fields more efficiently via using offsets for fields and representing some strings as integers. After the binary-to-ASCII conversion, the total data was 20GB.
3.2
SS7 Traces
Apart from the CDR traces, it is also possible to get more detailed information about the network and each message from SS7 traces, which were not present in CDR traces. For example, the CDR records have a field that gives the number of retransmissions for each message, however, there is no record that tells us
11
why the previous transmission failed. SS7 traces have this information for each transmission attempt. On the other hand, it is more difficult to collect SS7 traces. One has to connect a SS7 protocol analyzer to the network and has it log all the messages exchanged. The protocol analyzer logs everything from the MTP layer, to the TCAP layer1 . 20 days of SS7 traces were obtained from the carrier. A total of 15GB in compressed binary form was available in 1,497, 10MB files. Each 10MB file is about 700 MB when decompressed and converted to ASCII. The conversion process requires special software that takes about 40 minutes for each file. Due to resource limitations, it was impossible to decompress and analyze the entire SS7 trace. Instead, snapshots of the trace were analyzed. 10-minute snapshots taken at five different times of the day (9:00AM, 12:00PM, 6:00PM, 10:00PM and 2:00AM) for two weekdays and two weekend days were used for the analysis, which contained a total of 1,263,971 messages. This was used for studying the message failures.
1
See [IS497], for more details about SS7
12
CHAPTER 4 Results of SMS Trace Analysis This chapter presents an analysis of the SMS traces obtained from the nation wide cellular carrier in India. First, statistics of short messages are presented and characterized, then user and system level characteristics are presented1 , followed by some statistics on value-added services. Next, conversational threads of SMS messages are analyzed. Finally, the failure of SMS messages is analyzed from SS7 trace data.
4.1
Message Characteristics
4.1.1
Messages Transmitted
Figure 4.1 plots the number of messages sent or received in one week by each user on the y-axis versus the rank of the user on the x-axis in log-log scale. The data set contains 3,398,497 users. Users are ranked in a descending order according to the number of messages that they send or receive. That is, the user ranked in the first position is the one who sends/receives the most messages, the second position is the one who sends and receives the second most messages, and so on. Since SMS is mostly a person-to-person messaging service, one would expect that over a period of a week most users would send and receive a relatively small 1
The charging model of messages may influence the user behavior. The carrier whose traces are analyzed here charges users per MO-message.
13
1e+06 SMSs Sent SMSs Received MMS notifications Received Ringtones Received
100000
Number of messages
10000
1000
100
10
1 1
10
100
1000 10000 Rank of Mobile User
100000
1e+06
1e+07
Figure 4.1: Number of messages per user vs. ranking of users (log-log scale)
number of messages, in the order of a few hundred messages for the most active users. From the figure, we can verify that this assumption holds true for the majority of mobile phone users. We can see that the majority of users send and receive less than 10 messages, and most of them just one or two messages over a week. Then, there are a constant number of users at each level who exchange 10 to a few 100 messages. However, we also see from the figure that there are a large number of users who feature in the top ranks for sending and receiving SMS messages, that send and receive more that 1,000 messages. There are many users that exchange more than 10,000 messages. These obviously cannot be explained by human activity. These messages are application-to-person and person-toapplication for value-added application services. This conjecture was verified
14
by identifying the top SMS senders and receivers; they all have a 4-digit MIN number (phone number), which corresponds to various value-added services (like news, stock quotes, movie updates, online banking, dating, game play, interactive television, etc). Table 4.4 lists some of the top value-added services and describes what type of services they offer. Section 4.4 presents results about the popularity of these services. As the use of SMS in the form of a value-added and application service grows more popular in the future, such application-to-person (or even application-toapplication) traffic might easily surpass the message volume required by personto-person communications. This can already be seen in the application-to-person service that provides ringtones. Ringtones are song-like melodies that are played by mobile phones to indicate an incoming message or phone call. Most modern phones allow users to set multiple ringtones to identify different people from their phone book. The most popular ringtones are Monophonic ringtones and can be transferred over an SMS message, since they are encoded in the text format using the RTTL (Ring Tone Transfer Language) encoding which was developed by Nokia [RTT]. A mobile user requests a ringtone by sending an SMS to an application service. The application sends back the RTTL encoded ringtone. The CDR traces distinguish ringtones from other SMS messages, which made it possible to analyze the number of received ringtones. From Figure 4.1, one can also see that there are about 20,000 users who have received between 30 to 100 ringtones during the one-week period. Figure 4.1 also shows MMS notifications received. When a user receives an MMS, the message is stored in the MMS server and a notification is sent via SMS that points a link to the MMS message. The message can be downloaded using WAP or from a computer connected to the Internet. An average MMS user
15
receives many more MMS messages, compared with that an average SMS user receives SMS messages.
4.1.2
Message Size
100
CDF of messages (%)
80
60
40
MO-SERVERS MT-SERVERS
20
MO-USERS MT-USERS RINGTONES
0 0
20
40
60
80
100
120
140
160
Message Size
Figure 4.2: CDF of all Messages vs. Message Size
The maximum length of a SMS message is 160 ASCII characters. Larger messages can also be sent but they are fragmented into smaller messages of 160 characters by the mobile device. However, as far as the SMS network is concerned, each fragment is treated as a separate message, and it may be delivered out of order. Figure 4.2 plots the cumulative distribution of the size of the message payload, both for messages sent and received by mobile users (”MO-Users” and ”MT-
16
Users,” respectively), and messages that were sent to/from SMS-based valueadded and application services (”MO-Servers” and ”MT-Servers,” respectively) during a week. The cumulative distribution of the size of ringtone messages is also plotted in the same figure. From the figure one can make the following observations: 1. For person-to-person messages (”MO-User and ”MT-User”), the messages composed by users seem to span the entire range of message sizes with equal probability. However, there seems to be a large number of messages with the size of 140 characters, which seems to be the fragmentation limit of some old mobile phones. 2. For person-to-application messages (”MT-Servers,” which are messages sent by mobile users requesting services from applications), the majority of messages (up-to 96%) have small message size, less than 60 characters. This is due to the fact that usually only very limited information needs to be sent to an application for most services, such as the zip-code of the area for weather information, or the stock symbol for stock quotes, or a code that represents a certain ringtone request, etc. 3. For application-to-person messages (”MO-Server”), they exhibit very different behavior compared with all others. The reason is that most services use pre-formatted messages which values center around specific values. For example, about 40% of the messages have a size between 67 and 106 bytes. 4. For ringtones, they are also clustered around certain lengths. The reason for this is that most ringtones are based on popular songs and tunes that are composed of a fixed number of notes or chords, which repeat throughout
17
the song. Most songs have one or two chords or melodies that are composed of a fixed number of notes.
4.2
User Characteristics
10000000
10000000
1000000
1000000
100000 Number of Senders
Number of Receivers
100000
10000
1000
100
1000
100
10
10
1
1
0.1
0.1 0.1
10000
1
10
100
1000
10000
100000
0.1
1000000
1
10
100
1000
10000
100000
Number of Receivers
Number of Senders
(a) Number of receivers v/s number of (b) Number of senders v/s number of unique senders
unique receivers
Figure 4.3: Messaging Characteristics of Users (log-log scale).
Most SMS users send and receive messages to a relatively small number of people, typically their friends and business associates. We can test this hypotheses from Figure 4.3(a) and Figure 4.3(b). Figure 4.3 (a) shows the number of unique receivers for different numbers of senders, and Figure 4.3(b) shows the number of unique senders for different number of receivers. We see that about 70% of users send messages to one receiver and receive messages from one sender2 . 90% of the users exchange less than 50 messages. However, a few users send and receive 1,000s of messages. They are identified as application servers, based on their 4-digit phone numbers. 2
The set of users who send messages to one receiver is not the same set as the users who receive messages from one sender i.e. the communication between these users is not necessarily symmetric.
18
4.3
System Characteristics
This section presents an analysis of the SMS system. The storing-and-forwarding characteristics of the system are analyzed using traces.
4.3.1
Message Service Time
100
Delivered Denied Expired
CDF of number of messages (%)
80
60
40
20
0 1
10
100
1000
10000
100000
1e+06
message service time
Figure 4.4: Message Processing Time
Message service time is the amount of time a message stays in the messaging system before being delivered. This time can be calculated from the CDR traces by comparing the timestamps of the MO and the MT messages. The CDR traces classify messages into three categories: 1. DELIVERED: Messages that were successfully delivered. 2. DENIED: Messages that could not be delivered because the receiver either refused or were not authorized to receive the message.
19
3. EXPIRED: Messages that expired before they reached their destination. Each message has an expiration period that can be set by the sender of the message. The expiration period determines how long the network will attempt to deliver a message before deleting it. In the trace, 94.9% of the messages were delivered, 3.5% were denied, and 1.6% expired. Figure 4.4 shows the cumulative distribution of all three types of messages. The figure shows that among the messages that are successfully delivered, 73.2% reach their destination within 10 seconds; this validates SMS as a “near real-time” service. 17% of the messages need more than 1 minute to be delivered, and 5% need over 90 minutes to reach the intended receiver. The service time can be attributed to factors such as processing time at the SMS center, address resolution at the HLR/VLR servers, network and radio resource shortage[IS497]. However, the majority (over 90% of the message latency) is due to the destination being unreachable (e.g. the phone is powered off, in sleep mode, out of coverage, etc.), which can be verified by the results of Section 4.6.
4.3.2
Retries
Figure 4.5 plots the CDF of the number of messages verses the number of retries per message. The SMSC attempts to retransmit messages that were not delivered, until they are successfully delivered or they expire. The SMSC runs a retry algorithm, which dictates when it should retransmit messages that have failed during previous delivery attempts. The time interval since the last delivery attempt is dictated by the cause for the failure of the previous delivery attempt. Typically a failure due to mobile memory being full, for example, will have a retry time of a few minutes, while failures due to other reasons may have longer retry
20
100
CDF # of messages (%)
80
60
40
20 Delivered Denied Expired 0 0
2
4
6
8
10
12
14
16
18
20
22
24
26
28
30
32
# of retries/message
Figure 4.5: CDF of messages vs. retries per message
times [SO2]. The upper limit on the number of retires for an SMS message is 255. However, 99% of messages are delivered during the first 5 attempts. Among them, 24% are delivered by a single transmission.
4.3.3
Storage Requirements
Figure 4.6 plots the outstanding messages at the SMSC server over a period of five days. For every second of the trace, a counter is kept that increases as mobile-originated messages are received by the SMSC server. It decreases when mobile-terminated messages are transmitted from the SMSC server to the recipient, when they expire, or if they are denied. The Figure shows that the number of overall messages fluctuates on a daily basis, but is in the order of tens of thousands of messages. Although the storage requirement seems to be low considering that the maximum size of a message is 160 bytes, these statistics
21
Number of outstanding messages/second
90000 80000 70000 60000 50000 40000 30000 20000 10000 0 04/07
04/08
04/09
04/10
04/11
04/12
Figure 4.6: Outstanding Messages in the SMSC
may serve as an indicator for future demand when MMS messaging becomes as popular as SMS messaging.
4.4
Value-Added, Alert and Application Services
In [ABQ02] the authors study the notification and browse services provided by a large commercial website designed specifically for users who access it via cell phones and PDAs, to understand system load, type of content accessed and user behavior. They find out that most messages sent to the system and from the system are small in about 120 bytes, similar to the results in Section 4.1. They also analyze the popularity of various categories of services that users subscribe
22
10000000
SMSs Sent SMSs Received 1000000
Number of Messages (Log-scale)
100000
10000
1000
100
10
Nazara
Mobile Teleshoppe
Hungama
Exams Results
Positive Comsol
Sify
93 Number search
Mobile 2 Win
Reliance Contest
NDTV
ACL Wireless
AajTak
Reliance Services
CNBC TV 18
Sony
IRCTC
Sahara TV
Rediff
Yahoo India
Zee TV
Star TV
Indiatimes
Active Media
Reliance 1234
1
Figure 4.7: Application Services Number
textbfService
Description
1234
Reliance 1234
SMS Banking, Ringtones, Dating, Cricket, Jokes, Astro, Guides, Quotes
8888
Indiatimes
News, Astro,Stocks, Cricket, Jokes, Games, Ringtones, Poll, Contests, Shopping
3636
Active Media
Cricket, Contests, Ringtones, Logos, Pictures
7827
Star TV
Voting interactive TV, Contests
7575
Zee TV
Interactive TV
7333
Rediff
News, Astro,Stocks, Cricket, Jokes, Games, Ringtones
8243
Yahoo India
Ringtones, Wallpaper, Picture messages, java games
9090
Sahara TV
Astro, Cricket, Jokes, News, Ringtones
2525
Sony
TV, Contests, Cricket
7245
IRCTC
Indian Railway Tickets
2622
CNBC TV 18
News, Quotes
2424
AajTak
News, Quotes
3733
Reliance Services
Operator Services
6388
NDTV
Flight Schedules
6767
ACL Wireless
Query and Response, Chat
2345
Reliance Contest
Contests
8558
Mobile 2 Win
News, Jokes, Opt-in-reminders marketing
4545
Sify
News, Cricket, Stock
9393
93 Number search
Phone directory service
3030
Positive Comsol
Enterprise services
3926
Exams Results
Exam Results
4646
Hungama
Jokes, Polls, Cupones
6363
Nazara
Download games
3456
Mobile Teleshoppe
Teleshopping
Table 4.1: SMS Alert Servies
23
to. In their study they found that the most popular categories of services are Weather, Mail, Horoscopes, News Sports and Stock Quotes in the order of popularity. Personalization, Lottery and IM Note Engine are not as popular. However, for SMS value-added services, the popularity of services is quite different. Figure 4.7 shows the most popular-value added services available, and the number of messages sent and received by each of the services. The messages sent by these services amount to 11% of the total SMS messages in the trace, and the messages received by the services amounts to about 7% of the total messages in the trace. Table 4.4 describes each service. The services that provide ringtones, personalization, entertainment and contests linked to TV are the most popular services. The services that provide only news and stock quotes are less popular. Other services that provide flight schedules, exam results, etc., are the least popular.
4.5
Conversational Threads
As mentioned earlier, SMS was originally designed for GSM network operators to transmit voice mail, billing, and other network notifications to their subscribers. It was designed to be a one-way messaging system for notifications. However, once cellular network operators allowed users to send SMS messages amoung one another, it evolved into a two-way person-to-person messaging system, similar to the popular IM services (e.g. AOL instant messenger, MSN messenger, Yahoo messenger etc.) on the Internet. Today people carry out conversations over SMS. They set up meetings, send each other updates, and even greeting messages. Most messages sent by one person to another, result in a reply message, and might prompt a further response message. Nonetheless, SMS was not designed to support this kind of conversational or thread messages to be exchanged. The messages exchanged between two users are not associated in any way with
24
each other, even though they could be a conversational thread. An analysis of conversational threads, studying their length (in terms of number of messages exchanged) and the mobility of users (in terms of the number of MSCs they visit while part of a conversational thread), can help us to determine whether alternate messaging systems could help to improve system performance, and understand the performance of immediate messaging networks [3GP02] with internet messaging systems. For example, it may help us to calculate the number of concurrent TCP sessions that should be supported by the server, if TCP is used in the future messaging system.
thread length vs. thread duration for all mobility levels (10 mins time thresh)
length messages/thread Threadthread Length (# (#ofofmessages per thread)
1000 1000
100 100
1010
11 0.01 0.01
max # of MSCs = 2 max # of MSCs = 3 max # of MSCs = 4 max # of MSCs = 5 max # of MSCs = 6 0.1 0.1
10 11 10 threadDuration duration (mins) Thread (minutes)
100 100
1000 1000
Figure 4.8: Mobility of users while in participating in a thread
Figure 4.8 plots the conversational thread length (i.e., the number of messages exchanged in a conversation) verses the duration of the thread in minutes. The
25
messages were grouped into threads following the approach of [DWF03]. The duration of the majority of threads is between 5 and 20 minutes. The average thread length is about 5 messages. The figure also shows mobility (i.e., the number of MSCs visited) by the users participating in a conversational thread. The majority of users are not mobile when participating in conversational threads. About 87% of the users are static, that is, neither user participating in a conversation changes the MSC it is connected to initially. This means that for 87% of conversations, we could use a connection-based TCP like protocol for the exchange of messages, and this could be handled by the BSS. A maximum number of six MSCs was visited by two users when participating in a conversation.
4.6
Failure Analysis
Since the CDR traces are generally used for billing information, they do not have any explanation on why a message failed to be delivered. They only provide the number of failures (i.e., the number of retries), and they give the final outcome of the message as delivered, expired, or denied (explained in Section 4.3). To better understand why messages fail and to study failure with mobility and with load, we need more detailed traces that can only be obtained at the SS7 level. The SS7 trace (see Section 3.2), was analyzed for the different failure causes. There were 1,263,971 total messages in the trace, and 91,800 or 7.2% of them had failed for some reason. There were 13 different causes for the failures: 1. SMS delivery postponed: Delivery is not currently possible, because the destination can not be reached or is busy. 2. Destination no longer at this address: The receiver is no longer at the temporary SMS routing address.
26
3. Network failure: A network node failed, a link failed or a required operation failed. 4. SMS termination denied: The destination is not authorized to receive the SMS message. 5. Encoding problem: The size of a parameter or field is not what is expected. 6. Network resource shortage: Network transmission failed due to the lack of network resource or link capacity. 7. Unrecognized parameter value: A known parameter has a unknown or unsupported value. 8. Missing expected parameter: An optional parameter that is required for a particular function. 9. Address translation failure: The SMS Destination Address is invalid, which usually means the phone number of the destination is invalid. This probably shows up as a denied message in the CDR trace. 10. Invalid Teleservice ID: The SMS Teleservice Identifier is not known, is not supported or is not authorized by an addressed functional entity. A teleservice supports SMS supplementary services like delayed delivery or message distribution to a list of destinations. 11. User Data size error: The User Data size is too large for access technology, transport network, or call mode, etc. The User Data size is not what is expected for the indicated teleservice. 12. Other radio interface problem: Radio interface of the receiver has some problem.
27
13. Other general problems: This is set by the operator. Failure Cause Code
Number of Messages % of total failed
SMS delivery postponed
82700
90.08
Dest. no longer at this address
5117
5.57
SMS termination denied
2883
3.14
Unrecognized parameter value
461
0.50
Network resource shortage
322
0.35
Network failure
100
0.11
Encoding problem
93
0.10
Address translation failure
54
0.06
User Data size error
53
0.05
Invalid Teleservice ID
6
0.006
Missing expected parameter
5
0.005
Other radio interface problem
4
0.004
Other general problems
2
0.002
Table 4.2: SMS Failure Statistics
Table 4.6 gives the number and percentage of messages that failed for each of the cause codes described above. 90% of the messages failed due to SMS delivery postponed, because the destination cannot be reached or is busy. 5.57% of the messages failed because the destination has changed its location, i.e. these are failures due to mobility. Another 3.14% failed because of destination is not authorized to receive SMS messages. 0.35% of the messages failed due to network resource shortage, which can also be thought of as failure due to system load. However, this percentage would increase a lot during a high-load period such as during special events like New-Years Eve, the World Cup Cricket match, Diwali
28
festival, etc. Even though each SMS message is just a few bytes, such events can cause overload incidents that may even disrupt the entire network. For example, Figure 4.9 plots the variation of SMS message arrival rate during the period of [12/29/2004, 01/03/2005]. The figure shows the overload incident around 01/01
Message arrival rate (messages/second)
that has 8 times the normal load.
600
500
400
300
200
100
0 12/29
12/30
12/31
01/01
01/02
01/03
Figure 4.9: Overload during period around December 31, 2004
During such overload events, the operators turn off delivery notifications, to reduce the overall load. However, with 8 times the normal load, this is not sufficient to prevent the services from being disrupted. The only way to solve the overload problem in SMS is by over-provisioning network resources. However, in MMS systems there is more chance to be able to recover from overload events by using techniques such as transcoding to reduce load on the network. This is explain in Chapter 5.
29
CHAPTER 5 MMS, Video Streaming and Dynamic Video Transcoding SMS was an unintentional success story in the cellular industry. It has grown into the most popular wide-area wireless messaging application. Its use has been considerably expanded by web and application services, a result of the convergence of the cellular network and the Internet. After witnessing the success of SMS, the cellular industry introduced the Multimedia Messaging Service (MMS), which allows users to send messages that can include digital photographs, audio, and video clips, in addition to text. The majority of cellular phones are now equipped with cameras, which enable users to capture and send small video clips and photographs through MMS. Moreover, since the Internet is a media rich environment, MMS messages will allow for web and application services to send media rich messages to their customers. The MMS architecture is very similar to SMS. The MMS-Center(MMSC) is at the hart of the MMS network and is similar in functionality to the SMSC. However, MMS messages can be much bigger in size than SMS messages. The average size of a SMS message is 140 bytes, where as for MMS, the messages can be around 50,000 bytes; that is about 350 times larger. Also MMS messages are transmitted using the Wireless Application Protocol (WAP)1 over GPRS or 1
For more information on WAP refer to WAPForum. [WAP]
30
UMTS, rather than the GSM channel. WAP also permits streaming audio and video content on wireless devices. This makes it possible for the receiver of a MMS message that contains a video clip to watch it as a streaming video from the server. It is also possible to stream larger videos on modern mobile phones even though the phone’s memory is limited. Many operators are now allowing their clients to view live TV on their mobile phones through services like mobiTV[MOB]. In December 2004, Airtel India, a nation-wide cellular provider, premiered an entire movie in streaming video to their customers [AIR]. Most operators predict that in the near future, MMS and streaming video on mobile phones will follow the success trend of SMS. Hence, high on the research agenda are the issues of reliability, timely delivery, scalability and overload control of these systems. In addition another challenge for streaming video is to provide video that can be played on heterogeneous mobile devices with different screen resolutions, color support, processing power and network connectivity. In order to serve the same multi-media content to these heterogeneous mobile devices and to provide reliability, scalability and overload control, middleware proxy servers that transcode content to fit different types of mobile devices are becoming popular[STR04, HBL98, FGC97, FGB96]. In this chapter, a three-tier architecture for a video transcoding proxy, is presented. The transcoder enables dynamic changes in different transcoding parameters during a video streaming session. In addition, several tests conducted with different combinations of these parameters and presented. They show their impact on bandwidth usage of the client device, CPU, and energy consumption of the proxy server. The perceived bandwidth that a mobile phone consumes changes continuously due to varying characteristics of the wireless channel, e.g., fading and interfer-
31
ence. Furthermore, one can anticipate flash crowd events for MMS and mobileTV subscribers. In these scenarios, if we want to maintain the playback quality of the streaming video, the transcoding server has to adapt dynamically when there is a change in the bandwidth of a particular connection or when the server is overloaded during a flash-crowd event.
5.1
Previous Work
Previous work such as [WOM00] proposes an architecture for a dynamic video transcoder. It present a control algorithm, which adapts transcoding to the varying network bandwidth of a 3G-network device. The algorithm relies on experimental correlations between encoding bit-rate and frame rate for a given quantization scale, but lacks data on proxy resource consumption to determine desired transcoding. [CC02] proposes a transcoding algorithm that integrates error control schemes into the transcoding. It presents a two-pass video transcoding scheme that allocates bits between source coding and channel coding. [LK03] proposes a rate control scheme that adjusts the frame rate and frame quantization step to achieve good temporal-spatial quality tradeoff. In [KG01], the authors describe an interactive TCP layer. This layer communicates with the control module of the video transcoder to achieve better congestion management and video quality. An architecture for a transcoding server is described in the next section. A systematic evaluation of the impact of transcoding parameters on the transcoding server is also presented.
32
ENCODER FRAME SIZE
CLIENT DEVICE
DECODER
CONTENT SERVER
Q-SCALE COLOR
CONTROLLER
FEEDBACK
TRANSCODING PROXY
Figure 5.1: Transcoding architecture
5.2
Design and Implementation
This section describes the design and implementation of an open-source dynamic video transcoding proxy based on a three-tier architecture that can easily be integrated in a production middleware system, which can be placed with the base station subsystem.
5.2.1
Three-tier Architecture
The three-tier architecture for the video transcoding proxy is illustrated in Figure 5.1. Tier-1 consists of the content server, or the MMSC which provides one fixed quality video stream to the transcoding proxy. The content server is typically a network of file servers with load-balancing mechanisms. The proxy uses the Cascaded Pixel Domain Transcoder (CPDT) scheme initially proposed in [YS00], which consists of an encoder connected to a decoder. This is a flexible architecture, since the frame is fully decoded to raw pixels and reencoded. The controller module controls transcoding by changing the frame size,
33
Q-scale (or quantization scale) and color transcoding parameters for encoder. These parameters can be adjusted using a control algorithm, which takes into consideration the client device’s profile, user’s preferences, proxy-server resource usage, and network bandwidth available at the client’s device. The controller can have access to a client device’s profile and user preferences from user database that it can maintain, or it can get that information upon the content request and it can get a client’s available network bandwidth information directly from a client device or by monitoring the network conditions. The dotted line in Figure 5.1 between the client device and the controller is an optional communication link between those modules. The client device is used by an end user to view the video streaming and is characterized by its screen size, color depth, processing power and network connectivity. This is typically the mobile phone.
5.2.2
Transcoding Parameters
This section provides the description of the transcoding parameters that can be changed dynamically.
5.2.2.1
Frame Size
This is the size of the video frame. It can be initially specified based on the client’s screen size. Section 5.3 presents the measurement results of streaming video with different frame sizes. The results show that smaller frame sizes can take up considerably less network bandwidth. If the client is experiencing network congestion when streaming a video, the parameter on the transcoding proxy can be dynamically changed. The size of the frame is then reduced and the client
34
receives continuous streaming but with smaller frame size (Figure 5.2). One could extend the proxy further to support handoffs between devices, where the dynamic scaling of the frame size would be very useful for devices with different screen sizes.
Figure 5.2: Frame Scaling for width and height by 50%
5.2.2.2
Color Depth
MPEG standard specifies a single pixel format where each pixel is represented in the YUV scheme, where Y is the luminance, and U and V specify the chrominance [MPE]. Because each pixel is represented in 12 bits (e.g., 4:2:0 planar format), we expect minimal performance improvement by changing the video to gray scale.
5.2.2.3
Q-scale
The Q-scale is a parameter used to compress a given block of a video frame. Each block is a 8 × 8 pixel square to which a DCT (Discrete Cosine Transform) is applied (similar to JPEG encoding). The coefficient Cij of each block is then divided by a quantization matrix Mij and a quantization scale q:
Cij0 =
Cij q · Mij
35
(5.1)
The encoder quantifies the values of Cij0 that are bellow a certain threshold to zero. Each block is then fed into a RLE module (Run Length Encoder) that performs zigzag encoding to ensure better compression. A very high Q-Scale will offer a “pixilated” look to a frame (Figure 5.3) due to the loss of high frequency components in each frame block.
Figure 5.3: Transcoding operation with a high Q-scale.
5.2.3
Implementation Details
The video transcoding proxy was implemented using Tinyproxy [TIN] and FFserver [FFM]. Tinyproxy is a lightweight http proxy server licensed under GPL. FFserver is a streaming server for both audio and video licensed under LGPL. FFserver provides two codec libraries (libavcodec and libavf ormat) that can be used to encode and decode MPEG video. In this project tinyproxy is modified and integrated with the FFmpeg libraries so that it would be able to decode and encode a video stream. The client initiates the transcoding process by sending its device specification, along with the request for a video to the proxy. If transcoding is required, the proxy begins to get the requested video stream and decode each frame. It then re-encodes the frame by applying the parameters specified by the client during
36
encoding and streams it to the client device. Q-scaling, frame scaling, and altering color depth are implemented when re-encoding the frame at the proxy. Start
End of stream?
Yes
Stop
No Fetch frame from input buffer
Does frame need transcoding?
No
Yes
Decode frame
Have transcoding parameters changed?
Yes
Change codec
No Encode frame
Store frame in output buffer
Figure 5.4: Transcoding Algorithm
The transcoding then works as follows: Tinyproxy has one parent process, which spawns multiple http server processes that will serve incoming http requests from clients. Tinyproxy was modified so that it spawns an additional child, which serves as a dynamic transcoding request handler. The controller connects to this request handler on the proxy.
37
The algorithm for the transcoder is shown in the flowchart of Figure 5.4. If the input frame meets the transcoding requirements, it is directly sent to the output buffer without being decoded and re-encoded. Otherwise, the frame is decoded. Then, the codec is changed by the transcoder if the transcoding parameters have changed since the last frame was decoded. The frame is then re-encoded with the current codec and stored in the output buffer, where it is streamed to the client.
5.3
Measurements of the Transcoding Server
To understand how the transcoding system reacts to different configuration parameters, the following measurements were taken on a test-bed: 1. CPU usage at proxy 2. Bandwidth usage at client 3. Energy consumption at proxy
5.3.1
Testbed Setup
For each of the above measurements, different transcoding parameters (Q-scale, video frame size and gray/color scale) were used. All the CPU measurements were done at the proxy and throughput measurements were done at the client machine. M P layer [MPL] was used at the client side to play the video streams. CPU usage was computed as the CPU time spent by the transcoder during the entire video stream. This CPU time has two components: user time and system time. The user time is the CPU time allocated to the main user-level process and all its children, while the system usage is the CPU time allocated to kernel
38
processes (i.e., disk I/O, network access) during the user process execution2 . All CPU measurements presented here refer to the total time (user + system). T cpdump [TCPa] was used to trace the downstream TCP connections at the client side. These trace files were analyzed using T cptrace [TCPb]. Tcptrace calculates several statistics about a given TCP connection, including the overall throughput of the connection. Energy measurements were taken on a laptop with 1.8GHz AMD processor and 512MB of RAM configured as the proxy. Since energy measurements were very sensitive to other processes running in the system concurrently with the transcoder, all unnecessary processes were turned off, leaving only the transcoding proxy server and some kernel processes running. The ACPI [ACP] system of the laptop was used to get readings of voltage levels and current drawn from the battery. ACPI can be integrated into the Linux kernel and has a mapping to the /proc file system where current battery status can be accessed. Since ACPI takes measurements directly from the battery, the laptop was unplugged from the power supply to avoid its constant recharge. Periodically measurements of voltage level and current intensity from the battery were taken, as the proxy was processing the video stream. Then energy was computed as follows:
Z
T
v(t) · i(t) · dt
E(T ) = ∼
0 N X
v(n∆t) · i(n∆t) · ∆t,
(5.2)
n=1
where v(t), i(t) are instantaneous voltage and current drawn from battery, T is the total measurement time, N is the number of samples taken during T and ∆t = 2
T . N
The C function getrusage() was used to return the values of CPU usage
39
5.3.2
Q-scale Measurements
For the CPU measurements with different Q-scales, a 4-minute video clip file was used in avi format (the video stream was encoded in MPEG-2). For each allowed value of the Q-scale between 1 and 31, the average of two measurements was used. The results are shown in Figure 5.5. 40
CPU usage (seconds)
35
30
25
20 0
5
10
15 Q-Scale
20
25
30
Figure 5.5: CPU usage for different values of Qscale.
The figure shows that the total CPU usage has a linear decay for Q-scale
