AAMPL: Accelerometer Augmented Mobile PhoneLocalization

Andrew Ofstad Emmett Nicholas Rick Szcodronski Romit Roy ChoudhuryDept. of Electrical and Computer Engineering

Duke University{andrew.ofstad, emmett.nicholas, ras18, romit}@ee.duke.edu

ABSTRACTA variety of mobile phone applications are on the rise, manyof which utilize physical location to express the context ofinformation. This paper argues that physical location alone,unless remarkably precise, may not be sufficient to expressthis context. Even slight localization errors may cause amobile phone to be placed in a grocery store, as opposed toits actual location in an adjacent coffee shop. Applicationssuch as location specific advertisements, can get affected.This paper proposes accelerometer augmented mobile phonelocalization (AAMPL), a system that uses accelerometer sig-natures to place mobile phones in the right context. Earlyevaluation on Nokia N95 phones shows that AAMPL cancorrect locations derived from Google Maps. We believethat AAMPL can be extended to additional sensors (likelight and sound) to further aid GPS-free localization.

Categories and Subject DescriptorsC.3 [Special-Purpose and Application-Based Systems]:Real-time and embedded systems; C.2.4 [Computer Com-munication Networks]: Network Protocols

General TermsDesign, Experimentation, Measurement, Human Factors

KeywordsMobile phones, accelerometers, localization, energy, sensing

1. INTRODUCTIONThe proliferation of mobile phones is motivating a va-

riety of pervasive, context-aware, social applications. Ex-amples include Micro-Blog [1], MetroSense [2], Place-Its [3],PeopleNet [4], MyExperience [5], and several others. Manyof these applications exploit the location of the user as aprimary indicator of context. While most applications as-sume GPS based localization, recent investigations are be-ginning to expose several tradeoffs when using GPS. Poor

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.MELT’08, September 19, 2008, San Francisco, California, USA.Copyright 2008 ACM 978-1-60558-189-7/08/09 ...$5.00.

indoor coverage with GPS, alongside its high energy con-sumption [1], warrants alternate localization methods. Somealternates, proposed by Place Lab and others [6, 7], utilizeWiFi/GSM based fingerprinting and triangulation to local-ize mobile phones. While the improvements in coverage andenergy are encouraging, they arise at the expense of higherlocalization error ranging from 50 to 500m. Such error mar-gins may exceed the tolerance thresholds of several appli-cations. More importantly, even if these error bounds arereduced to a few meters, they may still be insufficient tocapture the user’s context. We present our argument next.

Consider an example application – Micro-Blog [1]. Onefeature of Micro-Blog is that location-specific queries aregeocast to mobile phones present at the corresponding lo-cation. For example, an Internet user may query about the“availability of free WiFi” at a particular coffee shop. Ifthis query reaches phones in the adjacent grocery store, thereplies to this query may be inapplicable. Existing localiza-tion schemes, even with accuracy of few meters, may notbe able to avoid this. The physical separation between twophones may be small (few meters), and yet they may be inlogically different contexts (opposite sides of the wall sep-arating the coffee shop and the grocery store). We arguethat localization needs to be performed across two domains,namely physical and logical. This paper presents a frame-work, AAMPL, that accepts the approximate physical loca-tion of a mobile phone, and augments it with context-awarelogical localization. The main idea is described as follows.

Modern phones are equipped with a large number of sen-sors, including cameras, microphones, accelerometers, andhealth-monitors. These sensors are natural candidates forsensing the context in which a user is situated. Automaticaccess to such context information can be exploited towardslocalization. For instance, a user’s movement (derived fromthe phone’s accelerometer) may be effective for predictingwhether the user is in a coffee shop or a grocery store. Sincegeographical localization can narrow down the choices to afew nearby contexts, accelerometer readings may be effectivein selecting the correct one from among them. Hence, the“WiFi availability” query can be correctly guided to phonesin the appropriate coffee shop. While classifying accelerome-ter signatures is one axis of augmentation, one may envisagemulti-dimensional context sensing through light and noisesignatures. This paper develops a framework for combiningphysical and logical localization via real-time classificationof accelerometer readings. Evaluation on Nokia N95 phonesshows that AAMPL was able to correct physical locationsderived from phone GPS and Google Maps.

