Pierdomenico Fiadino

Mirko Schiavone

Pedro Casas

Vivisecting WhatsApp in Cellular Networks: Servers, Flows, and Quality of Experience

Keywords: WhatsApp, Large-Scale Measurements, Cellular Networks, Traffic Characterization, Quality Of Experience

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

WhatsApp is doubtlessly the leading instant multimedia messaging service in cellular networks. WhatsApp is a cross-platform mobile application which allows users worldwide to instantly exchange text messages and multimedia contents such as photos, audio and videos. It currently handles more than 64 billion messages per day, including 700 million photos and 100 million videos [START_REF]WhatsApp Blog[END_REF]. With half a billion of active users, it has become the fastest-growing company in history in terms of users [START_REF] Blodget | Everyone Who Thinks Facebook Is Stupid To Buy What-sApp For $19 Billion Should Think Again[END_REF]. Such an astonishing popularity does not only have a major impact on the traditional SMS/MMS business, but might also have a remarked impact on the traffic, especially due to the sharing of multimedia messages.

The goal of this paper is to provide the first large-scale characterization of the WhatsApp service. By analyzing a week of cellular traffic flows collected in February 2014 at the cellular network of a major European ISP, we shed light on the WhatsApp hosting network architecture, the characteristics of the generated traffic, and the performance of media transfers, specially as perceived by the end users. As WhatsApp runs on top of encrypted connections, our measurements are complemented with a dissection of the WhatsApp protocol through hybrid measurements, enabling a subsequent passive monitoring at the large-scale. In addition, due to its large worldwide popularity, the WhatsApp dataset is augmented with geo-distributed DNS active measurements using more than 600 RIPE Atlas boxes distributed around the globe [START_REF]The RIPE Atlas measurement network[END_REF]. As we shall see next, this paper it is not just about finding which flows belong to the WhatsApp service and analyze them. Indeed, there are many measurement challenges associated to the characterization of such a service: the data gathering, the processing and the interpretation are already very complex per se, given the number of different measurement sources and datasets.

Recent papers have partially addressed the characterization of the WhatsApp traffic [START_REF] Vergara | When Mice Consume Like Elephants: Instant Messaging Applications[END_REF][START_REF] Aucinas | Staying Online While Mobile: The Hidden Costs[END_REF], but using very limited datasets (i.e., no more than 50 devices) and considering an energy-consumption perspective. Our study follows previous papers characterizing popular Internet services such as YouTube [START_REF] Finamore | YouTube Everywhere: Impact of Device and Infrastructure Synergies on User Experience[END_REF], Facebook [START_REF] Fiadino | Characterizing Web Services Provisioning via CDNs: The Case of Facebook[END_REF], Google+ [START_REF] Magno | New Kid on the Block: Exploring the Google+ Social Graph[END_REF], Skype [START_REF] Chen | Quantifying Skype User Satisfaction[END_REF], and Dropbox [START_REF] Drago | Inside Dropbox: Understanding Personal Cloud Storage Services[END_REF] among others. This paper represents an extended version of a recently presented abstract on the topic [START_REF] Fiadino | Vivisecting WhatsApp through Large-Scale Measurements in Mobile Networks[END_REF].

Our main findings are the following: (i) Despite its worldwide popularity, WhatsApp is a fully centralized service hosted by the cloud provider SoftLayer at servers located in the US. (ii) While the application is mainly used as a text-messaging service in terms of transmitted flows (more than 93%), video-sharing accounts for about 36% of the exchanged volume in uplink and downlink, and photo-sharing/audio-messaging for about 38%. (iii) Despite achieving flow download throughputs of 1.5 Mbps on average, about 35% of the total file downloads are potentially badly perceived by users. (iv) Flow duration characteristics depend on the device OS. In particular, different platforms employ different app-level timeouts.

Besides these contributions, our study also provides an overview on the worldwide WhatsApp outage reported on February the 22nd of 2014 [START_REF]WhatsApp Status in Twitter[END_REF], characterizing the event as observed from the analyzed dataset. The measurements are complemented with external Online Social Networks (OSNs) feeds (Twitter in this case) to verify that the outage was negatively perceived by the users, immediately at the time were the event occurred, additionally demonstrating the feasibility of using OSNs data to provide near real-time evidence of user quality impairments in large scale service outages. We believe that the information provided in this paper is highly useful for cellular operators to better understand how WhatsApp works and performs, and specially to provide means for analyzing and tracking its evolution inside their networks, including a Quality of Experience (QoE) perspective. To the best of our knowledge, we are the first to provide a large-scale characterization of the complete WhatsApp service running on its live environment.

The remainder of this paper is organized as follows: §2 briefly describes the client application work-flow in terms of exchanged messages and server roles as identified from hybrid end-device measurements. §3 explains the procedure used to detect the WhatsApp flows in the large-scale cellular passive measurements, and characterizes the underlying hosting network. The analysis of the WhatsApp traffic is presented in §4, including both the flow characteristics per communication and end-device types and the performance in terms of transfer throughputs. §5 presents the results of subjective QoE tests performed with customers downloading multimedia files through WhatsApp, and applies them to the analyzed large-scale traffic dataset. §6 provides an overview of the WhatsApp outage. Finally, §7 concludes this work.

An Overview on WhatsApp

WhatsApp uses encrypted communications, therefore the first step to analyze its functioning in the wild is to better understand its inner working. To this end, we rely on the manual inspection of hybrid measurements. We actively generate WhatsApp text and media flows at end devices (both Android and iOS), and passively observe them at two instrumented access gateways. We especially paid attention to the DNS traffic generated by the devices. WhatsApp uses a customized version of the open eXtensible Messaging and Presence Protocol (XMPP) [START_REF] Saint-Andre | Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence[END_REF]. XMPP is a protocol for message oriented communications based on XML. Not surprising, our measurements revealed that WhatsApp servers are associated to the domain names whatsapp.net (for supporting the service) and whatsapp.com (for the company website). As indicated in table 1, different third level domain names are used to handle different types of traffic (control, text messages, and multimedia messages). When the client application starts, it contacts a messaging or chat server {e|c|d}X.whatsapp.net listening on port 5222, where X is an integer changing for load balancing. This port is assigned by IANA to clear-text XMPP sessions. Nevertheless, the connection is SSL-encrypted. This connection is used for text messages as well as control channel, and is kept up while the application is active or in background. If the connection is dropped, a new one with the same or another messaging server is immediately re-established. In case the application client is not running, the message notification is delivered through the OS push APIs.

The application also offers the capability of multimedia contents transfer, including photos, audio and video. Transfers are managed by HTTPS multimedia (mm) servers listening on port 443. Those servers are associated to different domain names depending on their specific task: mmsXYZ.whatsapp.net and mmiXYZ.whatsapp.net are both used for audio and photo transfers, while mmvXYZ.whatsapp.net are exclusively reserved for videos. For each object, a ded-icated TLS-encrypted connection towards a mm server is established. Uploads are started immediately, while downloads of large objects need to be manually triggered by the receiving user to avoid undesired traffic. These servers do not perform any transcoding. As we shall see in §4, the two server classes have very different network footprints. While connections to chat servers are characterized by low data-rate and long duration (specially due to the control messages), media transfers are carried by short and heavy flows.

Hosting Infrastructure

