See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/308869389

Mobileinsight: extracting and analyzing cellular network information on

smartphones

Conference Paper · October 2016

DOI: 10.1145/2973750.2973751

CITATIONS READS
88 1,610

6 authors, including:

Yuanjie Li Chunyi Peng

Tsinghua University The Ohio State University
48 PUBLICATIONS   747 CITATIONS    60 PUBLICATIONS   1,506 CITATIONS   

SEE PROFILE SEE PROFILE

Jiayao Li Tao Wang

Shen Zhen University Peking University
5 PUBLICATIONS   118 CITATIONS    33 PUBLICATIONS   437 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

MobileInsight View project

All content following this page was uploaded by Yuanjie Li on 25 October 2018.

The user has requested enhancement of the downloaded file.

 MobileInsight: Extracting and Analyzing Cellular Network
Information on Smartphones

Yuanjie Li1 Chunyi Peng2 Zengwen Yuan1 Jiayao Li1 Haotian Deng2 Tao Wang3
1 2 3
University of California, Los Angeles The Ohio State University Peking University
[email protected], [email protected],
[email protected],[email protected], [email protected], [email protected]

ABSTRACT both data and analytics to identify problems and renovate the de-
sign. This calls for a community tool suite that can be built and
We design and implement M OBILE I NSIGHT, a software tool that shared together. Such tool could stimulate research on the 3G/4G
collects, analyzes and exploits runtime network information from mobile networks. Ideally, the tool should possess three features
operational cellular networks. M OBILE I NSIGHT runs on commer- simultaneously: (1) It can collect runtime operation traces using
cial off-the-shelf phones without extra hardware or additional sup- commercial off-the-shelf (COTS) devices without extra hardware
port from operators. It exposes protocol messages on both con- support; (2) Given the data traces, it provides analytics to extract
trol plane and (below IP) data plane from the 3G/4G chipset. It dynamic protocol behaviors for both common usage settings and
provides in-device protocol analysis and operation logic inference. abnormal failure cases; (3) The tool offers simple APIs to build
It further offers a simple API, through which developers and re- applications and the framework can be readily extended. Unfor-
searchers obtain access to low-level network information for their tunately, no such community software tools are available to date.
mobile applications. We have built three showcases to illustrate The existing ones cannot meet all three requirements [2–7] (see
how M OBILE I NSIGHT is applied to cellular network research. Table 14 for a comparison summary). Furthermore, operators are
reluctant to release the traces collected from the infrastructure side.
They also have limited access to the device-side operations.
1. I NTRODUCTION In this paper, we take the first step to develop M OBILE I NSIGHT1 ,
a software toolwhich enables runtime cellular network monitoring
The cellular network is a “closed” yet critical infrastructure. On and analytics on COTS smartphones. It aims to satisfy three fea-
one hand, mobile users are increasingly accessing online services tures above; We seek to overcome the barrier by providing open
through their 3G/4G networks on their smart devices (e.g., smart- access (in software) to fine-grained cellular information on 3G/4G
phones and tablets). The resulting data volume has contributed to protocols; We empower in-device analytics, which not only dis-
88% of global mobile traffic now, and is projected to reach 97% by close what happens but also shed light on why and how. The tool
2019, with a tenfold traffic growth [1]. On the other hand, users is intended as an open platform that is extensible. The goal is to
and devices have very limited access to their runtime operations on facilitate researchers and developers to readily and quickly obtain
all cellular protocols. Mobile applications transfer data through the the low-level network information through easy-to-use APIs.
cellular interface via the socket API. Beyond that, the network itself In a nutshell, M OBILE I NSIGHT runs as a user-space service on
largely remains a blackbox to users. COTS smartphones (root access required for some phone models).
The lack of open access into fine-grained runtime network op- It does not require any extra support from operators, or additional
erations creates barriers for researchers and developers to accu- hardware (USRP, PC or testing equipments). M OBILE I NSIGHT
rately understand and refine how cellular protocols operate at the leverages a side channel inside the COTS smartphones, and ex-
device and inside the network. For example, the device experi- tracts cellular operations from signaling messages between the de-
ences a handoff on the go but has no clue on why it is triggered and vice and the network. These control-plane messages regulate es-
whether it is a good decision. In reality, the device has been ob- sential utility functions of radio access, mobility management, se-
served to hand over and get stuck in 2G even when 4G is available. curity, data/voice service quality, to name a few. Given these mes-
Another real-life instance is that it is not uncommon to take long sages, it further enables in-device analytics for cellular protocols.
time to upload a photo or experience a failed call via 4G. It is not We not only infer runtime protocol state machines and dynamics on
clear whether it is caused by poor radio quality or network protocol the device side, but also infer protocol operation logic (e.g., handoff
issues. The list goes on and long. policy from the carrier) from the network. M OBILE I NSIGHT offers
For a rather closed, large-scale cellular network system, we need a simple API for use and extension. With its simple API, we fur-
ther describe three example cases to show how M OBILE I NSIGHT
Permission to make digital or hard copies of all or part of this work for personal or can be used. These showcases demonstrate how M OBILE I NSIGHT
classroom use is granted without fee provided that copies are not made or distributed benefits end devices in a variety of scenarios, including failure diag-
for profit or commercial advantage and that copies bear this notice and the full cita- nosis, performance improvement, and security loophole detection.
tion on the first page. Copyrights for components of this work owned by others than
ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or re- We have implemented M OBILE I NSIGHT on Android phones
publish, to post on servers or to redistribute to lists, requires prior specific permission with Qualcomm chipsets (feasibility on iPhones and non-
and/or a fee. Request permissions from [email protected]. Qualcomm chipsets has been also validated). It currently sup-
MobiCom’16, October 03-07, 2016, New York City, NY, USA ports all 3G/4G control-plane protocols for radio resource control,

c 2016 ACM. ISBN 978-1-4503-4226-1/16/10. . . $15.00
1
DOI: http://dx.doi.org/10.1145/2973750.2973751 http://metro.cs.ucla.edu/mobile_insight/
 User-plane Control-plane Table 2: Solicited commands supported by RIL (Android) [22].
User-plane Mobile apps
Control-plane Category Description

Software
HTTP, FTP, Android APIs
User-space (SW)

OS kernel
VoIP, … Telephony service Network status get current radio state, signal strength, time changed
Kernel-space (SW) TCP/UDP, RIL APIs Network setting barring, forwarding, selection ...
Chipset (HW) …
Radio interface layer Call/SMS/Data call status&handling (e.g., dial, answer, mute), SMS, ...
IP AT commands
Cellular network Miscellaneous power, reset, vendor-defined support
NAS

Hardware
(MM, SM) Cellular interface
Cellular
RRC
core Cellular chipset
Internet
PDCP/RLC/MAC cellular protocol stack at the device, which has three parts. The first
PHY
Protocol view System view is to enable radio access between the device and the base station.
Figure 1: Network architecture (left), protocol stack (middle), and Physical (L1) and link (L2) functionalities, including PHY, MAC,
information access at device (right). RLC (Radio Link Control) and PDCP (Packet Data Convergence
Protocol), are implemented. The second part is the control-plane
Table 1: Cellular network protocols and used acronyms. protocols, which are split into access stratum (AS) and non-access
stratum (NAS). The AS protocols regulate radio access through Ra-
Name Description Category System Standard dio Resource Control (RRC). RRC is mainly for radio resource al-
CM Connectivity Management Data/voice 3G CS TS24.008 [9] location and radio connection management; it also helps to transfer
SM Session Management control in 3G PS TS24.008 [9] signaling messages over the air. NAS is responsible for conveying
ESM 4G EPS Session Management NAS 4G TS24.301 [10]
non-radio signaling messages between the device and the core net-
MM Mobility Management Mobility 3G CS TS24.008 [9]
GMM GPRS Mobility Management mgmt. in 3G PS TS24.008 [9] work. Two protocols of mobility management (MM) and session
EMM EPS Mobility Management NAS 4G TS24.301 [10] management (SM) also belong to the control plane. MM offers
3G-RRC Radio Resource Control RRC in 3G TS25.331 [11]
4G-RRC Radio Resource Control AS 4G TS36.331 [12]
location updates and mobility support for call/data sessions, while
PHY Physical Layer Layer 1 4G TS36.211 [13]
SM is to create and mandate voice calls and data sessions. The last
TS36.212 [14] piece is the data-plane protocols above IP, which are not cellular
TS36.213 [15] specific but use the standard TCP/IP suite.
MAC Medium Access Control 4Ga TS36.321 [16]
RLC Radio Link Control Layer 2 4Ga TS36.322 [17] Table 1 lists the protocols studied in this work. Multiple vari-
PDCP Packet Data Convergence Protocol 4Ga TS36.323 [18] ants exist for a common function (like RRC and NAS) in 3G and
4G. 3G also has variants for its circuit-switched (CS) and packet-
mobility management and session management, as well as certain switched (PS) domains for voice and data, respectively. L1/L2 pro-
4G below-IP protocols that convey control information. We have tocols and control-plane protocols are generally cellular specific.
tested M OBILE I NSIGHT with 8 carriers: four US carriers (Verizon, Limited in-device access through APIs. In commodity phones,
AT&T, T-Mobile, Sprint) plus Project Fi [8], and three Chinese op- the OS and mobile apps have limited access to low-level, cellular-
erators, using 30 phones from 11 phone models. Our evaluation specific information at runtime. As shown in Figure 1 (right),
shows that, M OBILE I NSIGHT works well on both high-end and cellular-specific protocols (say, control-plane and L1/L2 protocols)
low-end phones using different cellular chipsets and OSes. It logs are implemented within the chipset (e.g., Qualcomm Snapdragon
cellular events and executes analysis with acceptable overhead. It and Samsung Exynos). As a result, cellular-specific information
can accurately infer protocol state-machines and operation logics is mostly inaccessible to the software (for both kernel-space and
and process 99% of cellular signaling messages in less than 0.8 ms user-space) in usual scenarios. The OS gets access to basic cellu-
in most cases. The tool itself consumes 1–7% CPU usage, 30MB lar functions and states (e.g., registration, dialing a voice call and
memory and 3–4% extra energy at maximum. The code and appli- enabling/disabling data) through the de facto radio interface layer
cation, as well as the traces we collect through M OBILE I NSIGHT, (RIL) library which interacts with the cellular interface exposed
are available to the research community1 . by the chipset. The RIL implementation is vendor-specific, and
This work has three main contributions. relies on the standardized AT commands [19]. For ease of app de-
1. We present M OBILE I NSIGHT, an in-device software tool to velopment and permission control, the OS further encapsulates a
monitor, analyze and exploit runtime cellular protocol infor- subset of RIL library to APIs, e.g., TelephonyManager class
mation on COTS smartphones; for Android [6, 7]. Some system services on specific phone mod-
2. We devise side-channel techniques to collect signaling mes- els (e.g., FieldTestMode in Nexus 5 [20] and iPhone [21]) may di-
sages for 3G/4G protocols, and design inference techniques rectly access some, but not all cellular information from the RIL
to analyze protocol state dynamics and operation logic; interface. Table 2 offers a sample of RIL commands [22], which
3. We conduct extensive tests to assess its effectiveness, and exposes coarse-grained information (call/data/cell level) only.
build three showcase examples to demonstrate its potential Debugging tools, such as QXDM [2], XCAL [3], MTK
of wide applicability. Catcher [4], xgoldmon [23], can collect cellular network messages
and offer fine-grained information. However, they all work with
PCs, and do not offer in-device collection or protocol analytics (see
2. C ELLULAR N ETWORK P RIMER §9 for more discussions).