2. RELATED WORKWe divide the related work into two following branches:

Activity Recognition: Several papers have studied ac-tivity recognition using accelerometers. Bao and Intille showedthat it is possible to detect 9 everyday activities using 2biaxial accelerometers mounted on a user [8]. Other re-search has investigated augmenting accelerometer data withon-body audio sensors to detect recurring human behaviors[9]. Project SATIRE [10] extends these results by imple-menting a sensor mote based architecture that takes advan-tage of recognizable accelerometer signatures. The authorsattempt to develop accelerometer-equipped smart clothesthat could trigger alerts or record daily activities. Severalprojects have explored applications of context-aware mobiledevices [11, 12, 13]. Project SenSay [14] aims to providea context-aware phone that adapts its state based on theenvironmental and physiological changes. It uses externallymounted light, motion, and sound sensors to provide thecontextual information. Inspired by these findings, AAMPLleverages accelerometer signatures towards augmenting lo-calization. Readings from the on-board accelerometer of amobile phone are transmitted over WiFi/GSM connectionsto a central server, which then localizes the phone in realtime. The architecture is made energy-aware, permittingAAMPL to be a deployable underlay to next generation ap-plications.

Localization: With increasing location based applica-tions for mobile phones, localization has been an excitingtopic of research. Since GPS is energy-hungry and has pooraccuracy in indoor and dense urban areas, other localiza-tion techniques have been explored [6, 7]. Augmenting GPSwith WiFi and/or GSM data has been shown to aid in lo-calization. Also, external sensors can aid in placing a userin a specific location [12]. The advantage of AAMPL is thatit unifies GPS based localization with other sensory inputs(accelerometer in the case of our implementation). WhileGPS offers an approximate location, an accelerometer basedclassifier effectively discriminates between possible logicallocations. We present the design, implementation, and theevaluation of the system, next.

3. ARCHITECTURE AND DESIGNFigure 1 presents the client-server architecture of AAMPL.

Without loss of generality, we describe AAMPL for localiz-ing phones located in urban business areas (shops, stores,malls). However, AAMPL may be equally effective in manynon-business indoor environments, such as homes, schools,or workplaces.

3.1 Client-Server ArchitectureThe AAMPL client runs on a Nokia N95 smartphone, and

uses a 3G or WiFi Internet connection to communicate tothe server. The client and server operate in conjunction tofirst classify the type of business a user is in, based on ac-celerometer data. The server then uses this classification tochoose from a list of businesses near the phone’s physicallocation. The main operations are as follows.

The client collects X, Y, and Z-axis accelerometer dataat one second intervals. These data points are logged inmemory over the duration of a minute, and are then passed

Figure 1: Block diagram of the AAMPL architecture

through a filtering layer that classifies each accelerometerdata point into an “action state”, which, in our implemen-tation, is either “sitting” or “standing”. This classified ac-celerometer data is then aggregated into three features thatcan be used at the server to classify a location (details pre-sented later). The aggregated features are included in a datapacket, along with a timestamp and the physical coordinatesderived from GPS, WiFi, or GSM. The data packet is sentto the server via an HTTP POST request.The server is mainly responsible for classifying the accelerom-eter data, and using the results to refine the physical locationof the device. Logically, the server application is divided intothree different components: (1) A MySQL database storesbusiness and mobile activity information, keeping an up-dated list of nearby businesses and client data logs. (2) Aclassifier is responsible for classifying the business categorybased on a set of recent points in the “logs” database. (3)A controller coordinates events across the different compo-nents, and communicates to the mobile client when neces-sary. When a packet first arrives, it is added to the“logs” ta-ble, which contains a list of recent accelerometer data pointsand location coordinates, provided by the mobile client. Theserver dynamically queries Google Maps for an updated listof businesses near these location coordinates. The controllerthen examines the database to determine whether the lat-est accelerometer data point is within a “span,” which isa sequence of data points with close spatial and temporalproximity to one another. The new data point is appendedto the most recent span if appropriate. If not, a new spanis created. Note that it is assumed that all the points in asingle span come from the same business location. The con-troller then sends all the points from the latest span to theclassifier, which uses the accelerometer features to classifythe business category of the entire span. The controller canthen use this classification to filter out the nearby businessesin the database, only returning businesses in the given cate-gory. The filtering module also uses other relevant pieces ofinformation to filter out unlikely businesses. For example,business hours, stored in the“businesses”database table, areused to filter out locations that are not open. This list isreturned to the phone and displayed on the screen.