The first part of the study focuses on discovering where the servers are located. For doing so, we rely on the analysis of a complete week of WhatsApp traffic traces, consisting of more than 150 million flows collected at the core of a European national-wide cellular network, from 18.02 till 25.02. Flows are captured at the well-known Gn interface [START_REF] Bannister | Convergence Technologies for 3G Networks: IP, UMTS, EGPRS and ATM[END_REF], using the METAWIN cellular network monitoring system [START_REF] Ricciato | Traffic Monitoring and Analysis for the Optimization of a 3G network[END_REF]. To preserve user privacy, any user related data are anonymized, while packets' payload is removed on the fly. Using the MaxMind GeoIP databases [START_REF]MaxMIND GeoIP Databases[END_REF], the ASes serving the corresponding flows are included in the dataset. Traffic flows are continuously imported and analyzed through DB-Stream [START_REF] Bär | DBStream: an Online Aggregation, Filtering and Processing System for Network Traffic Monitoring[END_REF], a data stream warehouse tailored for large-scale traffic monitoring applications. In the following analysis, volume and flow counts are normalized to preserve business privacy, and time-series are constructed with 10-min time slots resolution.

Methodology

WhatsApp communications are encrypted, thus we firstly devised a classification approach to identify WhatsApp flows. The approach is based on the HTTPTag classification system [START_REF] Fiadino | HTTPTag: A Flexible On-line HTTP Classification System for Operational 3G Networks[END_REF] running on DBStream. HTTPTag classification consists in applying pattern matching techniques to the hostname field of the HTTP requests. Given the usage of encryption, and the need to also classify non-HTTP traffic, the approach was extended to consider the analysis of DNS requests, similar to [START_REF] Bermudez | DNS to the rescue: Discerning Content and Services in a Tangled Web[END_REF]. Every time a user issues a DNS request for the Fully Qualified Domain Name (FQDN) *.whatsapp.net, HTTPTag creates an entry mapping this user to the server IPs provided in the DNS reply. Each entry is time stamped and contains the TTL replied by the DNS server. Using these mappings, all the subsequent flows between this user and the identified servers are assumed to be WhatsApp flows. The approach also allows for a finer-grained classification, using more specific patterns, i.e. (c|d|e)*.whatsapp.net for chat flows and mm*.whatsapp.net for media flows. To avoid miss-classifications due to out-ofdate mappings, every entry expires after a TTL-based time-out. To increase the robustness of the approach, the list of IPs is augmented by adding the list of server IPs signing the TLS/SSL certificates with the string *.whatsapp.net. Indeed, our hybrid measurements revealed that WhatsApp uses this string to sign all its communications. Finally, we use reverse DNS queries to verify that the list of filtered IPs actually corresponds to a WhatsApp domain.

Measurements Analysis

The complete one-week server IP mappings resulted in a total of 386 IPs identified as hosting the service, belonging to a single AS called SoftLayer (AS number 36351) [START_REF]SoftLayer: Cloud Servers[END_REF]. To avoid biased conclusions about the set of identified IPs from a single vantage point, we performed an active measurements campaign using the RIPE Atlas measurement network [START_REF]The RIPE Atlas measurement network[END_REF], where we analyzed which IPs were obtained when resolving the same FQDNs from 600 different boxes around the globe during multiple days. These active measurements confirmed that the same set of IPs is always replied, regardless of the geographical location of the requester. SoftLayer is a US-based cloud infrastructure provider consisting of 13 data centers and 17 Points of Presence (PoPs) distributed worldwide. Using MaxMind geoloacalization capabilities, we observed that despite its geographical distribution, WhatsApp traffic is handled mainly by the data centers in Dallas and Houston. Given that the city-location accuracy of public GeoIP databases such as MaxMind is questionable [START_REF] Poese | IP Geolocation Databases: Unreliable?[END_REF], we confirmed through traceroutes and active RTT measurements that the servers are indeed located in the US. Tab. 2 reports the different number of prefixes covered by the identified IPs in SoftLayer. Note that we consider different netmasks (e.g., /24, /16, /8) for simple counting and aggregation purposes, i.e., we do not claim that the prefixes are fully covered/own by the ASes. The range of server IPs is highly distributed, covering 51 different /24 prefixes and 24 /8 ones. The table additionally shows the total number of SoftLayer IPv4 IPs. However, in terms of flows and activity (measured as 10-min active slots), the range 50.22.225.0/24 captures a main share.

To complement the picture of the servers location, we investigate the distance to the vantage point in terms of RTTs, analyzing the minimum RTT values. RTTs are obtained from active ping measurements, performed during the span of the dataset from a single location in Europe. Every unique IP hosting WhatsApp is pinged with trains of 100 ICMP echo request packets every 10 minutes. Fig. 2 plots the distribution of the minimum RTT to (a) all the server IPs hosting WhatsApp, and (b) the same min RTT values, weighted by the previously considered 4 features (i.e., flows, active slots, and traffic volumes) to get a better understanding of the traffic sources. The distribution presents some clear steps indicating the existence of different data centers or hosting locations. The min RTT is always bigger than 100ms, confirming that WhatsApp servers are located outside Europe, where our vantage point is located. Fig. 2(b) shows that the service is evenly handled between two different yet potentially very close locations at about 106 ms and 114 ms, which is compatible with our previous findings.

To further understand how the hosting infrastructure of WhatsApp is structured, Fig. 3 depicts the distribution of server IPs over the same previous 4 features. The figures additionally depict chat and multimedia servers to discriminate their roles. Regarding (a) number of flows and (b) active time slots, we clearly observe how chat servers handle the biggest share of the flows, with a highly active set of server IPs. On the contrary, multimedia servers are much less active and handle a limited share of flows. In terms of volume, the picture is completely the opposite when considering traffic volumes in (c) downlink and (d) uplink directions.

Fig. 4 shows the dynamics of WhatsApp for 3 consecutive days, including the number of active server IPs, the fraction of flows and traffic volume shares, discriminating by chat and mm traffic. The mm category is further split into photos/audio (mmi and mms) and video (mmv). The time-series present a clear night/day pattern with two daily peaks at noon and 8pm. than 200 IPs are active even in the lowest load hours. When analyzing the active IPs per traffic type, we see how chat servers are constantly active, as they keep the state of active devices to achieve an efficient and fast push of the messages to the device. Fig. 4(b) shows the flow count shares, revealing how chat flows are clearly dominating. Once again we stop in the mmi and mms servers, which seem to always handle the same share of flows, suggesting that both space names are used as a mean to balance the load in terms of photos and audio messages. Finally, Figs. 4(c) and 4(d) reveal that even if the mm volume is higher than the chat volume, the latter is comparable to the photos and audio messaging volume, specially in the uplink. Tab. 3 summarizes these shares of flows and traffic volume. The reader should note that our dataset does not include flows transmitted over WiFi, thus some of these results might be biased due to users potentially using WiFi for large file transfers. We are currently analyzing this potential bias as part of our ongoing work, and our first results confirm that our observations are still valid. As a conclusion, our measurements confirmed that WhatsApp is a centralized and fully US-based service. This is likely to change in the near future after Facebook's WhatsApp acquisition. As for now, all messages among users outside the US are routed through the core network. Being Brazil, India, Mexico and Russia the fastest growing countries in terms of users [START_REF]WhatsApp Blog[END_REF], such a centralized hosting infrastructure is likely to become a problematic bottleneck. Indeed, as we show in §5, the high latencies to US servers are a potential cause of bad QoE for users downloading multimedia files, due to an increased download time and a reduced TCP throughput.

Traffic Analysis