Figure 1 (left) illustrates a simplified cellular network architec-

ture. The mobile device (i.e., smartphone) connects to the Internet
or telephony network through the base stations and the cellular core
3. M OBILE I NSIGHT OVERVIEW
network. Both control-plane and data-plane (i.e., user plane) oper- M OBILE I NSIGHT offers a pure software-based solution for in-
ations are needed to receive data/voice services. The data plane device collection and analytics of cellular protocol information.
delivers user content (data/voice), whereas the control plane ex- It runs as a user-space service. It infers protocol operations and
changes signaling messages to facilitate content delivery. key configurations by exploiting messages exchanged between the
Cellular network protocol stack. Figure 1 (middle) shows the device and the network at the hardware chipset. It supports fine-
 MobileInsight Table 3: Summary of virtual devices for external diagnostic mode.

Analyzers App#1 Mobile OS Chipset Virtual device Driver code

Monitor
Chipset

APIs App#2 Android Qualcomm /dev/diag [25]

Parser Analyzer ... Android MediaTek /dev/ccci_md_log_ctrl [26]
App#n Android Intel XMM /dev/mdmTrace [23]
OS User space
iOS Apple A6 /dev/tty.debug [27]
Figure 2: M OBILE I NSIGHT architecture.

cluding Qualcomm, MediaTek and Intel series) and mobile OSes