3.2 Energy AwarenessSending a single bit of information through a wireless

medium (Wi-Fi or GPRS) uses the same amount of poweras 800 clock cycles of processing [15]. Thus, it is importantto limit the amount of data sent back to the server for clas-sification. These considerations motivate the need for dataaggregation at the client side. In AAMPL, the accelerometerclassifier is set up such that 60 128-bit accelerometer datapoints (960 bytes in total) can be aggregated into 24 bytesthat provide most of the information necessary for businessclassification. An improvement factor of 40 is immediate,substantially reducing the energy costs.

3.3 Classifier DesignThe classification system is responsible for classifying ac-

celerometer data from a span (where each span correspondsto a business category). In the current implementation, wedecided to classify each span as belonging to one of threeclasses: restaurant, fast food, or retail store. This classifica-tion system required the collection and analysis of a trainingdataset. So, an accelerometer data-logging application wasprogrammed for the N95 that collected samples from the 3-axis accelerometer every second. (Each accelerometer datapoint contains raw signed acceleration integers for each ofthe X, Y, and Z axes, with a conversion rate of decimal64 to1g of acceleration.) Data was collected from 16 locations inthe Raleigh/Durham metropolitan area. For each business,logging began upon entering the business, and was stoppedupon exit. The phone was placed in the right pocket ofa pair of jeans. In addition to business-specific data collec-tion, measurements were taken for two different action statesthat are used in the classification. About 1000 data points(spanning 1000 seconds) were collected while standing (i.e.walking around and standing still) and sitting. The phonewas placed in the pocket in a variety of different angles andconfigurations, although each time it was approximately up-right in the pocket with the screen facing outward. Whencollecting standing data, the tester stood and walked witha variety of different gaits. Figure 2 shows this trainingdata. These two states, as can be seen from the data, ap-pear as distinct, separable distributions. Training data fromthe three business categories also had interesting distribu-tions with distinguishable patterns (Figure 3).

The classifier design was faced with a energy versus com-plexity tradeoff. While classifying patterns in different busi-ness distributions demand high computation cost (favoringserver side classification), reducing the energy cost of datatransmission favors classification at the phone client. In viewof this, AAMPL adopts a two stage classifier, with the firststage occurring on the phone and the second on the server.In the first stage, each accelerometer data point is classi-fied as either sitting or standing, using a Bayesian classifier.The classified data allows for the extraction of three aggre-gate features that can be used in the second stage of businesscategory classification. The first feature is the percentage ofpoints that are in the standing state, the second is the av-erage variance over all three axes for points in the standingstate, and the third is the total number of points taken fromthe business, which translates directly to the amount of timein seconds. These aggregate data features describe the datain a concise manner, and provide most of the informationneeded to make a classification. For each such classifica-

Figure 2: X-Y-Z accelerometer training data forstanding (black) and sitting (red)

tion, only a small amount of meta-data needs to be sentto the server. The server, which keeps a database of busi-ness category training points, then performs a multi-class,three-dimensional classification on the test point. This sec-ond stage of classification is done with a k-nearest neighbors(KNN) classifier. Figure 4 shows a flow chart of this com-plete classification scheme. A Bayesian classifier was usedfor the first stage. Once a class conditional probability dis-tribution function is created, the Bayesian classifier runs inlinear time for a set of data points. In addition, the Bayesianclassifier is easily extended to multi-class, multidimensionalclassifications with little additional computation complexity.

Figure 4: Business classification flow chart

For the Bayesian classifier, it was assumed that the priordistributions of sitting and standing are equal (P (ωi) = .5).The classification then degenerates to a simple comparisonbetween the two class conditional probabilities for sitting(Eqn. 1) and standing (Eqn. 2):

IfP (x|ωsitting)

P (x|ωstanding)> 1, then choose sitting (1)

IfP (x|ωsitting)

P (x|ωstanding)< 1, then choose standing (2)

To obtain the above class conditional probabilities, non-

Figure 3: X-Y-Z accelerometer measurements in (a) restaurant, (b) fast food joint, and (c) retail store