We study now the characteristics of the WhatsApp traffic in terms of size and duration. Additionally, we evaluate the performance of the service, computing the transfer throughputs as the Key Performance Indicator (KPI). Flow durations are measured with a coarse-grained resolution of one second (this is a limitation of the monitoring system, given the large amount of processed traffic), considering the time-stamps of the first and the last packet of a standard 5-tuple measured flow (note that flows are unidirectional) and adaptive flow time-outs, see [START_REF] Ricciato | Traffic Monitoring and Analysis for the Optimization of a 3G network[END_REF] for additional details. Flow throughput is estimated as the ratio between the total transferred bytes and the flow duration. Note that given the one second resolution, throughput values are somehow an underestimate of the real throughput. Still, the results obtained in the paper about flow duration allows us to claim that the absolute errors are marginal.

Fig. 5(a) shows a scatter plot reporting the flow duration vs. the flow size, discriminating by chat and mm flows. Whereas mm messages are sent over dedicated connections, resulting in short-lived flows, text messages are sent over the same connection used for control data, resulting in much longer flows. For example, some chat flows are active for as much as 62 hours. The protrusion at around 100KB is due to the fact that the client perform compression of images and most of media flows are close to that size. Fig. 5(b) indicates that more than 50% of the mm flows are bigger than 70 KB, with an average flow size of 225 KB. More than 90% of the chat flows are smaller than 10 KB, with an average size of 6.7 KB. In terms of duration, Fig. 5(c) shows that more than 90% of the mm flows last less than 1 min (mean duration of 1.8 min), whereas chat flows last on average as much as 17 minutes. The flow duration CDF additionally reveals some clear steps at exactly 10, 15 and 24 minutes, suggesting the usage of an application time-out to terminate long idle connections. This behavior is actually dictated by the operating system of the device. To better understand it, we performed a device OS classification based on manual labeling of each device based on its IMEI, covering more than 90% of the observed flows. Note that the device IMEI is not contained in the WhatsApp messages, but comes from other monitoring sources in METAWIN. Fig. 6(a) splits the analysis of the chat flow duration per device OS. The figure clearly shows that the aforementioned time-out is mainly OS-dependent, as different platforms show different values. Three different time-outs are visible for Android devices at 10, 15 and 24 mins; iOS uses a very short time-out of 3 mins, BlackBerry devices have 15 mins. long time-outs, whereas Windows Mobile phones favor 10 mins. time-outs. On the contrary, in the case of mm flows in Fig. 6(b), all the different OS show a similar behavior, with the exception of BlackBerry and Windows Phone, using a 90 secs. time-out. These observations might have a major impact on the performance of the Radio Access Network, due to different OS synchronization times and uneven resources reservation requests. Indeed, it has been recently shown that applications that provide continuous online presence such as WhatsApp can generate a significant burden on the signaling plane in cellular networks [START_REF] Aucinas | Staying Online While Mobile: The Hidden Costs[END_REF]. Considering flow throughput, Fig. 5(d) depicts the uplink and downlink throughputs for flows bigger than 1 MB. This filtering is performed as a means to improve the throughput estimations. A-priori, one might expect that the long RTTs involved in the communications to the US servers might heavily impact the achieved performance. This is confirmed for about 30% of the transmitted flows, which achieve a throughput smaller than 250 kbps. However, higher throughputs are obtained for the largest shares of flows, achieving an average per flow downlink/uplink throughput of 1.5 Mbps/800 kbps. Still, as we show next, a big share of the file downloads can actually result in a very poor quality of experience for the users.

Quality of Experience in WhatsApp

In the previous section we considered the transfer throughput as the main KPI reflecting service performance. However, in order to better understand the impacts of transfer throughputs on the experience of the users, we performed a QoE-based study of WhatsApp, relying on subjective QoE tests performed in the lab, following well defined standards for realizing the tests and analyzing the results [START_REF]Methods for Subjective Determination of Transmission Quality[END_REF][START_REF]Estimating End-to-End Performance in IP Networks for Data Applications[END_REF]. In a nutshell, 50 participants (45%/55% male/female, 23 average age, 60%/40% students/employees) provided their feedback in terms of Mean Opinion Scores (MOSs), reflecting their experienced quality while using WhatsApp for transferring video and music files. The study consisted of users receiving a multimedia file of 5MB to download on their smartphones as a What-sApp shared file. Different network conditions were emulated by connecting the phones to a network emulator, introducing different download throughput profiles via traffic shaping. At the end of each download, the user rates the overall quality in a 1-to-5 MOS scale, where 5 means excellent experience and 1 means a very bad one. Note that the file size of 5MB has a clear motivation behind: mp3 music files and short videos have a similar size. While it is clear that the 5MB flow size reflects only a fraction of the total flows (as depicted in Fig. 5(b)), the performed study permits to have some rough ideas of what the users perceive of the service in terms of quality in this case. A deeper WhatsApp QoE-based study is part of our current work. Fig. 7(a) shows the QoE results for different download throughput values, translated into waiting times. Download time is in fact the most relevant feature as perceived by the user when analyzing file transfers [START_REF] Casas | A First Look at Quality of Experience in Personal Cloud Storage Services[END_REF], as this is directly linked to anxiety and satisfaction. The figure shows that users tolerate transfers of up to 20s long with a good overall experience, whereas transfers lasting more than 80s are considered as very bad quality. A threshold of about 40s permits to approximately discriminate between good and bad experience. Fig. 7(b) plots the Flow Size vs. the Flow Download Time (FDT) for the large-scale dataset, considering only flows bigger than 1MB. If we focus on the range of flows with sizes around 5MB, we see that while the majority of the flows have a FDT below 40s, there are many downloads which highly exceed this threshold. Indeed, Fig. 7(c) shows the distribution of the FDTs, both for all the flows with size between 4MB and 6MB, as well as for all the flows bigger than 1MB. From these CDFs, one can say that almost 40% of the WhatsApp downloads with size between 4MB and 6MB have a FDT lower than 20s, resulting in good user experience. About 60% still result in an acceptable quality, and about 35% are potentially badly or very badly perceived. Finally, if we now assume that users are generally non experts and that file sizes are not taken into account into their quality expectations when downloading a video or a song through WhatsApp, we could say that similar results are observed for the complete dataset of downloaded flows bigger than 1MB. Of course this last observation is rather controversial, but still presents some notions on the experience of the end users. As a main conclusion, we see that the architectural design of WhatsApp, with servers centralized in the US, might actually have an impact on the experience of the users.

The WhatsApp Blackout

The last part of the study focuses on the analysis of the major WhatsApp worldwide outage reported since its beginning as observed in our traces. The outage occurred in February the 22nd of 2014, and had a strong attention in the medias worldwide. The event is not only clearly visible in our passive traces, but can also be correlated with the near real-time user reactions on social networks. Through the online downdetector application [START_REF] Downdetector | [END_REF] we accessed the counts of tweeter feeds containing the keyword "whatsapp", coupled with keywords reflecting service impairments such as "outage", "is down", etc.. We refer to these tweets as error tweets.

Fig. 8(a) depicts the time series of the share of bytes exchanged with the servers, the share of flows, as well as the number of error tweets during two consecutive days encompassing the outage. The traffic drastically dropped on the 22nd at around 19:00 CEST (event B), and slowly started recovering after midnight, with some transient anomalous behaviors in the following hours (events C and D). Traffic volumes in both directions did not drop completely to zero but some non-negligible fraction of the traffic was still being exchanged, suggesting an overloading problem of the hosting infrastructure. In terms of number of flows, there is a clear ramp-up on the flow counts. Very interestingly, there is a clear correlation between the events B, C and D and the number of WhatsApprelated error tweets. The users reacted on the social network immediately after the beginning of the outage, with the viral effect reaching its highest point after one hour. There is an additional outage event marked as A, which is clearly observable in the error tweet counts and has exactly the same signature of events B, C and D, i.e., a drop in the traffic volume and an increase in the flows count. As a take away of this social data analysis, one can use such information as ground truth for near real-time detection of QoE-relevant anomalies in popular services such as WhatsApp.