grained, per-message information retrieval and analysis from a set (including Android and iOS). However, no public documents are
of cellular-specific protocols on the control plane and at lower lay- available for this mode. We have to learn its details from the open-
ers. It not only unveils what is going on with cellular-specific op- source code of diagnostic drivers (summarized in Table 3).
erations, but also sheds light on why and how. Specifically, M O - Figure 3a illustrates the USB-based diagnostic mode on Android
BILE I NSIGHT seeks to achieve three concrete goals. for Qualcomm chipsets. The cellular interface maps itself to a vir-
• In-device deployability. It should be readily deployable in tual device (e.g., /dev/diag) in the OS. Different from RIL, this
COTS phones without extra hardware or changes on the existing virtual device exposes all raw cellular messages as binary streams.
infrastructure or the device OS. When the USB is connected to the external collector (e.g., a PC),
• Protocol analytics. In addition to archiving protocol messages, the OS uses USB tethering [24] to bind the virtual device with
M OBILE I NSIGHT should supplement analytics for standardized a USB port (e.g., /dev/ttyUSB). The external collector thus
cellular protocols, including their state dynamics and operation fetches the cellular messages from the hardware interface. This is
logics. Ideally, the analysis is done at runtime, so that it can be how the debuggers (Qualcomm QXDM [2], MediaTek Catcher [4],
used for various usages such as performance improvement and Intel xgoldmon [23], XCAL [3]) collect logs from USB. Similar
failure diagnosis. virtual devices also exist on other chipsets and mobile OSes (sum-
• Fine granularity and wide coverage. It should provide fine- marized in Table 3), with slightly different implementations2 .
grained information to runtime protocol operations. Moreover, M OBILE I NSIGHT emulates an external logger at the mobile de-
it should support protocols across layers and on both control and vice to collect raw cellular logs. We issue commands directly to
data planes. the virtual device (e.g., via ioctl or AT command AT+TRACE,
Figure 2 illustrates the architecture of M OBILE I NSIGHT, which depending on the chipset and mobile OS types). These commands
has two main components. include activation/deactivation of cellular message types, and call-
(i) Monitor (§4). It first exposes raw cellular logs from the cel- back registrations to receive hex logs. We then pull the hex log
lular interface to the device user-space at runtime, and then parses streams from the virtual device, and pass them to the in-device mes-
them into protocol messages and extracts their carried information sage parser. This ensures that, for each cellular message accessible
elements. It builds an extensible modular framework, where each to external debuggers, it is also available from M OBILE I NSIGHT.
parser works on a per-protocol basis. The parsed messages are then
fed to the analyzer. 4.2 Parsing Cellular Network Messages
(ii) Analyzer (§5). Given the extracted messages, the analyzer
Given the raw cellular logs, we next parse each message. The is-
aims to unveil protocol dynamics and operation logics. Based on
sue is to decode a variety of message types (see Table 4) in their
the observed messages and the anticipated behavior model (from
rich formats. Figure 3 exemplifies the structure of the 4G RRC
cellular domain knowledge), the analyzer infers protocol states,
message from the side channel. It carries a metadata header and
triggering conditions for state transitions, and protocol’s taken ac-
the payload, plus configurable and message-specific information
tions. Moreover, it infers certain protocol operation logics (say,
elements. The metadata headers’ formats are specific to cellular
handoff) that uses the operator-defined policies and configurations.
chipsets. We infer them based on the raw binary logs from the diag-
It offers built-in abstraction per protocol and allows for mobile OS-
nostic virtual device, and the publicly available open-source driver
/app developers to customize their analyzers.
code [23, 25–27]. The message-specific information elements are
standardized in the 3GPP standards [9–12, 16, 17, 17, 18, 28].
M OBILE I NSIGHT parses such rich messages in two steps, as
4. I N -D EVICE RUNTIME M ONITOR shown in Figure 3a. During the first step, a metadata parser is
To enable in-device runtime monitoring, we need to address applied to the raw hex logs to extract the message type ID and
three issues: (1) How to expose raw cellular information from the release version. It then selects the corresponding message parser
hardware to the software (§4.1)? (2) How to decode the informa- with a switch branch over the (type-ID, release) tuple. To develop
tion into valid messages, given rich types and inter-dependency of message parser for each signaling message, we extract the message
protocol messages (§4.2)? (3) How to meet the requirement for low formats from the standards of each protocol. Some formats can be
latency and reduce the system overhead (§4.3)? We next elaborate automatically extracted. For instance, the 3G/4G RRC standards
on each. provide abstract message notations under ASN.1 [29], which can
2
It is possible that some phone models do not have the virtual
4.1 Exposing Raw Logs from Side Channel device. For example, we find several LG Nexus 5 and Motorola
The first issue is that ordinary in-device schemes cannot expose Nexus 6 models delete it on startup. In this case, neither external
message-level cellular information to the user space (see §2). We debuggers (e.g., QXDM) nor M OBILE I NSIGHT can extract runtime
thus leverage an alternative side channel between the chipset and cellular function. M OBILE I NSIGHT can detect the inaccessibility
of the side-channel, and stop any tasks if it is inaccessible. In re-
the software. We find that the chipset supports an external diag- ality, we observe that for each phone model, the sidechannel ac-
nostic mode, which exposes the cellular interface to the USB port. cessibility is highly stable: it either always exists (for most phone
In fact, this diagnostic mode exists for major cellular chipsets (in- models), or is removed by some phone vendors permanently.
 Protocol analysis
Metadata header Cellular message payload (parsed)
3. Cellular message 0 8 16 24 31
Message Parser PDCP Reserved Msg len
ESM <packet>
RLC General Msg len (dup) Msg type <field name=“4G-RRC-ConnectionReconfiguration">
EMM
Protocol MAC Timestamp (from hardware) <field name="measConfig">
RRC
config PHY <field name="measObjectToAddModList">
Pkt RRC Radio <field name="Freq" value="4360”/>
2. Metadata + Payload Msg Type Reserved Info
ver. release bearer <field name=“measID” value=“1”/>
Metadata specific element
Parser
Serving cell identifier …
</field>
1. Raw hex logs
Message payload <field name="reportConfigToRemoveList" >
Info
MobileInsight Proxy 0. On-demand …
log config
element
Monitor Raw hex log </field>
Android External
…
/dev/diag /dev/ttyUSB 1000 9300 9300 c0b0 0000 8c8a </field>
OS kernel logger
f211 ce00 070a 7101 8200 9416 </packet>
7206 0600 0000 0076 0022 …
Cellular Interface
(a) Monitor information flow (b) An example of cellular message format (4G RRC)
Figure 3: M OBILE I NSIGHT’s in-device runtime monitor.

Table 4: Cellular messages in current M OBILE I NSIGHT monitor. clare its needed cellular messages (§5), and dynamically configures
the cellular interface to record only those messages of interests. In
Protocol Message Types # Msg # Element
4G-PHY PDSCH signal; Cell Measurement 2a N/Ab
§7.3, we will show that it can help reduce the storage overhead
4G-MAC Uplink/downlink transport blocks; MAC con- 5a 54 by up to two orders of magnitude. Second, it invokes on-demand
fig; Buffer status report parsing to only decode those necessary fields. For example, the an-
4G-RLC Control/data packet data unit 2a N/Ab
alyzer may only want to learn the connectivity state in RRC. It thus
4G-PDCP Control packet data unit 1a N/Ab
4G-RRC System info blocks; Connection 45 185 parses the metadata only, and then passes the message to the ana-
setup/release/re-establish/reconfig; Han- lyzer with an annotation of the message parsers needed. Then the
dover command; Measurement control/report;
Radio capability equerry; Paging; Security
analyzer can parse it on demand by calling the decode(), which
model command reads the annotation and calls the correct message parser. Last, we
3G-RRC Same as 4G-RRC 32 108 parallelize log collection and parsing. The trace collection proxy
3G- Attach/detach; Authentication request/re- 41 63
MM/GMM sponse; Location update; Security mode
and the parser are two separate daemons, and the proxy passes the
control; Identification request/response; raw logs via an in-memory queue. This prevents that the analysis
Service request; Paging is blocked by log collection.
4G-EMM Same as 3G-MM/GMM 32 108
3G-CM/SM Session (EPS bearer/PDP context) setup/modi- 58 54
Table 4 summarizes the supported messages by the time of sub-
fy/release; PDN connect/release/modify mission. For raw log collection, it supports the same types of mes-
4G-ESM Same as 3G-CM/SM 22 71 sages as the state-of-art external debuggers. For message parsing,
CDMA/EvDo Paging information; connectivity establishmen- 5a N/Ab
t/release; radio link protocol status
it currently supports 240 message types, encapsulated in 68 type-
a
Not all the message types supported. specific metadata headers and 3GPP releases 7-12. It decodes all
b
No information elements are defined. signaling messages on radio resource control, mobility manage-
ment and session management for 3G and 4G. It partially supports
4G PHY, MAC, RLC, and PDCP messages, mainly those convey-
be readily compiled into message decoders. For other messages, ing control information. It also supports CDMA/EvDO messages
we manually convert them to machine-readable formats. partially, including the paging and radio link protocols. We have
realized full support for Qualcomm Snapdragon processors, and
Handling protocol dependency. Certain messages are inter-
validated the feasibility on MediaTek/Intel chipsets and iOS.
dependent even at the parsing level. L1/L2 protocols (PDCP/RL-
C/MAC/PHY) may need control parameters from RRC for correct
parsing. For example, the PDCP packet headers might be com-
pressed with RoHC [30], whose parameters are carried in the RRC
Reconfiguration message. Without these RoHC parameters, 5. C ELLULAR A NALYTICS
these packets cannot be decompressed or decoded. We thus im-
plement a protocol configuration repository. Upon receiving RRC With the cellular messages, M OBILE I NSIGHT further builds run-
reconfiguration, M OBILE I NSIGHT extracts related informa- time analytics for protocol behaviors. Table 5 summarizes the pro-
tion elements for PDCP/RLC/MAC/PHY, such as the compression tocol analytics we have developed. For each protocol, we uncover
parameters (for PDCP), acknowledgement mode configuration (for two dimensions of its behaviors:
RLC), DRX timers (for MAC), modulation support (for PHY), etc. • Protocol state dynamics (§5.1): They include the protocol
They are used to parse upcoming messages accordingly. states, and the state transition events. They are controlled by the
standardized protocol state machines and runtime observation of
4.3 Optimization protocol messages and configurations.
We apply several optimizations to reduce message collection/pro- • Protocol operation logic (§5.2): It decides what parameters
cessing latency and system overhead. First, M OBILE I NSIGHT uses to use and which messages to send/receive. For network-centric
on-demand collection to only archive those logs required by the 3G/4G design, it is the algorithm or policy used by the network
device-specified analyzers. It asks each protocol analyzer to de- operator to determine the parameters/messages used by protocols.
 Table 5: Built-in protocol analyzers.
RRC_IDLE RRC_IDLE
RRC Connection Setup Request
Analyzers Description Conn Conn RRC Connection Setup Accept
LteRrcAnalyzer 4G RRC protocol analyzer that uncovers connection Setup Release CRX
state, configuration dynamics and base station’s hand- RRC_CONN RRC Connection Reconfiguration
off decision logic. CRX
CRX d Parameters: T1=100ms,
Timer start: T1
LteNasAnalyzer 4G EMM/ESM protocol analyzer that uncovers the mo- TshortDRX=20ms
bility management state dynamics T1 Data Timeout T2=2 TshortDRX
LtePhyAnalyzer 4G physical layer analyzer that reveals the runtime ra- Short-DRX Short-DRX
Data
dio resource allocation and link capacity Timer start: T2
T2
WcdmaRrcAnalyzer 3G RRC protocol analyzer that uncovers connection Stop timer
Long-DRX Downlink data
state, configuration dynamics and base station’s hand- CRX
off decision logic. ……
UmtsNasAnalyzer 3G GMM/SM protocol analyzer that uncovers the mo-
Reference State Runtime
bility management state dynamics state machine dynamics message-driven tracking
Figure 4: Example for 4G-RRC protocol state dynamics with
5.1 Extraction of Protocol State Dynamics reference state machine and runtime signals.
The cellular protocol states at the device are regulated by the state
machine in 3G/4G networks. The runtime protocol state dynamics Table 6: Size of device-side 3G/4G protocol state machines.
provide direct hints about performance (e.g. high/low-rate connec-
tivity state in RRC) and functional correctness (e.g., failure states Protocol #State #State transition Standard
in mobility management or session management). For each signal- CM 19 44 [9]
ing protocol (3G/4G RRC, MM and SM), M OBILE I NSIGHT seeks Session management SM 7 21 [9]
ESM 4 12 [10]
to capture its runtime state dynamics, including the current state, MM 30 50 [9]
the state transitions and the conditions for transitions. Mobility management GMM 18 22 [9]
We take a two-phase approach (see Figure 4 for an example). We EMM 21 25 [10]
first derive a reference state-machine model for each protocol based 3G-RRC 5 13 [11]
Radio resource control
4G-RRC 4 6 [12]
on the 3GPP standards [9–12]. This model abstracts the device-side
states and transition conditions as a function of cellular messages.
We then feed runtime cellular messages from our in-device monitor sages to be monitored. Each observed message is passed to all those
(§4) to this model. This provides the exact protocol states and state- state-transition functions originated from the current protocol state.
related configurations. From those cellular messages, we derive the If any transition function is satisfied, M OBILE I NSIGHT updates the
transition parameters and track the state transitions by following current state. Figure 4 shows how this works for the 4G-RRC
the reference state machine. Since both the standardized state ma- connectivity dynamics. Between idle and connected states, re-
chines and runtime messages are known in M OBILE I NSIGHT, the ceiving the RRC Connection Setup/Release message immediately
ground truth on the runtime protocol states can be obtained. triggers the transition. The transitions between substates within
Reference state machine. We focus on the protocol state ma- RRC_CONN rely on timer configurations. In this case, the transi-
chine at the device. For each protocol (RRC/MM/SM), the stan- tion functions between substates extract timers from the runtime
dard specifies the protocol states and substates, and the transition RRC Connection Reconfiguration message, and use internal timers
conditions. In RRC, the state represents the radio connectivity be- to track the potential transitions. In the example, CRX switches to
tween the device and the base station. For MM, the state denotes Short-DRX upon T1 timeout, and moves back to CRX but not
the device’s registration status to the core network. For SM, the Long-DRX since timer T2 stops. T2 is configured one or multiple
state represents the data session activity and QoS configurations. short DRX cycle (here, 2 × 20 ms = 40ms).
Figure 4 exemplifies the 4G-RRC state machine defined in [12]. Other protocols. We also apply similar techniques to track the
We extract both the main states (say, RRC_IDLE and RRC_CONN) states in 3G/4G MM and SM protocols (Table 6).
and the substates at each state (e.g., Continuous-RX and • Mobility management: These protocols control the device’s
Short/Long-DRX in RRC_CONN). Each state transition is mod- registration status to the core network, and manage the tracking/lo-
eled as a boolean function of cellular messages: true if the tran- cation/routing area for the device. We track the device’s registration
sition condition is met upon receiving this cellular message. The status based on messages of attach/detach and location/routing/-
transition can be directly triggered upon receiving certain mes- tracking area update. In each (de)registration status, the device’s
sages, and/or controlled by parameters inside the message (say, configurations (e.g., security mode, voice usage preference, net-
timers). It can also be activated upon receiving multiple messages work features) are also recorded. Such information can be used for
(e.g., five rejection messages from MM lead to the “out-of-service” failure diagnosis and security loophole detection (see §8).
state [10]). Note that such a reference model itself does not pro- • Session management: These protocols, including 4G ESM,
vide runtime state dynamics or concrete parameter settings for the 3G CM/SM, control the device’s data/voice session activities. Each
state transition. Instead, it serves as a template to track cellular data session has its own QoS profile (e.g., traffic/delay class, maxi-
messages and states at runtime. Table 6 summarizes the sizes of mum bitrate) and data billing policy. In M OBILE I NSIGHT, we track
the device-side state machines for each protocol, which are inde- the data session activity based on the session setup/modify/release
pendent of network carriers and phone models. It can be seen that messages. We extract the QoS profile and the billing policy (in the
all protocols’ state machines are of modest sizes, thus able to be form of traffic flow template) from these messages, and use them as
tracked efficiently at end device. hints for data performance and network failure diagnosis (see §8).
Runtime message-driven state tracking. Given the reference Correctness. M OBILE I NSIGHT provides protocol state dynam-
model, M OBILE I NSIGHT next tracks state transitions based on in- ics identical to those constructed by using messages from external
coming cellular messages from the in-device monitor (§4). It first debuggers (e.g. QXDM and MTK Catcher). This is for two fac-
reads the reference state machine, and determines the cellular mes- tors: (1) The protocol state machines are standardized, while the
standards dictate the protocols to follow the runtime parameters; BS1 (4G) BS 1’s internal handoff decision logic:
• Switch to BS 2 (4G) if RSS2(4G) > RSS1(4G) + 3 dBm
(2) M OBILE I NSIGHT has access to the same cellular information • Otherwise, switch to BS 3 (3G) if RSS1(4G) < 110 dBm
BS2 (4G) BS3 (3G)
as those tools. In the RRC protocol context, M OBILE I NSIGHT di- and RSS3(3G) > 90 dBm

rectly extracts and predicts RRC states with explicit information. It BS1 BS1
is thus better than the implicit learning scheme (e.g., through power meas control: monitor 4G meas control: monitor 4G

measurement [31–33]). Similarly, M OBILE I NSIGHT directly ana- meas report: RSS2 > RSS1 + 3 Sample 1 meas report: RSS1 < 110 Sample 2
Sample
lyzes 4G EMM and ESM protocols, and their 3G variants as well. Collection handoff command: to BS2 meas control: monitor 3G & 4G
Note that, however, the ultimate correctness of our protocol state RSS <
meas report: RSS13 >
110,
90 Sample 3
tracking at the device depends on two premises: (1) the device handoff command: to BS3
chipset implementation follows the 3GPP standards; (2) the cel-
lular information from the diagnostic mode is accurate. We do not monitor 4G monitor 4G
RSS1 < 110
monitor 3G & 4G
Partial
have any evidence to show that neither premise is invalid now. Recovery
RSS2 > RSS1 + 3 RSS1 < 110, RSS3 > 90
handoff to 4G handoff to 3G
Limitations. While M OBILE I NSIGHT can accurately re-
construct the device-side protocol state dynamics, it does not have RSSs(4G) < 110
monitor 4G monitor 3G & 4G
direct access to the network-side protocol state counterparts (which
Aggregation RSSn(4G) > RSSs(4G) + 3 RSSs(4G) < 110,
can be different from client-side protocol state dynamics). Indeed, RSSn(3G) > 90
handoff to 4G handoff to 3G
the network-side protocol state dynamics could be inferred based
on the device-side protocol’s state, which has been regulated by the Figure 5: An example of 4G cell handoff decision logic (top), and
3GPP standards. We leave this inference to the future work. how it is inferred by device at runtime (bottom).
5.2 Inference of Protocol Operation Logic
M OBILE I NSIGHT can also infer certain protocol operation logic
and measurement report criteria are of limited options. Although
from the network. The logic is the algorithm or policy by the oper-
the device has no direct access to network-side operations, it may
ator to determine what configurations the protocol should use and
infer them by pairing control commands and feedbacks.
what messages to send/receive. By analyzing operation logic, the
Consequently, we model network operations as a finite-state ma-
device can forecast possible performance degradation (e.g., hand-
chine and devise an online inference algorithm. Our approach
off to a low-speed cell) and functional incorrectness (e.g., network
adapts QSM, a state merging algorithm [41, 42] in AI with lever-
failures). We next present our initial effort on inferring the network-
aging domain-specific knowledge on cellular networks to improve
side protocol logic using the case study on handoff.
inference accuracy.
Handoff switches the device’s serving cell from one to another. It
is critical to end devices, since the target cell to be chosen may have Modeling handoff decision logic. We model the handoff logic
varying performance. In 3G/4G, when the device is at RRC_CONN as a domain-specific finite-state machine. Our model takes into ac-
state, the handoff decision is made by the base station and assisted count the standardized mechanisms, including measurement con-
by the device. Figure 5 (top) depicts a typical handoff procedure trol, measurement report and handoff procedure. Each state denotes
and its signaling between the device and the network. The phone the device’s control state configured by the network (e.g., Meas
is initially served by BS1. The serving cell (BS1) asks the phone Control and Handoff Command). Two states are equivalent
to measure and report the radio quality of neighboring cells. Upon if their control parameters are identical. For Meas Control,
receiving the measurement report from the phone, BS1 runs its de- this means identical measurement report criteria (e.g., A3 defined
cision logic to determine whether handoff should be triggered. It in [11, 12]). For Handoff Command, we assume that they are
may reconfigure the device for further measurements (right), or is- equivalent if the target cells are identical. The state equivalence is
sue the device handoff command (left). essential for the state merging process. The state transition happens
We need to address two challenges when inferring network-side when a new control command (Meas Control or Handoff
handoff logic. First, the connected-state handoff decision logic can Command) is received by the device. It is invoked upon receiv-
be operator specific. The 3GPP standards leave the freedom for ing the device’s Meas Report message in response to the cur-
operators to customize their decision logic. Second, the device does rent control state. Following QSM, the state transition is modeled
not have full access to all network-side operations. It has to rely on as a prefix of Meas Report sequence. Any sequence matching
its observations and interactions with the network to learn the logic. this prefix would trigger the state transition. This model is valid
Fortunately, the operation logic is not arbitrary in reality. It typ- for handoff, because the base station may make handoff decisions
ically follows well-justified common practices [34–40]. Opera- before receiving all reports from the device.
tors tend to apply the stable logic to each cell. It remains stable, Online inference. We use an online algorithm to infer the hand-
and thus predictable in operational 3G/4G networks. Moreover, off decision logic. For each serving cell, it collects runtime hand-
we observe that many network-side protocol operations be inter- off events and associated measurement controls/reports as samples,
active and stateful. The logic is customizable, but regulated by and iteratively updates its inferred state machine by aggregating
standardized mechanisms at the protocol level. The network often a new state with the existing one. Each iteration has three steps:
relies on device feedback to operate its protocols (e.g., measure- sample collection, partial recovery, and aggregation.
ment report for handoff). Consider the example of Figure 5. To (a) Sample collection. We collect the training samples at runtime
make a proper handoff decision, the serving cell needs to know the without active probing of the cellular network. We define a sam-
device-perceived signal strength of nearby candidate cells. It thus ple sequence as the tuple of an old control command (e.g., Meas
configures the device to perform measurements and report the sig- control), a new control command (e.g., Meas control or
nal strength (via the Meas Control command). This interaction Handoff command) and the Meas Report sequence in be-
may take multiple rounds, because the base station may request the tween. To collect a sample sequence, we track all corresponding
device to measure more candidates based on prior measurements. messages in the background (via in-device monitor) until the next
According to 3GPP standards [11, 12], both the handoff commands control command arrives. In the example, three samples are col-
Algorithm 1 G = Aggregation(G, Ξ) logic from each frequency. The above aggregation algorithm still
Input: G =FSM of handoff logic, Ξ = {e} with all transitions in (b); applies. We merge those samples from the serving cells over the
for e(vs −
r
→ vd ) ∈ Ξ do same frequency. Though this may lead to conflicting decision log-
if vs ∈ G AND vd ∈ G then ics between cells of the same type in theory, it is unlikely to happen
r0 in operational 3G/4G network (§7.2). To handle it, we duplicate
Find e0 ∈ G satisfying vs −→ vd and update r0 = r0 ∪ r;
else if vs ∈
/ G AND vd ∈ / G then the state transitions and create two branches and mark it as an ex-
Ge = {e}, G = G ∪ Ge ; //e is the only edge in an isolated Ge ception for further checking.
else // vs or vd ∈ G, assume vs ∈ G for simplicity Correctness and limitations. The correctness of the inferred
G = G ∪ e by adding vd and the edge e into G handoff logic is generally ensured by the good properties of QSM.
end if
end for [41–44] prove that, the state machine can be fully recovered if suffi-
Return G cient samples can reach all states and differentiate any pair of non-
equivalent states in the logic. This requires the device to receive all
possible types of Meas Control and Handoff Command from suffi-
cient samples. If the device has not collected enough samples that
lected in two cases where the device hands over from 4G BS1 to meet above conditions, the state machine may be incomplete.
4G BS2 (left) and 3G BS3 (right). A limitation of our approach is that, the inference may not cap-
(b) Partial recovery. From each sample sequence, we gen- ture the internal states on the network-side handoff logic that do
erate a state transition by converting the old/new control com- not interact with the device. For instance, even when the radio-
mand into from/to the control state, with the feedback se- related handoff criterion is met, the network may not invoke the
quence being the transition condition (the sequence itself is handoff to the target cell for load balancing; such operations may
also a prefix). Use sample sequence 1 as an example: Meas remain invisible to the device. The inferred one would then be
MeasReport1,...
Control−−−−−−−−−→Handoff Command. We thus de- the device-perceived handoff logic only. The direct access to these
rive a transition between the state “monitor other 4G neighbor network-side internal states would be possible only if the cellular
cells”→“handoff to another 4G cell” (here, BS2) when the mea- infrastructure is open, which however is unlikely to occur in reality.
surement report indicates RSS2 > RSS1 + 3 (event A3 in [12]). Our study shows that our inference typically captures network-side
Similarly, we derive the transition of extending the measurement logic in practice (§7.2).
from 4G to 4G and 3G, and the transition to a 4G→ 3G handoff. Operation logic for other protocols. Besides handoff, other
(c) Aggregation. When a new partial transition is created, the cellular protocols may also use their own logic. For example, oper-
aggregation step merges it to the existing state machine. It works ators may customize their QoS allocation policies in SM. PHY may
in three steps. First, it performs symbolic mapping to generalize customize its radio block allocation and rate adaptation algorithms.
the rule. This is feasible because the 3GPP standards define the We are exploring to adapt our online inference to these contexts.
measurement control/report parameters in an abstract form [12].
For example, we translate RSS2 > RSS1 + 3 into a general rule
RSSn(4G) > RSSs(4G) + 3 by mapping cells 1 and 2 into their 6. I MPLEMENTATION
roles in 4G: the serving cell and the neighboring candidate. Second,
it locates where to merge. For each edge from the partial transition M OBILE I NSIGHT seeks to provide an open platform to facili-
sample, we search if it exists in the current state machine. We use tate researchers and developers to learn the protocol operations in
a directed acyclic graph G to represent the state machine. Finally, cellular networks. It thus defines simple APIs for its monitor and
we merge the new rule into the existing graph by running the union analyzer components. We implement M OBILE I NSIGHT on off-
operation over the graph. the-shelf smartphones, as a user-space service. We choose the
Algorithm 1 shows the pseudo-code for aggregation. There are user-space rather than in-kernel solution for ease of deployabil-
three cases: both source and destination states (nodes) exist in the ity. It consists of 29,698 lines of code (12,254 lines of C/C++ and
graph, only one node exists, and no nodes exist. If no nodes are not 17,444 lines of Python), excluding the 3rd-party libraries. Our cur-
found, it is treated as a new edge and added to the existing state ma- rent implementation is mainly on Android phones with Qualcomm
chine as an isolated graph. When only one node exists, we create a chipsets, but porting to other platforms is ongoing.
new edge from the existing graph (by adding the non-existing node) M OBILE I NSIGHT API. We first illustrate how to use the API
and initialize its transition condition as the measurement sequence via an example (more detailed usage can be found in [45]), which
from the sample. When both nodes exist, the transition condition seeks to analyze the protocol state dynamics of 3G and 4G RRC.
(prefixes) should be merged. We search for the longest common
prefix in the existing transition and merge it with this new prefix. # Initialize a in-device monitor
src = Monitor()
In theory, the old and new conditions for the same transition might #Declare 3G/4G RRC analyzers
differ or even conflict with each other (e.g., RSS > −110 and lte_rrc_analyzer = LteRrcAnalyzer() #4G RRC
RSS < −110). However, it would not occur in practice because wdcma_rrc_analyzer = WcdmaRrcAnalyzer() #3G RRC
the rules used by the same serving cell are consistent. #Bind the analyzers to the monitor
Ideally, the above algorithm should be performed over every lte_rrc_analyzer.set_source(src)
serving cell. In practice, however, per-cell inference suffers from wcdma_rrc_analyzer.set_source(src)
#Start processing
insufficient training samples; otherwise, the user has to wander src.run()
around to collect unique samples within one cell coverage. More-
over, it requires more storage for per-cell logic. To tackle this Both monitor and analyzer functions in M OBILE I NSIGHT are
issue, we observe that operators tend to apply the same logic to encapsulated into classes, for instance, Monitor class and
each cell type (e.g., under the same frequency), with minor tun- LteRrcAnalyzer class. M OBILE I NSIGHT abstracts the in-
ing on parameters (e.g., thresholds). It is thus feasible to aggre- ference per protocol into a module called analyzer. To call a
gate samples from cells of the same type, and infer the decision chosen function, an atop app/service has to initiate an instance
of its corresponding class. For example, src = Monitor() Table 7: M OBILE I NSIGHT can run over various phones.
creates a Monitor instance. Second, the target app/service
Model CPU RAM Chipset OS
declares the needed analyzers, and binds them to the monitor
Huawei Nexus 6P Quad-core 2GHz 3GB Snapdragon Android
via set_source(src) method. This lets an analyzer regis- + Quad-core 1.55GHz 810 6.0.1
ter a callback function upon certain cellular events from moni- ZTE Nubia Z9 Quad-core 1.5 GHz 4GB 810 5.0.2
Motorola Nexus 6 Quad-core 2.7GHz 3GB 805 5.1.1
tor. Finally, we start M OBILE I NSIGHT by running the monitor via Samsung S5 Quad-core 2.5GHz 2GB 801 4.4.2
src.run(), which logs the events and drives the analysis. Sony Xperia Z3 Quad-core 2.5 GHz 3GB 801 4.4.4
Xiaomi Mi 4 Quad-core 2.5 GHz 3GB 801 4.4.3
In-device monitor (§4). We implement the monitor using two LG G3 Quad-core 2.5 GHz 2GB 801 4.4.2
daemons: a proxy daemon to extract raw hex logs from the cellu- Samsung Note 3 Quad-core 2.3 GHz 3GB 800 4.3
lar interface (chipset), and a parser daemon to decode messages. LG Tribute Quad-core 1.2 GHz 1GB 400 4.4.2
Meizu MX4∗ Quad-core 2.2 GHz 2GB MediaTek MT6595 4.4.4
This allows for pipeline parallelism, thus reducing processing la- LG G4 Stylus∗ Octa-core 1.4 GHz 2GB MediaTek MT6592 5.1
tency. The proxy daemon retrieves raw logs by leveraging An- Asus Zenfone 2E∗ Dual-core 1.6 GHz 1GB Intel XMM7160 5.0
droid’s open-source driver for the cellular virtual interface [25]. Apple iPhone 5∗ Dual-core 1.3 GHz 1GB Apple A6 iOS 7
Specifically, we first open the virtual device /dev/diag, and en-
able the logging mode by sending a command (defined in [25]) 7.1 In-device Support and Wide Coverage
via ioctl function. We then register a callback function linked
to the virtual device to be notified whenever raw binaries are gen- In-device support. We first validate that M OBILE I NSIGHT is
erated. The parser daemon implements the decoding of cellular readily deployable over various phone models, mobile OSes, and
messages in Table 4. We also implement optimization techniques cellular chipsets. We have installed and tested it over 30 phones. It
in §4.3, including on-demand collection, on-demand decoding and works over all phones. Table 7 summarizes the phone models, cov-
in-memory processing. To further speed up processing, both dae- ering a variety of Qualcomm chipsets and Android OS versions.
mons are implemented in C/C++ and compiled with Android NDK. We have also validated the feasibility of porting M OBILE I NSIGHT
Built-in Analyzers (§5). We implement each built-in analyzer to Intel/Madietek chipsets and Apple chipsets and iOS. Similar cel-
as a Python module3 . We port the Python-based analyzer frame- lular messages are collected. We are extending our code to these
work via python-for-android [46] which allows to compile phones. M OBILE I NSIGHT works well with various operators. We
the Python code into Android apk. The analyzer framework in- have run experiments with 8 carriers: four US carriers (AT&T, Ver-
tegrates all analyzers into a directed acyclic graph. Each node is izon, T-Mobile and Sprint), a US virtual operator (Project Fi) and
an analyzer, and a directed edge v→w denoting the dependency of three Chinese carriers (China Mobile/Telecom/Unicom).
w on v. Each analyzer is initiated at most once. It is shared by Wide coverage and characteristics of cellular messages. We
multiple callers when needed. validate that M OBILE I NSIGHT supports a wide range of signaling
Miscellaneous issues. We discuss two related issues. messages and those L1/L2 ones conveying control information. We
◦ Message coverage. The current version has not covered all conduct both controlled experiments and a small-scale user study
cellular messages to date. We only focus on those most useful during an 11-month period (July 2015 - Jun 2016). In the con-
ones (control-plane and L1/L2 ones carrying control information). trolled experiments, we test M OBILE I NSIGHT with representative
In principle, the same method is applicable to support all mes- usage scenarios: static, walking and driving (local and highway)
sages. We are extending M OBILE I NSIGHT to data-plane protocols under various traffic loads – idle, voice, data with different rates. In
(below-IP) and their analysis. the static test, we use iperf to generate constant UDP traffic. In the
◦ Rooted phones. M OBILE I NSIGHT currently works with rooted user study, 30 participating phones occasionally collect logs in the
phones. Studies claim that about 27.4% users have rooted phones wild over 8 operators, with the total volume being 227.95 GB.
[47]. Root should not be a big problem at current stage. M O - We next characterize their traffic patterns through the controlled
BILE I NSIGHT’s current target is the research community who does experiments. Figure 6 shows illustrative traces collected by Sam-
research on cellular networks. In fact, M OBILE I NSIGHT only re- sung S5 over T-Mobile; other phones and operators have similar
quires access permission to a specific system folder and the cellular behaviors. We make three observations. First, the heavier data traf-
interface. Once it is granted, it does not require other permissions fic result in more cellular messages (top two plots for static tests).
for root privilege. To support more mobile devices, we are also ex- The reason is that, more data delivery requires more control sup-
ploring rootless techniques, such as building M OBILE I NSIGHT as port and triggers more radio link reconfigurations. Second, mo-
a system service, and customizing boot image with minimal modi- bility causes more signaling and dynamics. The third plot shows
fication to grant cellular access privilege to MobileInsight . a driving test which starts around the 120th second (2nd minute),
turns on mobile data (background) at the 600th second, and adds
ping around the 1200th second. Mobility triggers frequent radio
link reconfigurations at PHY. It also incurs more signaling mes-
7. E VALUATION sages from RRC and NAS. Peaks are observed for certain control
We next assess M OBILE I NSIGHT to show its (1) in-device sup- events (handoff). Third, the lower-layer messages are much heavier
port for diverse phone models, chipsets and operators and wide- than the higher-layer ones. This is because the device interacts with
coverage of cellular messages, (2) effectiveness and runtime sup- the core network much less frequently than with the base station.
port, and (3) tolerable system overhead. We show the message breakdown in the bottom plot ([1200, 1800]
seconds of the 3rd plot) and the CDF in Figure 7a. PHY control
3
We choose Python instead of Java-based Android programming messages are an-order-magnitude higher than MAC, which has an-
for two reasons: (1) cross-platform support: M OBILE I NSIGHT has other order-of-magnitude higher than RRC and NAS. The control
both in-device and desktop versions on Windows/Linux/OS X. Us- plane (RRC and NAS) messages yield a bursty pattern. They come
ing Python ensures that the analyzers can run on all platforms with-
out modifications; (2) extensibility: M OBILE I NSIGHT aims to sup- every several seconds, but can reach up to 20-30 messages/s. Note
port direct execution of analytics as plugins. Python is more suit- that M OBILE I NSIGHT has not supported a full set of L1/L2 cellular
able for this purpose. messages (see Table 4) and the total traffic is underestimated.
 1000 10Mbps
Number of messages per second
SIGHT parses and analyzes messages. For each message, the pro-
500
cessing time is defined as the elapsed interval from its arrival to
0
200 1Mbps 100Kbps 10Kbps its completion of all analyses. In this experiment, we run the
100 in-device logger with all supported signaling messages activated
0 (Table 4), and all protocol analyzers enabled (Table 5). Figure 9
300 0 20 40 60 80 100 120
200 start driving w/ data (background) w/ ping shows the processing time under light (< 500 msg/s) and heavy
100 (≥ 500msg/s) loads. M OBILE I NSIGHT completes 99% processing
0 in less than 0.8ms, except the low-end, heavy-load case that it fin-
300 0 300 600 900 1200 1500 1800
PHY MAC PDCP RRC NAS ishes 90% within 0.8ms. The maximum processing time observed
200
is 33ms. The low-end one (1.2GHz CPU) performs slightly worse
100
50 than the other phones. This validates M OBILE I NSIGHT largely
5 meets the realtime requirement.
1200 1320 1440 1560 1680 1800
Time (second)
Effectiveness in extracting protocol state dynamics. MO-
Figure 6: Cellular message traffic patterns in the controlled tests. BILE I NSIGHT can correctly track runtime protocol states and key
configurations. For each signaling protocol, we compare the signal-
100 # volume 227.95 GB ing messages from M OBILE I NSIGHT and those from QXDM. We
# msg 67,285,683
80 4G/3G 4G (91%), 3G (9%) confirm that they are identical, because their data sources are the
CDF (%)

PHY Release Rel-7, Rel-8, Rel-9 , same. We use the logs from our user study to retrieve the protocol
60 MAC Rel-10, Rel-11, Rel-12
state machines. We find that all follow the standard specifications,
PDCP Layers PHY (71.8%),
40 RRC MAC (9.0%), and no mismatch is observed. All protocol states summarized in Ta-
NAS PDCP (8.3%),
RRC (10.0%),
ble 6 can be observed under different scenarios. The elapsed time
1 10 100 1000 NAS (0.6%), needed by M OBILE I NSIGHT to track the current protocol state is
CDMA/EvDo (0.3%)
Number of msgs per second bounded by the message processing time, which is less than 0.8ms
(b) User-study dataset statistics
(a) CDF in a driving test for 90% messages and 33ms at maximum (Figure 9).
Figure 7: Cellular traffic characteristics. We summarize some key 4G protocol configurations retrieved
from our user study in Table 8. These parameters unveil essen-
tial runtime information for end devices, including RRC connec-
Figure 7b shows he statistics from the user-study dataset. We tivity timers (§5.1), ciphering/integrity protection parameters from
find that the results are device independent and combine them in mobility management protocol, and QoS profiles from the session
analysis. There are much more 4G messages (91%) than 3G (9%). management protocol. We clearly observe diversity among carriers
This indicates the popularity and wide deployment of 4G. We ob- and even within each carrier. For example, Sprint chooses different
serve control information from various 3GPP releases (from Rel-7 RRC timers from others. In most cases, it does not enable short
to Rel-12). This implies the hybrid deployment and evolution of DRX (0 means no T2 and a direct jump to long DRX). Its T1 uses
the infrastructure. Moreover, NAS messages are much fewer than three options (10/100/200 ms); Its short DRX cycle is mainly con-
RRC and PHY. This is also because the device interacts with the figured as 80ms (40ms in few samples, 0.3%). We have also seen
core network much less frequently than with the base station. CD- diversity in encryption and QoS settings. Note that, China mobile
MA/EvDo messages are also observed in Verizon and Sprint 3G. does not enable encryption, thus exposing itself to attacks (see the
They are less observed because of our recent support for them and security followup result in §8). EEA (EPS Encryption Algorithm)
thus relatively less logs collected. and EIA (EPS Integrity Algorithm) are the standardized cipher al-
gorithms for 4G LTE. For QoS, the larger the value, the lower the
7.2 Responsiveness and Effectiveness QoS. It can be used to troubleshoot performance issues (§8).
Effectiveness in inferring operation logic. We next show that
Message monitoring rate. We examine how responsive M O - M OBILE I NSIGHT can infer most handoff operation logics defined
BILE I NSIGHT parses runtime cellular message. We record every by network operators. We first infer handoff policies per cell and
cellular message’s arrival (at monitor) and departure (after being then assemble them per frequency. Figure 10 shows four 4G in-
parsed) timestamps, and calculate the message number every sec- stances inferred by M OBILE I NSIGHT (one for each US carrier). A
ond. Ideally to satisfy the realtime requirement, the departure rate frequency band unit is indexed by an EARFCN (E-UTRA Absolute
should match with the arrival rate. This corresponds to a line Radio Frequency Channel Number) [48]. Each carrier has multi-
y = x, with x as the arrival (generation) rate from the hardware ple licensed channels for 4G and 3G. For example, channels 5780,
interface, and y as the departure rate from M OBILE I NSIGHT’s mon- 1975, and 825 are three LTE ones used by AT&T, with downlink
itor. In this experiment (and hereafter), we mainly use three phone center frequencies at 739MHz, 2112.5MHz and 1952.5MHz. Due
models with different capabilities: low-end (LG-Tribute), medium- to space limit, we do not show the handoff policies inferred for all
end (Samsung S5) and high-end (Nexus 6P) in this test (summa- channels. They are in a similar form, but parameters and states
rized in Table 7). Figure 8 shows the result using AT&T. The results may differ. For instance, 3G→4G handoff has distinct rules from
are similar for other operators. The results show that M OBILE I N - the 4G→3G one. Our inference process validates the hypothesis
SIGHT approximates the ideal line y = x for most phones in most that operators do follow well-justified practices [34–36]. All opera-
cases. Only for the low-end one, the processing speed slightly vi- tors almost use the identical handoff policy per frequency. So each
brates around the line. It implies that the monitoring sometimes cell’s state machine over the same channel can be readily aggre-
(mainly under heavy load) lags a little bit behinds but is compen- gated without conflicts; Each observation either coincides or com-
sated afterwards (see the points below the curve). It does not hurt plements another. The aggregated handoff logic merges quickly
the monitoring because two separate processes are used for proxy within several rounds. It also implies that, the inferred handoff
and parse daemons (§4.3). logic is likely to be correct because it is consistent among the same
Processing time. We examine how responsive M OBILE I N -
 600 600 600

Departure rate (pkt / s)

Departure rate (pkt / s)

Departure rate (pkt / s)

500 y=x 500 y=x 500 y=x
400 400 400
300 300 300
200 200 200
100 100 100
0 0 0
0 100 200 300 400 500 600 0 100 200 300 400 500 600 0 100 200 300 400 500 600
Arrival rate (pkt / s) Arrival rate (pkt / s) Arrival rate (pkt / s)
(a) LG Tribute (b) Samsung Galaxy S5 (c) Huawei Nexus 6P
Figure 8: M OBILE I NSIGHT message departure rate as a function of arrival rate from hardware cellular interface.
time (ms)

Table 9: Accuracy for predicting upcoming handoffs.

15 Tribute S5 6P
10
5 AT&T T-Mobile Sprint Verizon
0 0 5000 10000 15000 20000 25000 30000 #Samples 11,050 10,178 10,042 2,741
(a) Illustration of 30000 samples with light load: <500 msg/s Accuracy 90.7% 91.8% 95.3% 87.5%
100 100 100 100 Table 11: Log storage overhead in M OBILE I NSIGHT.
80 80
CDF (%)

CDF (%)

60 95 60 95 Control only Control+data Control+data+PHY

0 0.5 1 0 5 10 15 20
40 Tribute 40 Tribute Hex log size (1-hour) 0.36MB 3.89MB 41.40MB
S5 S5 Avg. log growth speed 0.79Kbps 8.64Kbps 92.00Kbps
20 20
6P 6P Avg. log size reduction 115.6x 10.62x N/A
00 00
0.5 1 1.5 2 2 4 6 8 10
Proc time (ms) Proc time (ms)
(b) CDF: light traffic (c) CDF: heavy traffic radio measurement meets the trigger conditions). No false nega-
Figure 9: M OBILE I NSIGHT’s processing time under light (<500 tive errors are observed since the handoff decision indeed considers
msg/s) and heavy (≥500 msg/s) loads. radio quality [36]. These results confirm that, our inference is al-
most complete, covering most rules used by operators through the
device-only observations.
Table 8: 4G protocol state-relevant parameters from 5 carriers.