parametric kernel density estimation (KDE) was used witha Gaussian window function on the training set in Figure2. 50x50x50 three dimensional class conditional probabili-ties for sitting and walking were saved as text files for useas Bayesian classifier lookup matrices on the phone. Afterevery point in a dataset is classified as sitting or standing,the percent sitting, number of points, and variance featuresare calculated with the aggregator. The variance of stand-ing points is approximated by the average of the X, Y, andZ axes variances. The second stage classifier is responsiblefor taking an aggregate feature point, as produced by thefirst stage classifier and aggregator, and classifying it into asingle business category. While this classification lends itselfto a number of different multi-class classification techniques,the small data set limited the effectiveness of more compli-cated methods. For this reason, a relatively simple KNNclassifier was chosen for this stage. The training set for thisclassifier can be seen below in Figure 5. This training setwas classified and aggregated using the first stage classifierdescribed above. The set is first normalized such that allthe dimensions ∈ [0,1].

Figure 5: Business classification training data forrestaurants, fast food, and retail stores.

While our dataset is very limited, one could imagine alarger dataset that occupies this feature space more com-pletely. This larger training set could be used for any num-ber of advanced classification techniques that are trained tominimum validation error, and these techniques could beimplemented on the server without having to change any-thing on the mobile phone client. However, for this partic-ular application with such a small dataset, a KNN classifierwas sufficient. If a larger training dataset or more featuresbecomes available, this information could be easily incorpo-rated to enhance the accuracy of the classifier.

4. SYSTEM IMPLEMENTATIONThe AAMPL phone client was implemented on the Nokia

N95 smartphone in approximately 3300 lines of code usingthe Carbide C++ IDE and compiler for Symbian OS. Theserver side was implemented in approximately 1650 lines ofcode across PHP, Perl, and MySQL. The implementationdetails are presented in the next two sections.

Phone Client: The Nokia N95 smartphone, currentlythe flagship of the Nokia product-line, runs on the S60 3rdEdition platform, using Symbian OS v9.2. The AAMPLsoftware requires access to the phone’s location and networkservices, which are provided by the S60 SDK. We obtainedan Open Signed Online certificate, to be used for develop-ment purposes only, from the Symbian Signed website [16].

Web Infrastructure: We installed a lighttpd 1.4.18 serverto offer HTTP access to the client, as well as to interface withthe back-end MySQL database server. Relevant installationson the server include PHP 5.2.4, Perl 5.8.8, and MySQL5.0.24a. Logs, sent from the client every minute via POSTrequests, are received by the server and communicated tothe database server through PHP. After each log is addedto the database, the entire collection of logs is analyzed us-ing PHP and Perl scripts. More specifically, Perl is used forthe two classifiers, and all other server-side logic is imple-mented in PHP. After a request is received and processedby the server, a response is sent to the query-originator (theAAMPL phone client). For testing purposes, the responsecontains a list of possible businesses, ordered by likelihood,in which the client is currently located.

5. EVALUATIONWe report early evaluation of AAMPL from a set of lo-

cal businesses in the Duke University campus. We compareAAMPL to a GPS-only approach, in which the client is as-sumed to be in the business geographically nearest to themost recent GPS measurement. The metric for success isbusiness prediction accuracy.

Classifier Evaluation: Overall, AAMPL serves its spe-cific purpose well. The first stage classifier was tested forits ability to classify whether each accelerometer point wasfrom the standing or sitting state. A 50-50 cross-validationwas used for this, i.e., half of the dataset was randomlyselected as training data, leaving aside the other half astest data. This validation produced classifications that werecorrect 98.9% of the time. While this classifier was not

tested with data from outside the training set, our inspec-tion/verification of the classified training data gives us confi-dence that the accelerometer will be able to well discriminatesitting from standing. Further, these results help to validateour decision to use a Bayesian classifier instead of a HiddenMarkov Model for this stage of classification. The next stageof classification also produced encouraging results. Leave-one-out validation was used to train and test the classifierwith the data collected. Each business was taken out of thetraining set, and then classified with the remaining data inthe set. Each business was classified correctly using a sim-ple nearest neighbor classification (KNN with k = 1). Ofcourse, if the dataset grew larger, this would probably notbe the case – k would need to be increased or another clas-sification method would need to be employed.