To better drill-down the anomaly, Fig. 8(b) depicts a 12-hour zoom-in of the traffic volume trends, split by chat and mm traffic, along with the counters of TCP flags. The bytes down counters show that the residual downlink traffic exchanged during the first part of the anomaly is due to previously queued mm transfers. In fact, while chat servers stopped working, media servers are still up and running at the beginning of the outage. We recall that connections to chat servers are also used for application control, hence they provide links to media contents. If such links have been delivered before the chat outage, the users might still be able to retrieve media objects. The chat traffic in the uplink direction does not drop to zero but slowly fades out, which actually corresponds to control flows trying to re-establish the lost connections. In particular, the TCP flags counters reveal an steeped increase of SYN packets, indicating that devices were repeatedly trying to reconnect after the servers abruptly flashed the connections (RST flags). This suggests that the servers were still reachable, thus the failure occurred at the application layer. The SYN and RST counters decrease gradually, revealing a back-off mechanism of the client application. These connection attempts explain the high increase in the flow counts during events A-D, as well as the persistence of uplink traffic to chat servers. This behaviour affected the whole WhatsApp addressing space.

Concluding Remarks

WhatsApp is the fastest-growing company in history in terms of users, and this paper presented the first large-scale characterization of the service from passive measurements collected at a national-wide cellular network. Our study fully dissected the well structured internal naming scheme used by WhatsApp to handle the different types of connections, which shall enable an easy way to monitor its traffic in the network. We discovered that WhatsApp is a centralized service, fully hosted in the US. We showed that such a centralized hosting infrastructure might negatively impact the experience of the end users. Even more, we believe that having a poorly geo-distributed network of servers might be highly harmful in terms of failures for such Internet-scale services, as revealed by the characterized worldwide outage. Finally, we showed that WhatsApp uses two different approaches for handling the messages exchanged among its users, keeping persistent connections to handle text messages and short-lived flows to send multimedia contents.

The datasets collected and analyzed in this paper correspond to a very interesting point in time in the history of WhatsApp, in which Facebook acquired the service. Given the highly distributed nature of the Facebook network [START_REF] Fiadino | Characterizing Web Services Provisioning via CDNs: The Case of Facebook[END_REF], we expect a significant change in the WhatsApp network architecture in the next couple of years, and we are currently collecting a very large-scale WhatsApp dataset to further investigate such changes in an upcoming study.

  WhatsApp/SoftLayer IP ranges. (b) Weighted IP ranges.

Fig. 1 .

 1 Fig. 1. Ranges of IPs hosting WhatsApp.

  Fig. 1(a) shows the intersection of both IP address ranges. As depicted in Fig. 1(b), when weighting the IP ranges by volume, the majority of the traffic corresponds to IPs falling in 3 /16 ranges. min RTT per WhatsApp IP. (b) Weighted min RTTs.

Fig. 2 .

 2 Fig. 2. min RTT to WhatsApp server IPs.

Fig. 4 (

 4 a) indicates that more than 350 IPs serve WhatsApp flows during peak hours. Note that no less Flows per srv. IP. (b) Active slots per srv. IP. Bytes down per srv. IP. (d) Bytes up per srv. IP.

Fig. 3 .

 3 Fig. 3. WhatsApp server IPs in terms of volume, flows, and activity shares.

Fig. 4 .

 4 Fig. 4. WhatsApp dynamics. More than 350 IPs serve WhatsApp during peak hours.

( a )

 a Flow duration vs. size.

  MM flow throughput (flow size > 1MB).

Fig. 5 .

 5 Fig. 5. WhatsApp flow characteristics and performance.

Fig. 6 .

 6 Fig. 6. Flow duration per different OS.

  WhatsApp overall quality. (b) Flow size vs. download time. (c) Flow download time distribution.

Fig. 7 .

 7 Fig. 7. QoE in WhatsApp, considering flows bigger than 1MB.

  (a) Aggregated traffic and OSN feedback. (b) A zoom-in of the TCP flag counts.

Fig. 8 .

 8 Fig. 8. The WhatsApp worldwide outage.

Table 1 .

 1 Third level domain names used by whatsapp.net and communication types.

Table 2 .

 2 Number of server IPs and prefixes used by WhatsApp.

	Service/AS	# IPs #/24 #/16 #/8
	WhatsApp	386	51	30	24
	SoftLayer (AS 36351) 1,364,480 5330 106 42

Table 3 .

 3 Volume and flows per traffic category.

Acknowledgements

This work has been performed in the framework of the EU-IP project mPlane, funded by the European Commission under the grant 318627


Peter Romirer-Maierhofer

Mirko Schiavone
email: schiavone@ftw.at

Alessandro D ' Alconzo
email: dalconzo@ftw.at

Device-specific Traffic Characterization for Root Cause Analysis in Cellular Networks

Nowadays mobile devices are highly heterogeneous both in terms of terminal types (e.g., smartphones versus data modems) and usage scenarios (e.g., mobile browsing versus machine-to-machine applications). Additionally, the complexity of mobile terminals is continuously growing due to increases in computational power and advances in mobile operating systems. In this scenario novel traffic patterns may arise in mobile networks, and it is highly desirable for operators to understand their impact on the network performance. We address this problem by characterizing the traffic of different device types and Operating systems, analyzing real traces from a large scale mobile operator. We find the presence of highly time synchronized spikes in both data and signaling plane traffic generated by different types of devices. Additionally, by investigating a real case, we show that a device-specific view on traffic can efficiently support the root cause analysis of some type of network anomalies. Our analysis confirms that large traffic peaks, potentially leading to large-scale anomalies, can be induced by the misbehavior of a specific device type. Accordingly, we advocate the need for novel analysis methodologies for automatic detection and possibly mitigation of such device-triggered network anomalies.

Introduction

In the last decade operators of mobile networks have witnessed the spread of heterogeneous mobile devices. Their heterogeneity stems from several respects: Mobile devices include different terminal types, operating systems and support a large variety of different applications. The level of device complexity is increased by the permanent evolution of their computational power, the introduction of novel mobile services and upgrades of the respective mobile APPs and Operating Systems (OSs). In such a heterogeneous and complex network scenario it is very appealing for mobile network operators i) to verify that device-specific traffic patterns are conform with the assumptions taken during dimensioning of network capacity, and ii) to identify device-specific traffic patterns that may induce undesirable events (such as temporary overload due to large device populations issuing synchronized downloads). This aspect is even more critical due to today's dynamics of mobile OSs making the assessment of device-specific traffic patterns a moving target.

In this study we present a device-specific view on traffic behavior in an operational cellular network by first categorizing device types and mobile OSs present in the network, and second by characterizing traffic patterns at different protocol layers for the resulting device-and OS-categories. Additionally, we show how device-specific traffic characterization can be exploited for the identification of the root causes of detected network anomalies, a task which is typically resource-intensive in operational networks [START_REF] D'alconzo | Distribution-Based Anomaly Detection in 3G Mobile Networks: From Theory to Practice[END_REF]. Monitoring device-specific traffic behavior enables the discrimination of anomalies caused by large populations of specific devices from other, network-triggered anomalies, such as e.g., malfunctioning of network equipment typically affecting all device types at the same time.