T1 (ms)
AT&T
200 (99.9%)
T-Mobile
500 (100%)
Sprint
200 (54.4%)
Verizon
200 (99.5%)
CMCC
60 (100%) 7.3 System Overhead
100 (0.1%) 100 (31.2%) 10 (0.5%)
RRC
TshortDRX (ms) 20 80
10 (14.4%)
0 (85.6%), 80 40 20
CPU and memory. We assess M OBILE I NSIGHT’s CPU and
T2 /TshortDRX 1 1 0 (85.6%), 2 0, 4 2 RAM usage. We enable all the supported messages (Table 4) and
Conn→ 10 10 4 10 13
idle (s) ±0.9 ±0.6 ±0.5 ±0.8 ±0.5 protocol analyzers (Table 5), and record their usage every second
EMM
Encryption
Integrity
EEA2
EIA2
EEA2
EIA2
EEA2
EIA2
EEA2
EIA2
NULL
EIA2
when we export parsed messages and analysis results into a file.
QoS class 8 6 9 1 (voice), 5 9 We divide the resource consumption into two parts: by M OBILE I N -
ESM Max dlink 150Mbps 256Mbps 200Mbps 138Mbps (data), 256Mbps
bitrate 80Kbps (voice) SIGHT service and by other relevant operations (e.g., file I/O). Fig-
ure 11 shows the average CPU and memory usage. Regarding M O -
BILE I NSIGHT itself, the CPU consumption for monitor and ana-
type of cells. We also observe that intra-frequency handoff (over
lyzer modules is about 1-3% for S5 and 6P, and 6-7% for LG Trib-
the same frequency) is the most common one with the highest pri-
ute. For all phone models, the average RAM usage is below 15 MB
ority. The handoff logic varies with carriers. Indeed, operators
(maximum < 30MB).
have freedom to customize their policies. We have also applied the
same inference to AT&T and T-Mobile 3G, and verified that sim- Energy consumption. We assess the energy cost by measuring
ilar per-frequency aggregations are used. One major difference is the phone’s power consumption with/without M OBILE I NSIGHT,
that, only intra-frequency handoff is allowed for each 3G frequency through a Monsoon power meter [50]. We use only Samsung S5
band. This is possibly because that 3G supports soft handoff be- because their back-covers are easy to remove for power measure-
tween cells under same frequency. So intra-frequency handoff is ment. Due to space limit, we show the results in three typical sce-
more preferred to provide more seamless network service. narios in Table 10. The results in many other scenarios are similar.
Given that carriers do not publicize their operation logics, we On average, M OBILE I NSIGHT consumes 11-58 mW extra power.
lack the ground truth to directly assess the correctness of our infer- The higher the traffic load, the larger the power value. However, its
ence algorithm. We thus devise an indirect approach. The idea is relative ratio remains within 4%, regardless of traffic variations.
to predict whether a handoff indeed occurs based on the inferred Storage overhead. We last gauge the storage required for M O -
handoff logic. If our inferred state machine is entirely identical to BILE I NSIGHT cellular logs. We run M OBILE I NSIGHT on Samsung
the one used by the operator, we could predict the handoff with- S5 phone in idle mode for 1-hour, and record the raw log size and
out errors. The accuracy reflects the completeness and correctness growth speed. We repeat this experiment by enabling different lev-
of prediction. Note that, the inferred one may be incomplete due els of cellular message types. Table 11 shows that, the log growth
to device-based perception only. In a word, the prediction accu- and storage consumption depends on the cellular message types
racy serves as a lower bound of the inference correctness. We run to be collected. When only the control plane messages (3G/4G-
the 10-fold cross validation [49]. Table 9 shows that M OBILE I N - RRC/MM/SM)are enabled, the log growth speed is 0.79Kbps on
SIGHT yields high prediction accuracy (87.5% to 95.3%) for four average, which is 115.6x slower than the scenario when all mes-
US carriers. It is slightly lower for Verizon because of a relatively sages are enabled. Note that the data-plane and PHY-layer mes-
smaller dataset. This validates that in practice, M OBILE I NSIGHT sages grow in proportion to the mobile user data volume. With
is effective in learning the network-side operation logic. There are active user data, the log size would grow even faster. This jus-
only false positive errors (i.e. the handoff does not occur when the tifies our optimization of on-demand log collection (§4.3), which
 monitor (4G,5780) monitor (4G,2275) monitor (4G,40978), CDMA2000 monitor (4G,5230)

RSRPserv > 116 RSRPserv < 116 RSRPserv > 108 RSRPserv < 120 RSRPserv > 106 RSRPserv < 108 RSRPserv > 100 RSRPserv < 116
monitor (4G,40978),
monitor (4G,5780), (4G,1975), (4G,825), monitor (4G,2275), (3G,637), (3G,662), (4G, 41176), (4G, 8665), monitor (4G,5230), (4G,2100)
RSRP4G,5780 > (3G,4385), (3G,4360), (3G,562) RSRP4G,2275 > (3G,2087), (2G,787-810) RSRP4G,40978 > CDMA2000 (RSRP4G,5230 >
RSRPserv + 3 RSRPserv + 4 RSRPserv + 3 ± 2 RSRPserv + 3 ± 3)
RSRP4G,5780 <
RSRP4G,2275 < or
RSRPserv + 3 RSRP4G,2275 < RSRP4G,40978 < (RSRQserv < 12
RSRP4G,5780 < RSRPserv + 4 CS voice call
RSRPserv < 118 RSRPserv + 4 RSRPserv + 3 ± 2 RSRQ4G,5230 > 19) intra-freq not satisfied
RSRPserv + 3 RSRPserv < 124
RSRPserv < 106 RSRP4G,⇤ < 107 RSRPserv < 122 EcN03G,⇤ < 14 RSRPserv < 112 (RSRPserv < 118
RSRP4G,⇤ > 107 RSCP3G,⇤ > 105 EcN03G,⇤ > 14 RSSI2G,⇤ > 105 RSRP4G,⇤ > 116 RSRP4G,2100 > 108)
handoff to handoff to
handoff to (4G,5780) handoff to (4G,*) handoff to (3G,*) handoff to (4G,2275) handoff to (3G,*) handoff to (2G,*) handoff to (4G,40978) handoff to (4G,5230) handoff to (4G,2100)
(4G,*) CDMA2000
(Intra-frequency) (Inter-frequency) (Inter-system) (Intra-frequency) (Inter-system) (Inter-system) (Intra-frequency) (Intra-frequency) (Inter-frequency)
(Inter-freq) (Inter-system)
(a) AT&T, 4G channel 5780 (b) T-Mobile, 4G channel 2275 (c) Sprint, 4G channel 40978 (d) Verizon, 4G channel 5230
Figure 10: Four instances of device-experienced mobility management policies inferred from M OBILE I NSIGHT.

Table 13: A network failure due to prepaid QoS misconfiguration

20 MobileInsight 20
idle 10Kbps 10Mbps (maximum downlink throughput throttled to 128Kbps).
off 468 ± 15.0 824 ± 14.2 1792 ± 31.4
MEM (MB)

Other
CPU (%)

15 15 on 484 ± 17.1 835 ± 20.1 1850 ± 16.1

10 10 ∆ 3.4% 1.3% 3.2% Timestamp Protocol Event
5 5 15:20:34.525 3G-SM PDP context setup request
0 Tribute S5 0 Tribute S5
Table 10: Consumed power (avg 15:20:35.633 3G-SM PDP context setup accept: dlink peak tput=2Mbps
6P 6P
± std) when M OBILE I NSIGHT 15:20:35.753 3G-SM PDP context deactivation request: QoS unsupported
Figure 11: CPU & memory off/on. 15:20:35.754 3G-SM PDP context deactivation accept
15:20:42.123 3G-SM PDP context setup request
usage. 15:20:43.278 3G-SM PDP context setup accept: dlink peak tput=2Mbps
... 3G-SM ...
Table 12: A network failure due to voice QoS misconfigurations.

Timestamp Protocol Event from NetDiag. It is observed on a Samsung S5 phone over T-

17:57:24.814 3G-SM PDP context setup request: QoS class = 1 (voice)
17:57:24.933 3G-SM PDP context setup reject: QoS unsupported
Mobile, with the VoLTE capability enabled. The failure occurs
17:57:25.435 3G-SM PDP context setup request: QoS class = 1 (voice) when the phone migrates to 3G and attempts to activate its data
17:57:24.515 3G-SM PDP context setup reject: QoS unsupported session (i.e., the PDP context). The device keeps on receiving re-
... 3G-SM ... jected session requests from the network, and is stuck at the in-
activity state of the 3G-SM protocol. By tracing the log, we find
can help reduce the storage overhead based on app demands. that the problem results from the QoS specified by the device in the
request message. It requires the QoS profile optimized for the low-
latency voice service. This request is accepted by T-Mobile 4G,
8. S HOWCASE A PPLICATIONS but is rejected by T-Mobile 3G (probably due to network resource
constraints). This is caused by the phone’s problematic implemen-
We now present three showcase examples to illustrate how M O - tation. To support VoLTE, it improperly uses the low-latency QoS
BILE I NSIGHT can assist in failure diagnosis, performance improve- profile in each request, even using 3G. Given this hint, we have
ment, and security loophole detection. These examples are not fixed this problem at the device by disabling the VoLTE feature
intended to be complete. Instead, they aim to demonstrate the when the device is in 3G.
feasibility and usefulness of building apps with M OBILE I NSIGHT. The second observed instance is a prepaid data plan violation
Moreover, M OBILE I NSIGHT is not restricted to these example sce- in AT&T. According to AT&T’s contract [51], when the prepaid
narios; other services/applications that gains from low-level cellu- user runs out of its high-speed data, (s)he can still retain the low-
lar information may benefit from M OBILE I NSIGHT. speed data connectivity (throttled to 128Kbps). But NetDiag re-
Network failure resolution. The first example is NetDiag, ports that, this policy can be violated if the prepaid user is associ-
a control-plane diagnosis tool built on top of M OBILE I NSIGHT. ated with a 3G private Femtocell; i.e., (s)he cannot gain low-speed
In presence of network failures, NetDiag aims to provide end data connectivity after running out of its high-speed data. Table 13
users reasoning about why they occur. By tracking control- shows the traceback logs in this scenario. This failure is caused
plane protocol state dynamics and operation logic at runtime, by the network-side misconfiguration for prepaid user QoS throt-
M OBILE I NSIGHT provides direct hints for network failures and tling. The phone in 3G Femtocell first attempts to activate its data
helps to resolve them. NetDiag uses four built-in analyz- session. The network accepts this request, and guarantees to pro-
ers (Table 5): LteRrcAnalyzer and WcdmaRrcAnalyzer, vide 2Mbps downlink peak throughput. However, this guarantee
LteNasAnalyzer and UmtsNasAnalyzer. It keeps track of exceeds the maximum speed (128Kbps) when running out of high-
the runtime protocol states for each protocol (3G/4G RRC, MM speed data. Upon detecting this violation, the core network deac-
and SM). When an error state (e.g., RRC connection disruption, tivates the data session immediately. But the next time the device
MM “out-of-service” state, SM “data session deactivated”) is tra- requests for data session activation, the core network still assigns
versed, it traces back all cellular events that lead to the transition to unsupported downlink peak throughput to it. The device thus keeps
this error state from the initial protocol state, and reports the entire on receiving deactivation session requests from the network, and is
event sequence to the device. By examining the event sequence, stuck at the inactivity state of the 3G-SM protocol. With this hint,
M OBILE I NSIGHT provides operation logs on why the error is trig- the mobile device can report these issues to network operators, and
gered, and offers suggestions for the device-side fix. help them resolve the network failures at fine-granularity.
We show how NetDiag helps to identify two real-world failure Security loophole detection. This case leverages M O -
cases that have not been reported before. The first one arises from BILE I NSIGHT to detect security loopholes over cellular net-
the device-side QoS misconfiguration of voice over LTE (VoLTE). works. We built a security checker with 3G/4G MM analyz-
Table 12 shows the traceback logs in 3G session management layer ers of LteNasAnalyzer and UmtsNasAnalyzer. It aims
 Table 14: Comparison of device-side solutions to retrieve and infer cellular network information.

Category Examples In-Device COTS Coverage Granularity Analysis Runtime API

√ √ √ √ √
Our approach: M OBILE I NSIGHT Almost full Fine-grained (msg-level) (ms-level)
√ √ √ √
OS API [6, 7, 52–54] Limited (mainly service states) coarse (aggregated) ×
√ √ √ √
RIL Analyzer [55] Limited (depending on AT cmds) coarse (partially) ×
√ √
PC-side Debugger [2–4, 23] × (PC) Full fine (msg-level) × ×
√ √
Radio analytics [5, 56] × (USRP) × Limited (partial PHY) Selected PHY fields (partial PHY) N/A
√ √ √ √
RRC inference e.g., [31–33, 55] Limited Selected (RRC states) (RRC only) (mainly offline) N/A
√ √ √ √
SnoopSnitch [57] Limited (IMSI catcher detection) Selected (Security only) ×

Table 15: Null signaling encryption loophole in China Mobile. Table 16: Suboptimal FCFS handoff strategy in a AT&T’s 3G cell.

Timestamp Protocol Event Timestamp Protocol Event

02:21:24.064 4G-EMM Attach req: support {EEA0,EEA2} 00:45:13.818 3G-RRC Meas control: monitor 3G and 2G
02:21:24.469 4G-EMM Security mode command: use EEA0 00:45:14.140 3G-RRC Meas report: 2G ARFCN=401, RSSI=-80dB
02:21:24.470 4G-EMM Security mode complete 17:57:15.130 3G-RRC Handoff command: to 2G ARFCN=401
02:21:24.519 4G-EMM Attach accept 17:57:15.410 3G-SM Meas report: 3G Freq=4360, RSCP=-90dBm

9. R ELATED W ORK
We first compare M OBILE I NSIGHT with other approaches to
to detect if the signaling/data communication between mobile de- learning cellular information from the device. Table 14 summa-
vice and the cellular base stations are encrypted and integrity pro- rizes the features and limitations of each scheme. It shows that
tected. To this end, it tracks the authentication and key agreement M OBILE I NSIGHT is the only software-only in-device cellular net-
(AKA) procedure [10], and the security mode activation in 3G/4G. work analyzer, which covers more 3G/4G control-plane and low-
Both procedures are carried over the 3G/4G mobility management layer protocols, supports both fine-grained information collection
(MM/EMM) layer. It checks the authentication status in the reg- and protocol analytics at runtime, operates on COTS phones , and
istration process, and the ciphering/integrity protection algorithms offers APIs for mobile applications. There are also in-device ana-
specified in the security mode commands. If the authentication fails lyzers [58–60], but they focus on application and transport layers,
or the ciphering/integrity algorithms are not activated, the user’s not cellular-specific lower-layers.
signaling or data may not be well protected over the air. In this Meanwhile, extensive research has been conducted to improve
case, a vulnerability would be reported. device-side performance over cellular networks, including video
We have applied our tool and found a new security loophole in adaptation [56], energy saving [61–63], and cellular congestion
China Mobile on its 4G mobility management protocol (EMM). As control [64, 65], etc. They could also benefit from M OBILE I N -
shown in Table 15, after registration (attach) to the network, EMM SIGHT with further access to the fine-grained, runtime informa-
configures the device to not encrypt the signaling messages (EEA0 tion. Finally, there are ongoing efforts on optimizations for hand-
algorithm). This results in the man-in-the-middle sniffing on user off [37–40], software-defined LTE [66–70] and backend cellular
behaviors and privacy intrusion. Our tool provides warnings to the infrastructure [71–73]. The insights from M OBILE I NSIGHT over
device. We are contacting the operator to fix this vulnerability. operational networks (e.g., signaling protocols and handoff poli-
Performance boost. The next showcase is a handoff advisor that cies), can help to better design the future network infrastructure.
advises whether a better-performing cell is available for handoffs.
It is built with LteRrcAnalyzer and WcdmaRrcAnalyzer,
which implement our handoff decision logic inference algorithms 10. C ONCLUSION
(§5.2). By inferring the protocol operation logic, this tool helps to
forecast the potential sub-optimal handoff behaviors from the net- The cellular network provides more control utilities than the
work and reconfigure the device to work them around. To this end, wired Internet, including radio resource control, security, mobility
it leverages the current control state and measurement reports. If support, and carrier-grade services, to name a few. Understanding
the measurement reports indicate that a faster cell (e.g. 4G) exists, these functions and their protocol operations will be important for
but the predicted target cell for handoff is slower (e.g. 3G), it alerts refining the design and optimizing application performance. How-
the device with a suboptimal handoff. ever, such fine-grained protocol operations have remained inacces-
We show a real instance on how the tool helps the device to pre- sible to the research community.
vent suboptimal handoffs. The instance occurs when certain AT&T M OBILE I NSIGHT represents our first effort to build a software
3G cell makes a handoff decision too early so that it migrates the tool to open up the blackbox operations. It enables open access to
device to a low-performance cell (2G here). Table 16 shows this the low-level protocol operations in 3G/4G from the device side. It
scenario. The device is initially served by a 3G cell. To initiate a runs on the COTS phone, but leverages its increasing capability. It
handoff, the 3G cell asks the device to measure both 2G and 3G directly extracts the signaling and/or low-layer messages from the
cells. The problem occurs when both 2G and 3G cells have good side channel toward 3G/4G hardware interface, decodes the proto-
signal strengths. Moreover, the 3G cell uses the first-come-first- col messages, and infers the protocol state dynamics and decision
serve (FCFS) handoff strategy. Consequently, the serving cell may logic at runtime through analyzers. Through M OBILE I NSIGHT’s
immediately hand over the device to 2G upon receiving the 2G re- APIs, applications can benefit from accessing such low-level do-
port first, without waiting for the 3G measurement report. It thus main knowledge. In presence of network failures, security loop-
misses the desired handoff to 3G. Our tool captures this issue by holes, or performance degrade, M OBILE I NSIGHT helps to detect
inferring this 3G cell’s decision logic, and reports the suboptimal the problematic instances, infer the root causes, and suggest fixes.
handoff before it is triggered. Given this advice, we eliminate this In the broader context, M OBILE I NSIGHT is designated to be an
suboptimal handoff by disabling 2G (via secret codes) at the device. open, extensible tool for the community and by the community. It
may help us to examine cellular networks in the large-scale setting https://android.googlesource.com/kernel/msm.git/+/androi
via crowdsourcing. More community efforts are clearly needed to d-6.0.0_r0.9/drivers/usb/gadget/android.c.
enhance and extend every aspect, particularly analyzers and appli- [25] Android source code for qualcomm cellular diagnostic mode.
cations atop. The collected datasets can further be shared within https://android.googlesource.com/kernel/msm.git/+/androi
the community. Our own experience so far has confirmed that such d-6.0.0_r0.9/drivers/char/diag/.
tool-building efforts are quite worthwhile and can be rewarding. [26] Android source code for meadiatek cellular diagnostic mode.
Acknowledgments: We thank the anonymous reviewers and shep- https://android.googlesource.com/kernel/mediatek/+/android
herd for their constructive comments. This work is supported in -4.4.4_r3/drivers/misc/mediatek/.
part by NSF awards (CNS-1526456, CNS-1526985, CNS-1423576 [27] ios baseband commands. https:
and CNS-1421440). //www.theiphonewiki.com/wiki/Talk:Baseband_Commands.
[28] 3GPP. TS36.300: E-UTRA and E-UTRAN; Overall
description; Stage 2, 2011.
11. R EFERENCES [29] Wikipedia: Abstract syntax notation one (asn.1). https:
//en.wikipedia.org/wiki/Abstract_Syntax_Notation_One.
[1] Cisco Visual Networking Index. Global Mobile Data Traffic
[30] K. Sandlund, G. Pelletier, and L. Jonsson. The robust header
Forecast Update, 2014–2019, 2015.
compression (rohc) framework, 2010. RFC 5795.
[2] Qualcomm. QxDM Professional - QUALCOMM eXtensible
[31] S. Rosen, H. Luo, Q. A. Chen, Z. M. Mao, J. Hui, A. Drake,
Diagnostic Monitor.
and K. Lau. Discovering fine-grained rrc state dynamics and
http://www.qualcomm.com/media/documents/tags/qxdm.
performance impacts in cellular networks. In MobiCom,
[3] Xcal-mobile. http://www.accuver.com. 2014.
[4] MTK Catcher. http: [32] J. Huang, F. Qian, A. Gerber, Z. Mao, S. Sen, and
//www.finetopix.com/showthread.php/40844-MTK-Catcher. O. Spatscheck. A Close Examination of Performance and
[5] S. Kumar, E. Hamed, D. Katabi, and L. Erran Li. LTE Radio Power Characteristics of 4G LTE Networks. In ACM
Analytics Made Easy and Accessible. In ACM SIGCOMM, MobiSys, 2012.
2014. [33] F. Qian, Z. Wang, A. Gerber, Z. Mao, S. Sen, and
[6] Android.telephony. http://developer.android.com/reference/ O. Spatscheck. Characterizing Radio Resource Allocation
android/telephony/package-summary.html. for 3G Networks. In IMC, 2010.
[7] Android telephonymanager class. http://developer.android.co [34] ZTE UMTS Handover Description. http://www.slideshare.n
m/reference/android/telephony/TelephonyManager.html. et/quyetnguyenhong/zte-umtshandoverdescription.
[8] Google. Project fi, 2015. https://fi.google.com/about/. [35] Netmanias. Overview of LTE handover. http://www.netman
[9] 3GPP. TS24.008: Mobile Radio Interface Layer 3, 2012. ias.com/en/post/techdocs/6224/emm-procedure-6-handove
[10] 3GPP. TS24.301: Non-Access-Stratum (NAS) for EPS; , Jun. r-without-tau-part-1-overview-of-lte-handover.
2013. [36] Blind handover. https://www.linkedin.com/groups/Can-any
[11] 3GPP. TS25.331: Radio Resource Control (RRC), 2006. body-explain-what-exactly-1180727.S.158571676.
[12] 3GPP. TS36.331: Radio Resource Control (RRC), 2012. [37] K. Dimou, M. Wang, Y. Yang, M. Kazmi, A. Larmo,
[13] 3GPP. TS36.211: Evolved Universal Terrestrial Radio J. Pettersson, W. Muller, and Y. Timner. Handover within
Access (E-UTRA); Physical channels and modulation. 3gpp lte: design principles and performance. In Vehicular
[14] 3GPP. TS36.212: Evolved Universal Terrestrial Radio Technology Conference Fall (VTC 2009-Fall), 2009 IEEE
Access (E-UTRA); Multiplexing and channel coding. 70th, pages 1–5. IEEE, 2009.
[15] 3GPP. TS36.213: Evolved Universal Terrestrial Radio [38] T. Jansen, I. Balan, J. Turk, I. Moerman, and T. Kurner.
Access (E-UTRA); Physical layer procedures. Handover parameter optimization in lte self-organizing
[16] 3GPP. TS36.321: Evolved Universal Terrestrial Radio networks. In Vehicular Technology Conference Fall (VTC
Access (E-UTRA); Medium Access Control (MAC) protocol 2010-Fall), 2010 IEEE 72nd, pages 1–5. IEEE, 2010.
specification, Mar. 2014. [39] A. Lobinger, S. Stefanski, T. Jansen, and I. Balan.
[17] 3GPP. TS36.322: Evolved Universal Terrestrial Radio Coordinating handover parameter optimization and load
Access (E-UTRA); Radio Link Control (RLC) protocol balancing in lte self-optimizing networks. In Vehicular
specification, Sep. 2012. Technology Conference (VTC Spring), 2011 IEEE 73rd,
[18] 3GPP. TS36.321: Evolved Universal Terrestrial Radio pages 1–5. IEEE, 2011.
Access (E-UTRA); Packet Data Convergence Protocol [40] L. Korowajczuk. LTE, WiMAX and WLAN network design,
(PDCP) specification, Jun. 2014. optimization and performance analysis. John Wiley & Sons,
[19] 3GPP. TS27.007: AT command set for User Equipment 2011.
(UE), 2011. [41] P. Dupont, B. Lambeau, C. Damas, and A. v. Lamsweerde.
[20] Nexus 5 field test mode. https://play.google.com/store/apps/d The qsm algorithm and its application to software behavior
etails?id=com.cellmapper.nexus5fieldtestmode&hl=en. model induction. Applied Artificial Intelligence,
[21] Field test mode: What it is and how to enable it on your 22(1-2):77–115, 2008.
phone. http://www.ubersignal.com/field-test-mode. [42] N. Walkinshaw, K. Bogdanov, M. Holcombe, and
[22] Android platform development kit: Radio layer interface. S. Salahuddin. Reverse engineering state machines by
http://www.netmite.com/android/mydroid/development/pdk/ interactive grammar inference. In Reverse Engineering,
docs/telephony.html. 2007. WCRE 2007. 14th Working Conference on, pages
209–218. IEEE, 2007.
[23] xgoldmon. https://github.com/2b-as/xgoldmon.
[43] C. Damas, B. Lambeau, P. Dupont, and A. Van Lamsweerde.
[24] Android source code for usb tethering.
Generating annotated behavior models from end-user
 scenarios. Software Engineering, IEEE Transactions on, [61] C. Shi, K. Joshi, R. K. Panta, M. H. Ammar, and E. W.
31(12):1056–1073, 2005. Zegura. Coast: collaborative application-aware scheduling of
[44] J. Oncina and P. Garcia. Inferring regular languages in last-mile cellular traffic. In Mobisys’14, pages 245–258.
polynomial update time. 1992. ACM, 2014.
[45] Mobileinsight. http://metro.cs.ucla.edu/mobile_insight. [62] X. Chen, A. Jindal, N. Ding, Y. C. Hu, M. Gupta, and
[46] Python-for-android project. R. Vannithamby. Smartphone background activities in the
https://python-for-android.readthedocs.org/en/latest/. wild: Origin, energy drain, and optimization. In Proceedings
[47] AndroidHeadlines. Over 27.44% users root their phone(s) in of the 21st Annual International Conference on Mobile
order to remove built-in apps. Computing and Networking, pages 40–52. ACM, 2015.
http://www.androidheadlines.com/2014/11/50-users-root- [63] D. H. Bui, Y. Liu, H. Kim, I. Shin, and F. Zhao. Rethinking
phones-order-remove-built-apps-one.html. energy-performance trade-off in mobile web page loading. In
Proceedings of the 21st Annual International Conference on
[48] 3GPP. TS36.508: Evolved Universal Terrestrial Radio
Mobile Computing and Networking, pages 14–26. ACM,
Access (E-UTRA) and Evolved Packet Core (EPC);
2015.
Common test environments for User Equipment (UE)
conformance testing, Dec 2015. [64] F. Lu, H. Du, A. Jain, G. M. Voelker, A. C. Snoeren, and
A. Terzis. Cqic: Revisiting cross-layer congestion control for
[49] Cross-validation (statistics).
cellular networks. In Proceedings of the 16th International
https://en.wikipedia.org/wiki/Cross-validation_(statistics).
Workshop on Mobile Computing Systems and Applications,
[50] Monsoon power meter.
pages 45–50. ACM, 2015.
https://www.msoon.com/LabEquipment/PowerMonitor/.
[65] K. Winstein, A. Sivaraman, H. Balakrishnan, et al. Stochastic
[51] At&t’s prepaid data plan policy. https:
forecasts achieve high throughput and low delay over cellular
//www.att.com/shop/wireless/plans/voice/sku7420265.html.
networks. In NSDI, pages 459–471, 2013.
[52] ios developer library: Core telephony framework reference.
[66] N. Nikaein, M. K. Marina, S. Manickam, A. Dawson,
https://developer.apple.com/library/prerelease/ios/documenta
R. Knopp, and C. Bonnet. Openairinterface: A flexible
tion/NetworkingInternet/Reference/CoreTelephonyFramewo
platform for 5g research. ACM SIGCOMM Computer
rkReference/index.html.
Communication Review, 44(5):33–38, 2014.
[53] Connection manager.
[67] Openlte implementation.
https://msdn.microsoft.com/en-us/library/bb416435.aspx.
http://sourceforge.net/projects/openlte/.
[54] Windows phone: Telephony api.
[68] L. E. Li, Z. M. Mao, and J. Rexford. Toward
https://msdn.microsoft.com/en-us/library/aa922068.aspx.
software-defined cellular networks. In Software Defined
[55] N. Vallina-Rodriguez, A. Auçinas, M. Almeida, Networking (EWSDN), 2012 European Workshop on, pages
Y. Grunenberger, K. Papagiannaki, and J. Crowcroft. 7–12, 2012.
Rilanalyzer: a comprehensive 3g monitor on your phone. In
[69] X. Jin, L. E. Li, L. Vanbever, and J. Rexford. Softcell:
IMC, 2013.
scalable and flexible cellular core network architecture. In
[56] X. Xie, X. Zhang, S. Kumar, and L. E. Li. pistream: Physical CoNEXT, 2013.
layer informed adaptive video streaming over lte. In
[70] M. Arslan, K. Sundaresan, and S. Rangarajan.
MobiCom, 2015.
Software-defined networking in cellular radio access
[57] Snoopsnitch. networks: potential and challenges. Communications
https://opensource.srlabs.de/projects/snoopsnitch. Magazine, IEEE, 53(1):150–156, 2015.
[58] N. Vallina-Rodriguez, S. Sundaresan, C. Kreibich, [71] A. Iyer, L. E. Li, and I. Stoica. Celliq: real-time cellular
N. Weaver, and V. Paxson. Beyond the radio: Illuminating network analytics at scale. In 12th USENIX Symposium on
the higher layers of mobile networks. In Mobisys’15, pages Networked Systems Design and Implementation (NSDI 15),
375–387. ACM, 2015. pages 309–322, 2015.
[59] A. Nikravesh, H. Yao, S. Xu, D. Choffnes, and Z. M. Mao. [72] A. Banerjee, J. Cho, E. Eide, J. Duerig, B. Nguyen, R. Ricci,
Mobilyzer: An open platform for controllable mobile J. Van der Merwe, K. Webb, and G. Wong. Phantomnet:
network measurements. In Mobisys’15, pages 389–404. Research infrastructure for mobile networking, cloud
ACM, 2015. computing and software-defined networking. GetMobile:
[60] C. Shepard, A. Rahmati, C. Tossell, L. Zhong, and Mobile Computing and Communications, 19(2):28–33, 2015.
P. Kortum. Livelab: measuring wireless networks and [73] Z. Li, W. Wang, T. Xu, X. Zhong, X.-Y. Li, Y. Liu,
smartphone users in the field. ACM SIGMETRICS C. Wilson, and B. Y. Zhao. Exploring cross-application
Performance Evaluation Review, 38(3):15–20, 2011. cellular traffic optimization with baidu trafficguard. 2016.

View publication stats