Experimental Setup: The back-end“businesses”databasecontains geographic information for 25 businesses near theNinth Street business district in Durham, NC. Figure 6shows the stretch of Ninth Street on which we conductedpart of our experiments. The (red) pushpins correspond tothe actual locations of three adjacent businesses: RegulatorBookshop, Blue Corn Cafe, and Bean Traders Coffee. The(blue) balloons correspond to the positions of each businessas reported by the Google Maps API. The Google-reportedphysical coordinates are moderately accurate, but the log-ical discrepancies with the actual businesses can be signif-icant. For example, the location of Regulator Bookshop isreported as in front of the Blue Corn Cafe. We carried theAAMPL-equipped phone in our trouser pockets and spentvaried amounts of time in or around the three locations.Since the businesses were of different types (store, restau-rant, and fast food, respectively), the accelerometer signa-ture provided useful information for localization.

Figure 6: Google satellite view of Regulator store,Blue Corn restaurant, and Bean Traders fast food.Coordinates from Google Maps marked with bal-loons, and actual coordinates marked with pushpins.

5.1 Experimental ResultsOverall, AAMPL performed well even with our simple

classification schemes. Table I summarizes a subset of our

Figure 7: AAMPL classification on Nokia Phone

experiment results. Trials 1 and 2 constitute a single visitto Bean Traders Coffee. The GPS signal was lost uponentering the shop, so the measured distances to the threebusinesses are equal in the two trials. Though the locationinformation remained constant, the accelerometer signaturecontinued to provide useful information. After first enteringthe shop, AAMPL classified the signature as that of a store– incorrectly predicting Regulator Bookshop. However, af-ter several minutes, the classifier recognized the accelerom-eter signatures as those of a fast food shop, thus correctlyidentifying Bean Traders Coffee. Trials 3 and 4 occurredduring a sit-down dinner at Blue Corn Cafe. As was thecase with Bean Traders Coffee, the GPS signal was initiallylost upon entering the restaurant. As a result, the ensuinglogs defaulted to the last valid set of GPS coordinates, butthe accelerometer signature continued to change. In trial3, the GPS-only approach indicated that Regulator Book-shop was closest. Since we had been sitting down for severalminutes, AAMPL successfully recognized the signature ofa restaurant and predicted Blue Corn Cafe as well. About20 minutes into the dinner, a stray GPS signal was perhapsreceived, yielding the inaccurate distance measurements oftrial 4. In this trial, the GPS-only approach correctly iden-tified that we were currently in Blue Corn Cafe. AAMPLcontinued to identify the restaurant setting, and remainedcorrect as well. Trial 5 was conducted in The RegulatorBookshop, which is classified as a store. The nearest lo-cation, as predicted by GPS-only localization, was BeanTraders Coffee. However, AAMPL correctly classified Reg-ulator as a store, which enabled a correct prediction of ourlocation. Figure 7 shows the AAMPL prediction screenshotfrom our Nokia N95 phone implementation. This was takenimmediately after leaving Regulator Bookshop.

6. LIMITATIONS AND FUTURE WORKStrengthening AAMPL: Clearly, reported results are pre-

liminary and hence indicative (not conclusive) of the poten-tials of AAMPL. Our ongoing work is strengthening AAMPLin a variety of ways, including (1) larger action states (be-

Trial Distance to Distance to Distance to Classification Actual GPS AAMPLRegulator Bookshop Blue Corn Cafe Bean Traders Location Prediction Prediction

1 11.8m 36.2m 15.1m Store BeanTraders

RegulatorBookshop

RegulatorBookshop

2 11.8m 36.2m 15.1m Fast Food BeanTraders

RegulatorBookshop

BeanTraders

3 10.7m 18.7m 25.6m Restaurant Blue CornCafe

RegulatorBookshop

Blue CornCafe

4 85.9m 59.4m 95.3m Restaurant Blue CornCafe

Blue CornCafe

Blue CornCafe

5 14.3m 26.2m 11.9m Store RegulatorBookshop

BeanTraders

RegulatorBookshop

Table 1: Experimental Results (“Distance” indicates difference between GPS reading and Google estimate)

yond sitting and standing), (2) addition of more locationcategories including non-business locations, (3) addition ofmore features derived from accelerometers and other sensors.Moreover, ladies may carry mobile phones in their handbags,and accelerometer signatures may be less indicative of activ-ity. We intend to investigate these issues in future.