The remainder of this paper is organized as follows. We present our monitoring setup and approach to device categorization in §3. In §4.1 we characterize devicespecific traffic behavior at the data plane. Additionally, we report on observed similarities and differences compared to the previous work in [START_REF] Shafiq | Large-Scale Measurement and Characterization of Cellular Machine-to-Machine Traffic[END_REF]. We investigate the device characteristics in Third Generation Partnership Project (3GPP)-specific signaling at sub-minute granularity in §4.2. To the best of our knowledge this is the first work investigating device-specific 3GPP signaling at sub-minute granularity. In §4.3 we report about a device-specific network anomaly detected from the analysis of Domain Name System (DNS) traffic for different device categories and mobile OSs. Finally, we discuss lessons learned and derive guidelines for future work in §5.

Our findings collectively suggest that the extraction and analysis of device-specific traffic patterns becomes more and more important for dimensioning and troubleshooting mobile networks. Accordingly, novel methodologies to detect and mitigate undesirable device-specific traffic behavior are required in the near future.

Related Works

In order to enable a consistent taxonomy for describing heterogeneous mobile devices Gansemer et al. presented a scalable database approach for classifying devices, according to their features [START_REF] Gansemer | Database Classification of Mobile Devices[END_REF], into three categories: smartphones, mobile phones and Personal Digital Assistents (PDAs). While the focus of that work lies on enabling the selection of the optimal devices for development of specific mobile applications, we use our device categorization for studying their network-layer behavior. The authors in [START_REF] Granell | Smart devices fingerprint detection[END_REF] presented the classification of mobile devices by means of fingerprinting of their specific traffic behavior at the network and transport layer. To this purpose the authors deploy supervised machine learning techniques for processing passively monitored traffic features such as Time-To-Live or TCP congestion-window size. However, the experimental measurements presented in [START_REF] Granell | Smart devices fingerprint detection[END_REF] cover only a limited number of devices, while we characterize the traffic behavior of the entire population of mobile devices within an operational mobile network. Kumar et al. report about large spatio-temporal differences between smart-phones and laptops in [START_REF] Kumar | Changing patterns of mobile network (WLAN) usage: Smart-phones vs. laptops[END_REF]. Their study relies on MAC address-based device classification and has been conducted by means of large-scale trace analysis within a campus Wireless Local Area Network (WLAN). Our work includes also additional device categories and is based on characterizing the traffic behavior of a device population that is several orders of magnitudes larger than the one studied in [START_REF] Kumar | Changing patterns of mobile network (WLAN) usage: Smart-phones vs. laptops[END_REF].

The characterization of Machine-to-Machine (M2M) device-specific traffic behavior in operational cellular networks has been presented earlier in [START_REF] Shafiq | Large-Scale Measurement and Characterization of Cellular Machine-to-Machine Traffic[END_REF][START_REF] Marjamaa | A measurement-based analysis of machine-to-machine communications over a cellular network[END_REF][START_REF] Baer | MTRAC -Discovering M2M Devices in Cellular Networks from Coarse-grained Measurements[END_REF]. The work presented in [START_REF] Marjamaa | A measurement-based analysis of machine-to-machine communications over a cellular network[END_REF] includes the characterization of traffic volume behavior and radio per- formance of M2M devices. The authors in [START_REF] Shafiq | Large-Scale Measurement and Characterization of Cellular Machine-to-Machine Traffic[END_REF] study volume time series, session durations, mobility, applications and network performance of M2M devices. While our approach to device categorization is similar to these earlier studies, we do not limit ourselves to the characterization of M2M devices, but rather we encompass additional device categories such as tablets and USB modems. Additionally, we complement the studies presented in [START_REF] Shafiq | Large-Scale Measurement and Characterization of Cellular Machine-to-Machine Traffic[END_REF][START_REF] Marjamaa | A measurement-based analysis of machine-to-machine communications over a cellular network[END_REF][START_REF] Baer | MTRAC -Discovering M2M Devices in Cellular Networks from Coarse-grained Measurements[END_REF] by i) characterizing the traffic behavior of two different types of mobile operating systems, ii) studying the 3GPP-signaling protocol behavior and iii) investigating traffic behavior at shorter time-scales enabling us to characterize device synchronization at sub-minute granularity. Finally, we compare the traffic volume characteristics in the network under study with the characteristics presented in [START_REF] Shafiq | Large-Scale Measurement and Characterization of Cellular Machine-to-Machine Traffic[END_REF] and discuss observed similarities and differences.

Methodology

Traces were collected at the core network of a large scale European mobile operator. The results reported in the paper are based on several consecutive weeks of observation in the fourth quarter of 2013. The measurement setup is depicted in Fig. 1. Packetlevel traces are captured at the Gn links between the GGSN and SGSN -for details about 3G network structure please refer to [START_REF] Bannister | Convergence technologies for 3G networks: IP, UMTS, EGPRS and ATM[END_REF]. We analyze anonymized data captured by the METAWIN monitoring system developed in a previous research project [START_REF] Ricciato | Traffic monitoring and analysis in 3G networks: lessons learned from the METAWIN project[END_REF]. This monitoring system relies on Endace DAG cards [START_REF]Endace measurememt systems[END_REF], and packets are recorded with Global Positioning System (GPS)-synchronized timestamps offering an accuracy of ±100 ns. Our measurement setup enables the investigation not only of data traffic, but also of 3GPP-specific signaling traffic, e.g., mobile data sessions set-up and tear-down , that is PDP contexts in the terminology of 3GPP (see [START_REF][END_REF] for more details). Signaling information is exploited for associating an anonymized Mobile Device Identifier (MDID) and the observed device type to each monitored packet. This latter is achieved by extracting the Type Allocation Code (TAC) digits from the International Mobile Equipment Identity (IMEI), while the serial number digits of the IMEI are anonymized by means of an irreversible hash function. Additionally, anonymized traffic data is trans-formed into high-level records of e.g. aggregate IP flows or signaling events (ref. "Aggregation Process" in Fig. 1). Finally, the recorded measurements are forwarded within an extraction process (ref. Fig. 1) to DBStream [START_REF] Baer | Large-scale network traffic monitoring with DBStream, a system for rolling big data analysis[END_REF], a PostgreSQL-based parallel data processing system. In this paper, we use DBStream as our main analysis system. Note that all results presented in this work report normalized values to protect confidentiality of business-relevant information. Therefore, we cannot report the exact number of devices in our dataset, nor the number of devices per category.

Device Categorization

Studying device-specific traffic behavior relies on a proper categorization of the device types observed in the monitored traffic. To this purpose we follow the approach presented in [START_REF] Marjamaa | A measurement-based analysis of machine-to-machine communications over a cellular network[END_REF][START_REF] Shafiq | Large-Scale Measurement and Characterization of Cellular Machine-to-Machine Traffic[END_REF]. To determine the hardware model we started inspecting the device TAC codes and matching them with the publicly available GSM Association database [START_REF]GSMA IMEI Database[END_REF]. For categorizing M2M devices we adopt the base template scheme defined in [START_REF]AT&T specialty vertical devices[END_REF]. Then, similarly to [START_REF] Shafiq | Large-Scale Measurement and Characterization of Cellular Machine-to-Machine Traffic[END_REF] we used public information (e.g., production brochures, specification sheets) to manual supplement and verify this template. Furthermore, we distinguish the categories tablet, feature phone and smartphone. In particular, we label as feature phone all devices that are only capable of transferring data via 2G, i.e., General Packet Radio System (GPRS) or Enhanced General Packet Radio System (E-GPRS), while we consider smartphones all devices that are at least Third Generation (3G)-capable, i.e., support data transfer via Universal Mobile Telecommunications System (UMTS) or High Speed Packet Access (HSPA). We also distinguish between USB modems and modems. The first category includes devices connected via USB to PCs or Laptops, the latter refers to PCs or Laptops built-in modems. Finally, devices specifically designed for offering 3G-connectivity via local WLAN connections are labeled as router.

