Facing the Apple Watch with Traffic Monitor


This year on the 24th of April Apple released its first wearable: the Apple Watch. This new device within the Apple universe opens up a completely new category of devices and may change the way how we communicate and interact with mobile devices.

We at RadioOpt in Dresden took the chance to explore the possibilities on this exciting new platform aiming to bring the users a new experience of Traffic Monitor on their wrist. In this post, we want to share our first experiences with the Watch and provide you some insights in the deployment process.


First Steps

We started our Watch journey by exploring the early adopted apps on the platform and to study the Human Interface Guidelines given by Apple. These include assistance on components, structure and interaction.

With all this information, we began developing a small app: the Battery Monitor App. The use case for this app is straightforward: display the current battery status of your iPhone on the watch to have this little piece of information always available without checking on the iPhone directly. For this sample app, a one-screener is absolutely sufficient. Moreover, we designed battery icon and charging icon which then represent the different charging states.

If you’re interested in the result you can give it a try and download it in the Apple AppStore (LINK).



Traffic Monitor offers Apple Watch App

With the experiences gathered during the development of the Battery Monitor App, we continued our journey towards the Traffic Monitor Apple Watch App.

As a first step, we were discussing about the most relevant information to be displayed to the user and how we present it. Here, we used the previously developed today extension for the iPhone notification center as a foundation for the watch as it also shows this kind of information.

We targeted to have a glance screen for quick data usage information lookup and a Watch App with more detailed information about the current usage and iPhone status information.

The glance screen of the watch is displayed when sliding up on the watch face screen. It contains information about the current type of the data network and its name as well as the data usage in mobile and Wi-Fi.

The Watch App extends the glance screen by showing more detailed information on multiple separate pages. This lead to the following app structure:

  • Cellular usage with daily, monthly breakdown
  • Wi-Fi usage with daily, monthly breakdown
  • iPhone statistics, i.e., battery status, capacity, uptime of your iPhone

With the provided information the Watch App user is always able to quickly access his current data usage via glance or watch app. This interaction is much quicker than getting your phone out of the pocket, unlock the screen and open up the Traffic Monitor.

During the development of the Watch App we faced multiple challenges. At first, the small form factor of the Watch which is either 35mm squared or 42mm squared. Hence, the user interface has to be well designed to provide the relevant information in an appropriate way. Moreover, in the current version of the SDK (Software Development Kit) provided by Apple all the work has to be done on the phone while the Watch only works as a secondary display. This also applies to graphics and animations. Hence, they have to be pre-rendered on the Mac or generated dynamically on the phone, and then transferred to the watch via the Bluetooth interface. This ultimately limits the opportunities of the Watch App, i.e., displaying real-time data is not possible.

Talking about the communication link via Bluetooth, it is not as performant as we thought. More precisely, the data rates are low and it introduces a significant delay. This is sometimes hindering the user interaction and user experience. As an example an update in a navigation app is always 1 – 2 seconds delayed. Moreover, there is no status information about the Watch itself available at the moment, but it will be introduced in WatchOS 2.x.

All these limitations have led to tradeoffs we had to do during development. Limited space forces information to be cut down into small pieces – this was only some brain work and did not appear as a major obstacle. Animations were pre-rendered on the iPhone and then stored on the Watch. This can be a problem if the animations are very detailed or you have many different as they consume very much space and thus increase the app size on the Watch significantly.

The implementation on the Watch is easy and straightforward, but the deployment on the Apple AppStore has many small stumbling blocks, e.g., setting up multiple provisioning profiles.

If you are interested in the final app, feel free to download the Traffic Monitor including the Apple Watch extension on the Apple AppStore.



Authors: Anton Augsburg / Björn Almeroth

Determine the environment of smartphones by an indoor / outdoor classifier

For mobile network analysis it is often desirable to classify some measurements to an indoor or outdoor environment. For example to determine the quality of service for voice calls in conjunction with the coverage it is very helpful to take the indoor/outdoor scenario into consideration. Furthermore for planning the network capacity it is interesting to take a look at the distribution of the data traffic, which could be mainly indoor or outdoor, depending on the season and the time of day.

The mobile devices – our mobile measuring instruments – offer the necessary kinds of sensors to do such a classification. The classification algorithm consists of a decision tree that evaluates the indoor / outdoor state based on a wide variety of environment information from the device. In this post we will focus on the impact of the light sensor to determine the most likely state (indoor vs. outdoor) based on a probabilistic model.

On the following chart, you can see the probability density function by using the light sensor for the classification process. How you can see, this sensor information can contribute to an indoor/outdoor decision. But note that this procedure is only practicable for hours with daylight. Also in daylight, a certain range of light sensor values is not usable for the classification, because of the difference in the probabilities, which is not significant enough to make a reliable decision.



The results of the indoor/outdoor classification taking all the different information sources into account can be evaluated in a typical day curve as shown in the following figure. Depending on the time of the day and season the outdoor probability is between 1% in night hours in winter and nearly 16% in daylight hours in summer.

Blog_IOD_Day_Curve_Outdoor_Germany_SouthAfricaFurthermore the distinction of the indoor/outdoor state for some interesting KPIs like the speedtest transfer rate (download) or the average of the signal strength in voice calls is possible. How expected in the outdoor case the average of the transfer rate and signal strength is much better for mobile networks.