Light, Sound, and Compasses: We are investigating theapplicability of light and sound signatures towards contextidentification. Our belief, partially validated by preliminarymeasurements, is that different contexts may exhibit dissim-ilar photo-acoustic ambiances. While any individual signa-ture is too noisy an indicator, their intersection may providestronger correlation with the context. Of course, camerasmay be mostly in pockets, and the opportunity may ariseonly when the user takes it out for a phone call, or placesit on the table. Hence, acoustics may be a more reliablesource, and should perhaps be opportunistically augmentedby light signatures. We are also investigating the utility ofcompasses to understand a user’s orientation, and correlatethat to the sitting layouts in restaurants and coffee shops.

7. CONCLUSIONMany mobile phone applications require a user’s context

to execute its functions. Rough location coordinates maynot be a flawless indicator of this context because the spa-tial separation between these contexts may be arbitrarilysmall. As a result, marginal errors in physical coordinatesmay result in incorrect contextual information. This pa-per proposes AAMPL – a framework that utilizes phone ac-celerometers to augment physical localization services. Themain idea is to shortlist a list of potential logical locationsfrom GPS/alternate localization methods, and then choosefrom these logical locations by exploiting dissimilar humanmovements from each of them. In the restricted case ofbusiness localization, we show that accelerometer signaturesfrom restaurants, coffee shops, and retail stores can be sep-arable, thereby refining coordinates available from GPS orGoogle Maps. In conjunction with other sensor signatures,such as light and sound, the confidence of localization maybe further increased. Our ongoing work is investigating thesepossibilities towards GPS-free context-aware localization.

8. REFERENCES[1] Shravan Gaonkar, Jack Li, Romit Roy Choudhury,

Landon Cox, and Al Schmidt, “Micro-blog: Sharing

and querying content through mobile phones andsocial participation,” in ACM MobiSys, 2008.

[2] Shane B. Eisenman, et. al. “Metrosense project:People-centric sensing at scale,” in First Workshop onWorld-Sensor-Web (WSW’2006), Oct, 2006.

[3] Timothy Sohn, et. al. “Place-its: A study oflocation-based reminders on mobile phones,” inUbicomp, 2005.

[4] Mehul Motani, Vikram Srinivasan, and Pavan S.Nuggehalli, “Peoplenet: engineering a wireless virtualsocial network,” in ACM MobiCom, 2005.

[5] Jon Froehlich, et. al. “Myexperience: a system for insitu tracing and capturing of user feedback on mobilephones,” in ACM MobiSys, 2007.

[6] Anthony LaMarca, et. al. “Place lab: Devicepositioning using radio beacons in the wild,” inPervasive, 2005.

[7] Y. Chen, Y. Chawathe, A. LaMarca, and J. Krumm,“Accuracy characterization for metropolitan-scale wi-filocalization,” in ACM Mobisys, 2005.

[8] L. Bao and S. Intille. Activity Recognition fromUser-Annotated Acceleration Data. In Proceedings ofPervasive Computing (PerCom), 2002.

[9] D. Minnen, et al. Recognizing and Discovering HumanActions from On-Body Sensor Data. In InternationalConference on Multimedia and Expo, 2005.

[10] R. Ganti, et al. SATIRE: A Software Architecture forSmart AtTIRE. In Proceedings of ACM Mobicom,2003.

[11] G. Chen and D. Kotz. A Survey of Context-AwareMobile Computing Research. Dartmouth CS Tech.Report 2000.

[12] C. Randell and H. Muller. The Well ManneredWearable Computer. Personal and UbiquitousComputing 2002.

[13] G.D. Abowd, et al. A mobile Context-Aware TourGuide. ACM Mobile Networks 3, 1997.

[14] D. Siewiorek, et al. SenSay: A Context-Aware MobilePhone. In IEEE International Symposium onWearable Computers, 2003.

[15] S. Madden, M. Franklin, J. Hollerstein, and W. Hong.TAG: a Tiny AGrigation Service for Ad-Hoc SensorNetworks. In USENIX OSDI, 2002.

[16] Symbian Signed. <https://www.symbiansigned.com>.