By relying on this approach we managed to label up to 96% of the devices observed within our study. As there is no standardized definition of M2M devices some might have multiple uses (e.g., PC built-in card and M2M device modem), thus the accuracy of our categorization is affected. In these cases, we adopted a conservative approach and we labeled as M2M, devices which were exclusively advertised as such by vendors.

Operating System Classification

In addition to previous works, our study includes the characterization of traffic behavior for two different types of mobile OS in §4.3. The different OS types have been derived from publicly available TAC information. For example, the TAC codes assigned to Apple devices can be associated to the iOS operating system, whereas TAC codes assigned to Nexus devices can be labeled as Android OS). While we are aware that such a manual labeling provides only moderate classification coverage, as shown in §4.3, it still enables us to study important OS specific traffic characteristics. For obtaining larger classification coverage, information from higher protocol layers would be requiredrefer to the earlier study presented in [START_REF] Granell | Smart devices fingerprint detection[END_REF] for an illustrative example.

Results

We start our study of device-specific traffic characteristics by analyzing aggregate traffic volume behavior for different types of devices.

Device-specific Characteristics at the Data Plane

As reported in [START_REF] Shafiq | Large-Scale Measurement and Characterization of Cellular Machine-to-Machine Traffic[END_REF] the introduction of new device types, as e.g., M2M devices, induce novel traffic usage patterns that may question current assumptions for optimization of network capacity. For instance, Shafiq et al. report that careful allocation of network resources is required due to uplink-heavy M2M devices contradicting optimization approaches relying on downlink asymmetry of network traffic [START_REF] Law | Capacity of Hybrid Cellular-Ad Hoc Data Networks[END_REF].

For investigation of this aspect in the network under study, we plot the ratio of uplink traffic volume to downlink traffic volume for different device categories over a period of 7 days in Fig. 2. We plot the ratio for the device category M2M and all other device categories separately. The latter categories are named according to their ranked share of the overall traffic volume during the observation period 1 . For enabling a comparison of our results with the findings presented in [START_REF] Shafiq | Large-Scale Measurement and Characterization of Cellular Machine-to-Machine Traffic[END_REF]Fig. 2c] we also plot the ratios after taking their logarithm, referred to as Z. Negative values of Z indicate larger volume in downlink than in uplink, while positive values of Z refer to larger uplink volume than downlink volume. In Fig. 2 we observe a clear separation of the distribution of M2M devices and all other devices. This is consistent with the finding presented in [2, Fig. 2c]. However, while Shafiq et al. report that ≈40% of smartphones have Z < -0.4 and ≈20% of smartphones have more uplink than downlink traffic (i.e. Z > 0), in our study we cannot identify any device category exhibiting the reported qualitative shape (compare Fig. 2 and [2, Fig. 2c]). Another dissimilarity to the work in [START_REF] Shafiq | Large-Scale Measurement and Characterization of Cellular Machine-to-Machine Traffic[END_REF] is observed in the volume share of M2M devices. While we observe Z ≤ 0 for almost 40% of M2M For further study of the device-specific data volume behavior, in Fig. 3 we plot data volume time series for different device categories, in time bins of 5 minutes, over a period of one week in the fourth quarter of 2013. We observe diurnal patterns for all time series of Fig. 3. In case of smartphones (ref. Fig. 3a) the daily peak volume is reached in the evening hours of each day. This represents a strong difference compared with the observation provided in [2, Fig. 3a] where the authors report a decrease of overall traffic volume for the evening hours. This might be explained by the different pricing models used in the two networks. In the case of [START_REF] Shafiq | Large-Scale Measurement and Characterization of Cellular Machine-to-Machine Traffic[END_REF] users may be encouraged by higher tariff models to switch from cellular connectivity to WLAN connections available in private homes.

The local volume peaks observed in Fig. 3a at noon during lunch time are a further deviation from the results presented in [START_REF] Shafiq | Large-Scale Measurement and Characterization of Cellular Machine-to-Machine Traffic[END_REF]. This specific characteristic is not visible for any other device type (ref. Fig. 3c and Fig. 3d). Our comparison with the work in [START_REF] Shafiq | Large-Scale Measurement and Characterization of Cellular Machine-to-Machine Traffic[END_REF] suggests that even conceptually simple metrics such as e.g., volume time series may exhibit significant dissimilarities for different networks. An aspect which should be specifically regarded when establishing generic traffic models based on observations derived from real networks.

From the time series of M2M devices (ref. Fig. 3b) we may establish following findings which are consistent with the results presented in [2, Fig. 3b]: i) there is a clear difference of the time series between working days and week days, ii) M2M devices are the only device types that show higher aggregate uplink volume than downlink volume, and iii) we observe distinct spikes in the traffic volume indicating the presence of M2M devices sending data traffic in a synchronized manner. The aspect of synchronized traffic patterns will be further addressed in the next section. Summarizing our investigation of traffic volume behavior, we may confirm earlier works reporting the presence of uplink-heavy, synchronized M2M terminals. However, we report distinct differences in the aggregate time series, specifically for the smartphone device category.

Device-specific Characteristics at the Signaling Plane

As reported in [START_REF] Laner | Traffic Models for Machine Type Communications[END_REF], 3G wireless networks are currently designed for traditional humantype communication rather than for synchronized, machine-type communication patterns as they may be triggered by M2M applications or mobile APPs relying on periodic transfers of data. Accordingly, it is highly desirable for mobile network operators to assess the effect of synchronized communication patterns onto available network capacity. This is specifically important since large increases of M2M-devices are expected until 2020. Such a perspective makes an evolution from high data rate networks to M2M-optimized low cost networks very appealing for network operators [START_REF] Laner | Traffic Models for Machine Type Communications[END_REF].

In this section we characterize the signaling behavior of different device classes. In In this section we characterize the signaling behavior of different device classes. In particular we focus on the PDP-context establishment procedure. Whenever a mobile client requires the establishment of a mobile data session, it is required to send a PDPcontext create request message (ref. to [START_REF] Bannister | Convergence technologies for 3G networks: IP, UMTS, EGPRS and ATM[END_REF] for more details).

Fig. 4 shows the Cumulative Distribution Function (CDF) of the number of Packet Data Protocol (PDP)-context create requests for the device class M2M and the two most popular device categories, computed over an aggregation period of 7 consecutive days 2 . We observe similar characteristics for M2M devices and the top category. While the second category converges quickly to 1, suggesting that the devices of this category are operated by means of lower amounts of PDP context create procedures. Moreover, we observe that the CDF of M2M devices converges slower to 1 than in case of other device types. This suggests that a small fraction of M2M devices relies on frequent session establishments, an aspect which we address further below. Fig. 5 depicts the overall time series of PDP-context create request messages over a period of one day. We observe a time-of-day variation in the PDP-context create request messages indicating more context establishments during day-time and less connection establishments during night hours. However, in addition to this daily cycle, we report distinct short-term spikes arising every full-hour and also smaller spikes occurring at a periodicity of 15 minutes.

For further investigation of these spikes in the connection establishment process, we plot the time series of PDP-context creates for different device classes over a period of two days in Fig. 6. Comparing Fig. 5 and Fig. 6 we discover that the reported peaks are triggered by different device classes. In particular M2M devices are responsible for the higher peaks (e.g. refer to the largest spike in the morning hours depicted in Fig. 6b).

Additionally, we observe that M2M devices exhibit their largest spikes during night hours indicating that a certain population of M2M devices relies on periodic session establishments during off-peak hours. It is interesting to note that also smartphones exhibit some sort of synchronized behavior recognizable by the first three prominent spikes persistently re-occurring in the morning hours (ref. Fig. 6a). By isolating these spikes for the different OS types derived from the publicly available TAC identifier, we find that those are caused by different types of mobile OSs. This suggests that specific types of OS may in fact exhibit different behavior in the context establishment process. For instance, the first two prominent spikes can be mapped to iOS-related TAC identifiers while the third peak can be associated to Android OS-specific TAC identifiers. The aspect of OS-specific signaling behavior will be further discussed in §4.3. Additionally, Fig. 6d shows distinct spikes every day at 04:00 for the device category of USB modems. This behavior may be triggered by an M2M-like application relying on periodic data transfers once a day. For further investigation of the synchronization level exhibited by the different device classes, we introduce the following indicator functions and sets.

Be e and E the generic device and the set it belongs, respectively. We denote by d = 1, 2, ..., 7 the days of the week, by m = 1, 2, ..., 1440 the minutes of the day, and by w = 1, 2, ...52 the weeks of the year. For each device, let define the function:

Θ e (m, d, w) def =    1 if e creates a PDP-context within minute m of day d on week w 0 otherwise (1)
For counting the number of days in the week the device e is creating a PDP-context, at minute m, we introduce the function:

Σ e (m, w) = 7 d=1 Θ e (m, d, w) (2)
For filtering on the devices active in more than τ days per week, we define the following indicator function:

Λ e (m, w) def = 1 if Σ e (m, w) > τ 0 otherwise (3)
The set of devices active at least τ days at the minute m of the week w, is defined as follows:

C m,w def = {e ∈ E : Λ e (m, w) = 1} (4)
In order to filter those devices that exhibit stable activity patterns across two consecutive weeks, we consider the sets P m,w obtained intersecting the C m,w with the conform set (i.e., the same minute) of the previous week:

P m,w = C m,w ∩ C m,w-1
(5) 0 0 :0 0 :0 0 0 3 :0 0 :0 0 0 6 :0 0 :0 0 0 9 :0 0 :0 0 1 2 :0 0 :0 0 1 5 :0 0 :0 0 1 8 :0 0 :0 0 7a depicts graphical representation of the cardinality of the sets P m,42 for the different minutes at week 42. From this plot we notice that M2M and smartphones exhibit similar behavior since both the classes tend to be synchronized with the full hour, and partially synchronized also at a periodicity of 30 and 15 minutes. We found that more than 20% of M2M devices exhibit this behavior while the share of smartphones is around 1%. In Fig 7b we report a zoom on 4 hours of Fig. 7a. We observe that the variation around the spikes is larger for smartphones compared to the case of M2M devices. This suggests that smartphones are synchronized at a coarser level, while M2M devices are tightly synchronized in time. This tight time-synchronization is highly undesirable for mobile operators, since it requires allocation of large network resources when the network is dimensioned to keep up with capacity demands during traffic peaks. Consequently, the expected future increase of M2M devices [START_REF] Laner | Traffic Models for Machine Type Communications[END_REF] suggests that a continuous monitoring of M2M-triggered communication patterns is needed, such that adequate countermeasures can be timely enforced (e.g., de-synchronization of M2M devices).

Investigation of a device-specific anomaly

In this section we report about a large-scale network anomaly detected while studying the characteristics of the Domain Name System (DNS) traffic generated by each device category and for different OS.

Since the vast majority of Internet applications rely on the proper functionality of the DNS, ensuring the availability and performance of DNS servers is an essential task for operators of mobile networks. Due to the emerging of synchronized traffic behavior, as e.g., shown in §4.2, it is important to know whether a large device population queries the operator's DNS servers in a highly synchronized manner, potentially impairing DNS servers performance. To this purpose, in Fig. 8 we plot the time series of DNS queries for different device categories, over a period of two days, aggregated in time bins of 1 minute. In Fig. 8b we observe that M2M devices trigger several timesynchronized peaks in the DNS query count across both days, showing the largest peaks around midnight. Further manual investigation of the spikes depicted Fig. 8b showed that these spikes are deterministic and re-occur every day at the same time of day. Since network capacity is typically dimensioned in a peak-oriented manner, the presence of short-term peaks results in higher capacity demands and wastage of resources in non-peak intervals. Both aspects are highly undesirable at the network dimension-0 0 :0 0 :0 0 0 4 :0 0 :0 0 0 8 :0 0 :0 0 1 2 :0 0 :0 0 1 6 :0 0 :0 0 2 0 :0 0 :0 0 0 0 :0 0 :0 0 0 4 :0 0 :0 0 0 8 :0 0 :0 0 1 2 :0 0 :0 0 1 6 :0 0 :0 0 2 0 :0 0 :0 0 0 0 :0 0 :0 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 # DNS Query (rescaled)

(a) Smartphone 0 0 :0 0 :0 0 0 4 :0 0 :0 0 0 8 :0 0 :0 0 1 2 :0 0 :0 0 1 6 :0 0 :0 0 2 0 :0 0 :0 0 0 0 :0 0 :0 0 0 4 :0 0 :0 0 0 8 :0 0 :0 0 1 2 :0 0 :0 0 1 6 :0 0 :0 0 2 0 :0 0 :0 0 0 0 :0 0 :0 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 # DNS Query (rescaled) (b) M2M 0 0 :0 0 :0 0 0 4 :0 0 :0 0 0 8 :0 0 :0 0 1 2 :0 0 :0 0 1 6 :0 0 :0 0 2 0 :0 0 :0 0 0 0 :0 0 :0 0 0 4 :0 0 :0 0 0 8 :0 0 :0 0 1 2 :0 0 :0 0 1 6 :0 0 :0 0 2 0 :0 0 :0 0 0 0 :0 0 :0 0 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 # DNS Query (rescaled)

(c) Tablet 0 0 :0 0 :0 0 0 4 :0 0 :0 0 0 8 :0 0 :0 0 1 2 :0 0 :0 0 1 6 :0 0 :0 0 2 0 :0 0 :0 0 0 0 :0 0 :0 0 0 4 :0 0 :0 0 0 8 :0 0 :0 0 1 2 :0 0 :0 0 1 6 :0 0 :0 0 2 0 :0 0 :0 0 0 0 :0 0 :0 0 ing stage. Our observation suggests the need for deploying randomization strategies for de-synchronization of network traffic in order to optimize network dimensioning.

The expected large increase of (synchronized) M2M devices by 2020 [START_REF] Laner | Traffic Models for Machine Type Communications[END_REF] urges for the adoption of such mitigation strategies in the near future. However, in Fig. 8 we observe that not only M2M devices, but also smartphones and tablets exhibit synchronized peaks in the DNS query counts. For instance, we report smaller spikes throughout the whole day and larger, persistent spikes in the night hours every day (ref. Fig. 8a and Fig. 8c). Interestingly, Fig. 8 shows a sudden and large increase of DNS queries in the morning hours of the second day. This clear anomaly only affects smartphones and tablets, but no other device types (ref. e.g., USB modem in Fig. 8). For further investigation of the anomaly, we plot the time series of DNS query counts separately for TAC identifiers related to Android OS and iOS (recall §3) in Fig. 9. From this figure we observe that only iOS-based devices are affected by the anomaly. This confirms that the misbehavior of a large population of a certain device type may in fact trigger macroscopic, networkwide anomalies. As mobile devices nowadays rely on frequent updates of mobile apps and operating systems, it cannot be excluded that novel device-specific (mis-)behavior are induced by such software updates over time. Accordingly, the assessment whether software-updates result in new device-specific traffic characteristics or even might induce novel network anomalies, requires continuous monitoring of device-specific behavior across different types of devices and OSs. Hence, we consider the the analysis of device-specific traffic behavior a moving target.

We further investigate the iOS-based anomaly depicted in Fig. 9 as follows. Our monitoring system allows for the extraction of IP-level flow counters aggregated in time bins of 1 minute. That is, in each time bin traffic volumes (i.e., IP packets transferred in uplink and in downlink) are aggregated per flow, where a flow is identified by the anonymized MDID, destination IP address, source port and destination port. These flow aggregates enable the analysis of three different flow types: flows where traffic has 0 0 :0 0 :0 0 0 4 :0 0 :0 0 0 8 :0 0 :0 0 1 2 :0 0 :0 0 1 6 :0 0 :0 0 2 0 :0 0 :0 0 0 0 :0 0 :0 0 0 4 :0 0 :0 0 0 8 :0 0 :0 0 1 2 :0 0 :0 0 1 6 :0 0 :0 0 2 0 :0 0 :0 0 0 0 :0 0 :0 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 # DNS Query (rescaled)

(a) Android 0 0 :0 0 :0 0 0 4 :0 0 :0 0 0 8 :0 0 :0 0 1 2 :0 0 :0 0 1 6 :0 0 :0 0 2 0 :0 0 :0 0 0 0 :0 0 :0 0 0 4 :0 0 :0 0 0 8 :0 0 :0 0 1 2 :0 0 :0 0 1 6 :0 0 :0 0 2 0 :0 0 :0 0 0 0 :0 0 :0 0 been transferred exclusively in uplink, i.e., data has been sent from the mobile devices towards the Internet. Such flows are referred to as "uplink-only" flows. Conversely, "downlink-only" refers to flows where traffic has been transferred only from servers in the Internet towards mobile devices, and "two-way" flows refer to the case where traffic volume has been transferred in both directions. As mentioned in [START_REF] Glatz | Classifying Internet one-way traffic[END_REF] one-way traffic is caused by different sources, such as scanning, peer-to-peer applications, back-scatter and unreachable services. As noticed in [START_REF] Glatz | Classifying Internet one-way traffic[END_REF] the latter type is particularly helpful for large scale monitoring of network and service outages.

In Fig. 10 we plot the (rescaled) number of different flow types versus time during the interval of the iOS-based anomaly. Fig. 10a depicts the flows involving servers located in the anomalous IP range, while Fig. 10b shows flows involving the residual server IP addresses. In order to enable direct comparison both figures have been rescaled by the same undisclosed factor. In Fig 10b we observe that all flow types are rather stable over time. The number of two-way flows shows two slight bumps during the anomaly, which are likely caused by the anomalous increase of DNS queries that has been presented in Fig. 9b. In contrast, we observe two distinct bumps for all flows of the anomalous IP range in Fig. 10a. The majority of these flows is unanswered by the destined servers within the same time bin, resulting in two bumps of uplink-only flows (indicated by the solid line). This finding and the fact that we observe a simultaneous increase of uplink DNS queries, suggest that the anomaly is induced by a large set of iOS-based devices issuing connection requests in uplink (e.g., by sending TCP SYN packets). While we find that still some of the flows are answered by the servers (see "two-way" flows in Fig. 10a), we also report two bumps for the class of downlink-only flows. Such downlink-only flows may be present if connection requests in uplink are answered late (e.g. by TCP reset packets) such that the downlink packet is counted in one of the subsequent time bins after the corresponding uplink flow. The pattern shown in Fig. 10a suggests that the servers located in the anomalous IP range suffered from temporary faults leading to a large number of unanswered and rejected client connection requests. In fact the mobile devices reacted upon these unsuccessful connection requests by triggering even more uplink-only flows (indicated by the persistently increasing height of the bumps in Fig. 10a). Such a behavior is highly unwanted, since the scheduling mechanisms in the Radio Access Network (RAN) typically rely on assigning higher bandwidth to devices exceeding certain traffic rate thresholds [START_REF] Laner | A comparison between one-way delays in operating HSPA and LTE networks[END_REF]. As a result of this scheduling strategy, anomalies like the reported one may lead to large bandwidth demands for sending unsuccessful connection requests and, hence, to a significant wastage of network resources in the RAN. Since RAN resources are allocated in a shared manner, such incidents may even impair the network performance of those devices not directly involved into an anomaly.

Our findings suggest that new methodologies are required for detecting and mitigating device-specific anomalies. Current protection mechanisms, such as e.g., IP firewalls or intrusion prevention systems, are mainly designed for mitigating anomalies and attacks originating from external sources located in the Internet. Accordingly, such protection infrastructure is placed towards the edge of the core network between the Gateway GPRS Support Node (GGSN) and the Internet (ref. Fig 1). However, methodologies for efficiently mitigating device-triggered anomalies should be enforced in the RAN section close to the mobile devices, in order to avoid the propagation of anomalies and their negative effects towards the core network. Furthermore, our study illustrates how root causes of anomalies can be efficiently carried out by relying on deviceand OS-specific traffic characteristics. Further work along this direction has been documented in [START_REF] Schiavone | Diagnosing Device-Specific Anomalies in Cellular Networks[END_REF]. There, we provide guidelines for designing an automatic diagnosis system for network anomalies, which relies on entropy metrics calculated from devicespecific traffic features.

Conclusions and Future Work

In this paper we present a device-specific view on the traffic within an operational cellular network, taking into account both, data plane and signaling plane traffic. By discussing previous works on traffic characterization in mobile networks we show that comparing data sets collected from different networks is not trivial, since even simple metrics such as, e.g., traffic volume time series, may exhibit significantly different patterns across different networks. This is specifically critical in case generic traffic models are derived from network-specific traffic behavior.

Moreover, we report the presence of time-synchronized peaks at different protocol layers (e.g., DNS and PDP-context create) and at different time of the day. In particular we find that such spikes are not only triggered by synchronized M2M devices, but are also observed in other device categories (e.g., smartphones, tables and USB modems). This finding suggests that de-synchronization of mobile devices for mitigating the negative effects of synchronized traffic peaks should not only be carried out for M2M devices, but also for all the other device classes.

Finally, we also report about a device-specific network anomaly detected from the analysis of DNS traffic. Analyzing this anomaly we show that device-specific traffic characterization supports investigation of device-induced network anomalies, and the identification of their root causes.

Fig. 1 :

 1 Fig. 1: Monitoring infrastructure and measurement setup.

Fig. 2 :

 2 Fig. 2: CDF of ratio log(Uplink/Downlink), 7 day aggregate.

Fig. 3 :

 3 Fig. 3: Downlink and uplink traffic volume time series, time bins of 5 minutes.

Fig. 4 :

 4 Fig. 4: CDF of number of PDP-context create, different categories, 7 days (rescaled).

Fig. 5 :Fig. 6 :

 56 Fig. 5: Time series of PDP-context creates, 1 day, time bins of 10 sec.

Fig. 7 :

 7 Fig. 7: Cardinality of P m,42 , different zoom levels.

Fig. 8 :

 8 Fig. 8: Time series of DNS requests per device category, 2 days, time bins of 1 minute.

Fig. 9 :

 9 Fig. 9: Time series of DNS requests per operating system, 2 days, time bins of 1 minute.

  Residual IP range.

Fig. 10 :

 10 Fig. 10: Time series of flow types during observed anomaly, 1 min. time bins (rescaled).

In order to obfuscate business-sensitive information the specific category labels have been substituted by their rank.

In order to obfuscate business-sensitive information the specific category labels have been again substituted by their rank according to the overall volume during the observation period.

Acknowledgments

This work has been performed in the framework of the EU-IP project mPlane, funded by the European Commission under the grant 318627.