DASHBOARDS OF SERVICE FULFILMENT AND ASSURANCE FOR MOBILE 1

Dashboards of Service Fulfilment andAssurance for Mobile: Multi-plataform versus

NativeAntonio Cardoso Jr.

Abstract—The Service Fulfilment and Assurance (SFA) products division at Nokia is developing mobile applications toproduce dashboards with the key information required by Chief Technical Officers (CTOs) in the telecommunicationsindustry. But the diversity of mobile operating systems and their fragmentation in terms of different versions/platformsturns the development of mobile applications a very difficult task, requiring an exhaustive testing suite for each targetmobile platform. The objectives of the work is the development of a mobile application capable of displaying OperationSupport System (OSS) and Service Fulfilment and Assurance (SFA) data in real-time, and to evaluate whether theperformance of the application developed in a multi-platform environment has impact on the usability. The prototypesolution developed in a multi-platform environment proved to satisfy the requirements with its performance meetingNokia’s standard values.

Index Terms—Mobile Application; Android; PhoneGap; iOS; OSS; Assurance; Fulfilment;

F

1 INTRODUCTION

THE telecommunications industry considersOSS not just an essential mechanism to

automate and control businesses operations butalso the must-have tool for driving improve-ments in internal operational performance. Inother words, the OSSs must automate the valuechain in order to achieve operational excellencethrough flexible and compelling service offer-ings, efficient service acquisition and superiorservice delivery.

The business competition in this area isincreasingly fierce with the technologies thatsupport daily business decisions evolving at agalloping pace. For timely decisions and effi-cient and effective management, these type ofcompanies need access to updated informationin the shortest time possible. It is the pro-cess of collecting large amounts of data, theiranalysis and presentation in high-level reports

• Antonio Paulo Cardoso Jr., nr. 57699,E-mail: antonio.junior@tecnico.ulisboa.pt,Instituto Superior Tecnico, Universidade de Lisboa.

Manuscript received May 15, 2015.

integrating the essence of such data, that allowsmanagement decisions to be taken daily, forthe most basic of business actions. Additionally,the overwhelming number of applications fordaily use in mobile devices, from tablets tosmartphones, is allowing businesses to accessthe information they need, typically received inthe form of graphs and dashboards. However,this wide range of applications must definefeatures and functionalities, including detailedevaluation matrices, in order to differentiateand thus facilitate the evaluation of those ap-plications, and provide the best user experiencematching the user requirements.

One of the key areas in OSS addressing theaforementioned goals is the Service Fulfilmentand Assurance (SFA). With the purpose of in-creasing efficiency, the SFA products division atNokia is developing mobile applications able toproduce dashboards with the key informationeagerly required by Chief Technical Officers(CTOs) in the telecommunications industry. Butthe diversity of mobile operating systems inthe market, or more specifically, their fragmen-tation in terms of different versions/platformswith different software and hardware capabil-

2 DASHBOARDS OF SERVICE FULFILMENT AND ASSURANCE FOR MOBILE

Fig. 1. Mockup of the Mobile Application MainMenu

ities, turned the development of mobile ap-plications a very difficult task, as the sameapplication is required to be developed andexhaustively tested for each target mobile plat-form. The typical process of developing nativeapplications for mobile platforms should be theappropriate way, however, it currently bears ahuge disadvantage as it is hard to reuse thesource code developed for some target mobileplatform in a different platform/mobile Oper-ating System (OS) (or even a different versionof the same hardware platform). [1]. How-ever, under certain scopes, a multi-platformapplication development technology may solvethe aforementioned difficulties, by enabling thereuse of the same source code to produce theApp targeted to various mobile OSs/platforms.

In order to address those issues, one of theobjectives of the work presented in this thesisis related to the development of one such mo-bile application capable of displaying OSS SFAdata from the network elements of a provider,allowing end-users (operations or managementpersonnel) to access that information in real-time. Another objective of the work is theevaluation of the performance of such an App,developed in a multi-platform environment,in terms of the impact in its usability. Thereasons for the evaluation are mainly due to thehigher costs incurred when developing nativeApps for each of the existing mobile OSs/platforms. To determine the way forward inthe optimization of functions already providedby Nokia solutions for the development of theApp, some surveys were performed involvingcurrent customers of the company.

The objective of the work to be developedis the scope of this thesis, is the analysis ofperformance a mobile App multiplatform de-

velopment framework. This mobile App willbe based in dashboards. A mockup of thedashboards is illustrated in Figure 1.

2 BACKGROUND

In this section it will be shown all the con-ducted studies for the development of theproject. Initially it is introduced Nokia as acompany and also the OSS network architec-ture. Then I show the investigated Develop-ment for Mobile Application Platforms thatenable the development of mobile applications.It is also described all the studied developmentframeworks and tools, like the hybrid apps de-velopment frameworks and also the develop-ment support tools including charts and maps.

Given that the application to be developedwill make a great use of the capabilities tocreate and analysis charts, and taking into ac-count the cross-platform development, it is arequirement to use charts libraries. The ap-plication to be developed will include a mapwith the location of each service. It is necessaryto ensure that maps using API that allowsmanipulation and customization according tothe desired one.

2.1 Nokia Networks Reference ArchitectureNokia Networks is the global expert in mobilebroadband, offering efficient mobile networkproducts and services as well as market intelli-gence solutions that maximize the value of thenetworks.

The “Network Architecture” is considereda specific domain of an operator due to itshuge importance. In terms of Nokia Networksproducts for operators, a special emphasis hasbeen put on linking the “Network Architec-ture” with the Nokia Networks Reference Ar-chitecture, enabling an operator to make keydecisions on its investments. Rather than tryingto fit everything into one gigantic view, theNokia Networks Reference Architecture is splitinto six viewpoints of smaller areas. The NokiaNetworks Reference Architecture is based onopen standards to ensure it suits the needs ofmost operators.

The starting point for the concept of theNokia Networks Reference Architecture was the

CARDOSO 3

TeleManagement Forum (TMF)’s Framework,which consists of four enterprise layers: the En-hanced Telecom Operations Map (eTOM) Busi-ness Process Framework, the SID InformationFramework, the TAM Application Frameworkand the Integration Framework.

2.2 Nokia Networks

Nokia is highly focused on Mobile BroadBand(MBB) and considers fundamental to have Op-eration Support System (OSS) applications ableto answer all faults in the network in the short-est possible time. All this paradigm is situatedin the business area named Customer Expere-rience Management and Operations SupportSystem (CEMOSS). This business area of Nokiais illustrated, namely the components of theNetwork Management products that the com-pany sells to operators. The NetAct, is thekey Element Manager, thereby allowing otherapplications of the company to work over thissystem [2].

A very wide range of OSSs such as Inven-tory, Order Management, Provision and ServiceActivation are included in the Fulfillment pro-cess area. Network failures may also be pro-actively identified by Service Assurance, ini-tiating resolution actions and notifying high-priority customers. The “Order-to-Cash” cy-cle, in which service providers give requestedservices to customers in a timely and correctmanner, is supported by Service Fulfillmentsubsystems. Service Assurance solutions donot monitor service performance based on thenetwork manager’s view but on the customer’sview, defining the following key indicators:Key Performance Indicators (KPIs), Key Qual-ity Indicators (KQIs) and Service Level Agree-ments (SLAs).

In Nokia, until recently, the interface to allthose services was available as a web interfaceaccessible via a browser using Service QualityManager (SQM), making easy to an operatorto identify if the quality of its basic serviceswas being degraded. Through these processesoperations technicians are able to prioritize theresolution of problems through a set of correc-tive actions. The Technical Officer (TO) moduleof the solution produces, usually daily, reports

of all issues identified through the various toolsto be typically delivered to the CTO of theoperator, as represented in Figure 2.

Fig. 2. Reporting Workflow

2.3 Development for Mobile ApplicationPlatformsThere are many different platforms for mobiledevices: Google’s Android, Apple’s iOS, Mi-crosoft’s Windows Phone, Blackberry, amongothers. It is therefore a very competitive andfragmented market scenario with very rapidchanges. In addition to this diversity of sys-tems, each platform adopts different program-ming language paradigms, development toolsand environments.

Native applications (Apps) are developed us-ing an Integrated Development Environmente(IDE) requiring a high-level of experience andtechnological know-how.

One alternative to Native application de-velopment, circumventing the aforementionedcomplexity, corresponds to Web developmentframeworks that use just web technologies (HyperText Markup Language (HTML), Cas-cading Style Sheets (CSS) and JavaScript) forthe web Apps, facilitating the developmentwith consolidated technologies and also pre-senting sets of Application Program Interfaces(APIs) to access some features of the hardwareand operating system of mobile platforms.

Other alternatives are Hybrid applicationdevelopment frameworks that embed HTML5Apps inside thin Native application containerswhere the source code to be executed by abrowser is packaged within the application.Hybrid applications are installed on the deviceand allow access to the device hardware.

These frameworks have as objective the de-velopment of applications suitable to run invarious platforms, encoding only once the ap-plication [3] [4] [5]. Among the frameworks

4 DASHBOARDS OF SERVICE FULFILMENT AND ASSURANCE FOR MOBILE

that stand out are the Phonegap [6] and theTitanium Mobile [7].

2.3.1 Native Application DevelopmentFor the development of Native applications anIDE is required, providing all the necessarytools and components for building the appli-cations.

The main mobile Operating Systems avail-able nowadays on the market, are undoubtedlyGoogle’s Android (around 80% share) and Ap-ple’s iOS (around 15% share), with Microsoft’sWindows Phone (around 4% share) seeing somegrowth. For the work of this thesis the firstoption to consider is Google’s Android, due toits specifications and popularity, with Apple’siOS as the second option in terms of NativeApp development.

Apple’iOS was developed by Apple Inc. fortheir portable devices (initially the iPod touchthen the iPhone in 2007 and later the iPad andthe Apple TV). iOS controls the hardware ofthe devices and Apple supplies all the nec-essary Development Environment technologies(Xcode) for the implementation and testing ofnative applications. iOS is a mobile (embed-ded) version of Apple’s OS X operating system,a Berkeley Unix system.

Google’s Android is an operating systembased on the Linux kernel with a user interfacebased on direct manipulation, designed pri-marily for touchscreen mobile devices such assmartphones and tablet computers using touchinputs. Touch inputs loosely correspond to real-world actions, like swiping, tapping, pinching,and reverse pinching, used to manipulate on-screen objects or a virtual keyboard. Despite be-ing primarily designed for touchscreen input,Android is also used in embedded systems suchas televisions, game consoles, digital cameras,and other consumer electronics devices [8] [9].

2.3.2 Hybrid Application DevelopmentHybrid Apps combine the advantages of WebApps and Native Apps. The Hybrid Apps arebuilt largely resorting to the use of HTML5 andJavaScript, making possible to develop an ap-plication without a detailed knowledge of thetarget platform. Hybrid Apps embed HTML5

code inside a thin Native App container (UI-WebView in iOS and WebView in Android). LikeWeb Apps, the source code is still executedby a thin browser that is part of the finalapplication and can be packaged with the App.Unlike Web Apps, where the source code mustbe downloaded from the web before runningthe App, Hybrid Apps are installed in thedevice and allow access to the hardware. Dataaccess is also done through the use of APIs.Phonegap and Titanium are examples of themost popular containers for building Hybridmobile Apps [1].

2.4 Development Frameworks

In this section shows the investigated devel-opment for mobile application platforms thatenable the development of mobile applications.

2.4.1 Phonegap Framework

PhoneGap is a mobile development frame-work, it enables software programmers tobuild applications for mobile devices usingJavaScript, HTML5, and CSS3, instead of tra-ditional languages such as Objective-C [6] orJava. The resulting applications are hybrid, sothey are neither truly native (because the wholelayout rendering is done through web views in-stead of native User Interface (UI) framework)nor purely web based (as they are not onlyweb applications, but applications packagedfor distribution and access to native deviceAPIs).

Building Native Apps for iPhone, Android,Windows Phone and others requires differentframeworks and languages. PhoneGap solvesthis gap by using standards-based web tech-nologies to bridge web applications and mobiledevices. Since PhoneGap Apps are standardscompliant, they are future-proof to work withbrowsers as they evolve.

2.5 Charting Tools

To determine the most suitable Charting Toolslibraries several usability tests were carriedout based on predetermined heuristics (relativeto charting features and functionalities). The

CARDOSO 5

Charting Libraries identified as best for mo-bile devices and satisfying the heuristics: AM-CHART, jsChart, CanvasJS, HighCharts andZingChart, studied in [10].

2.5.1 AMCharts Library

AMCHARTS offers JavaScript/HTML5 chartsfor most needs. The framework includes serial(column, bar, line, area, step line, step withoutrisers, smoothed line, candlestick and OHLCgraphs), pie/donut, radar/polar, y/scatter/bubble, Funnel/Pyramid charts and angulargauges. Those charts offer unmatched function-ality and performance in a modern, standardscompliant package, and the JavaScript chartinglibrary is responsive and supported by touch/mobile devices [11].

2.6 Geo Location

The GeoLocation it is a very important pointin this application, because by showing the lo-cation of the network components in the appli-cation identified which allows more effectivelythe location of problem.

In this section studied the frameworks for thecreation of maps used for the application.TheAPI should support the reception of data in astandard format, such as GeoJSON.

2.6.1 GeoJSON

GeoJSON is a particular case of JavaScriptObject Notation (JSON), but in this case it isused to encode geographic data structures, sothere are now specific members in the formatstructure. A GeoJSON object may represent ageometry, a feature, or a collection of features.Features in GeoJSON contain a geometry objectand additional properties, and a feature collec-tion represents a list of features. A completeGeoJSON data structure is always an object (inJSON terms). [12].

2.6.2 Here Maps

Here Maps is developed inside the Nokiagroup, and its mission is “to make maps for abetter life”. The HERE Maps API for JavaScriptis a set of programming interfaces that enable

developers to build Web applications with fea-ture rich, interactive HERE Maps at their cen-ter. The API consists of libraries of classes andmethods to implement the functionality of aninteractive application similar to Google Maps,and this API receives data also in GeoJSONformat, allowing to create and manipulate themaps according to what is required in eachcase. Unlike Google Maps, Here Maps requireslicensing that involves costs, but in this case,given that the work is developed inside theNokia group, the cost factor does not weighin deciding the best platform to use [13].

3 SYSTEM DESIGN AND DEVELOP-MENT

This chapter describes the design and devel-opment of the application, and the integrationand connection to existing servers. The chapteris divided in three parts, being the first dedi-cated to the conceptual design of the Appli-cation, the second describing the developmentenvironment where all the frameworks usedwill be identified, and the third describing thedevelopment steps of the hybrid application.

3.1 System DesignThe Platform consists of a CommunicationModule and the SQM Mobile App to be inte-grated with the SQM System.

The SQM is based on services. Services aredefined as the business entities that are soldto operator’s customers, such as voice, data,SMS, music streaming, etc. SQM models theseservices internally, and monitors the impact ofnetwork state (existing problems, faults, per-formance degradations, etc) on those services,thus allowing an operator to support the Ser-vice Assurance process understanding if deliv-ered services meet agreed service levels.

The Communication Module will be imple-mented following the concepts of RESTful,with objects of the data model encoded inJSON/JSON with padding (JSONP), as cur-rently used by Nokia for communications be-tween the various systems of products. The re-sponse to these requests is the responsibility ofLiferay Portal, as already described, and this is

6 DASHBOARDS OF SERVICE FULFILMENT AND ASSURANCE FOR MOBILE

Fig. 3. SQM

a central point for all the required information.Figure 3 illustrates the current architecture ofSQM, composed of Database Servers (DSs), Ap-plication Servers (ASs), Load Balancers (LBs),Element and Manager Systems (EMSs) andGraphical User Interfaces (GUIs) modules, intowhich the SQM Mobile App will be integrated.

A load balancer, not shown in Figure 3, willbe responsible for determining which of thefront-end GUIs the SQM Mobile will bind.After determining the GUI, the connection be-tween the equipment and the communicationmodule of the GUI is established enabling tosend requests and to receive data in the mobiledevice.

SQM Mobile will then be responsible for theanalysis and manipulation of the data received,to be subsequently made available to the useras intended. The data will be requested fromthe current system through Representationalstate transfer (REST) requests, with these re-quests returning JSON objects.

3.1.1 Communication ModuleOne communication module will be installedfor each existing GUI. The mobile device willcommunicate with the communication moduleusing REST calls in secure transport channels.If the GUI was not assigned a Public IP (mean-ing that the front-end would be in a DMZ),then a VPN connection between the mobiledevice and SQM will have to be established. Asthe data model to be used is the same as the onealready used in communications between thevarious su-systems of the SQM solution, it will

not be necessary to define a new data model.The HTTP methods for sending and gettingdata, in order to have the proper interpretationof the data and therefore adequately display itin the dashboards, will also have to be defined.

Considering that SQM Mobile App will ma-nipulate existing data to other Nokia services,the communication modules to be used alreadyexist and are used in other products fromNokia. Therefore the main focus of this workwill be the efficient manipulation of data.

3.1.2 SQM Mobile AppThe data processed by the SQM Mobile Appis constantly changing, as it corresponds toevents (alarms) that are generated in real-timeby the Services (Service Platforms or NetworkElements) of an Operator.

As such, in each “view” of the SQM MobileApp, the details of a Service must be loadedin order to ensure that the data shown corre-sponds to the latest available in the system.This requires a management a large amountof data. This is the main challenge of theSQM Mobile App, as it should be able toprocess large amounts of data in near real-time. The development work started with amulti-platform framework environment, usingHTML, CSS, and JavaScript, and the chartinglibrary AMCHART, in order to display thebehavior of different types of Service Platformsor Network Elements, according to the patternsalready identified in the work of [10].

Although initially considered in the scopeof works, the Native application was not de-veloped, as it was determined that the dura-tion of the thesis work would not be suffi-cient for the full development of two mobileapplications. However there existed referencevalues for application performance, providedby Nokia, documented in Section 4 that wereused to carry out several performance tests,from reception times and loading data to theamount of data transferred.

In relation to the mapping API componentof the SQM Mobile App, the necessary re-quirements such as, support receiving data inGeoJSON structures and allow the construc-tion of Geometry Objects (Points, Multipoints,Polygons and MultiPolygon) were met by both

CARDOSO 7

Nokia’s HERE Maps and Google Maps, the factthat the HERE Maps solution belongs to theNokia group, weighted on its selection.

3.2 Development ProcessThis section will describe the project organi-zation. Must be applied to development of allapplication screens, as well as their use.

The JavaScript libraries selected for the de-velopment of the hybrid App are jQuery andjQuery Mobile, that greatly facilitate all pro-gramming, namely due to a variety of sim-plified commands to perform standard proce-dures and the specific features for mobile de-velopment, as well as the use of AsynchronousJavaScript and XML (AJAX) that makes possi-ble to easily create requests to servers.

Because of the “same origin” policy, it is notpossible to make cross domain AJAX requests.However, with JSONP it is possible to havescript tags that load javascript files from otherdomains, turning this JSONP exception capableof making cross domain requests by dynami-cally creating a script tag with the necessaryUniform Resource Locator (URL).

The method can be described as follows: theServer includes data, usually in JSON format,in a function call; during the load of the script,the browser calls that function and passes theloaded data; this situation implies that a thirdparty server needs to know the local javascriptfunction name, which is not practical, but canbe circumvented by passing the function nameas a parameter to the request URL.

In order to support the JSONP requests, itwas necessary to make an “adaptation” to theNokia servers, by adapting the level of theresponse format, from the response to be sentwithin a certain function by a jsonpCallbackattribute. This attribute is the same for allrequests. The following code snippet is an ex-ample of an AJAX request using JSONP.

The SQM Mobile App is composed of sixmain screens, i.e., Login, Home, Map, Graph,Service and Attributes. Due to its nature, thesame development process is applied to all ofthe App screens.

1) Login Screen: Page entry where the loginto the Platform is performed. The login

is performed through an AJAX request,using the login URL.

2) Home Screen: This screen displays alldashboards created for the Services, as il-lustrated in Figure 4 where it possible toobserve the Services, as well as a list ofthe latest 5 “problems” and their location.By selecting on each service, it is possibleto view the properties about service. AsServices are grouped into logical views itis possible to select which of the logicalviews the user wants to see. For that pur-pose a “burger menu” has been used inorder to list all the logical views available.For this menu construction the “UltimateBurger Menu”.

Fig. 4. Home Menu

3) Graph Screen: The purpose of the Graphscreen is to display the dependencies ofthe selected Service, showing all the otherServices that are associated with the onethat was selected. The graph with thedependencies of each Service allowed toidentify a Root node, and the left and rightChildren.Given that the development of a full graphof dependencies represents a very highload in mobile devices, a different solu-tion for the presentation of the data wasproposed to Nokia, consisting in splittingthe display screen into five columns, eachidentifying a level of Service hierarchyshowing only their leads. This proposalwas accepted and it turned possible todisplay only the necessary data with amuch lower development cost and im-provements in the loading of the informa-

8 DASHBOARDS OF SERVICE FULFILMENT AND ASSURANCE FOR MOBILE

tion in the mobile device.4) Map Screen: The Map view screen shows

the location of Services. This screen wasimplemented using the Nokia HERE Mapsframework, with data received in GeoJ-SON format. Once imported the data theframework is responsible for identifyingthe type of object shown on maps, whichcan be “areas” (identifying a region wherethe problem is occurring) and points (iden-tifying Network Elements with problems).

5) Problem Screen: The Problem screenshows the data for a particular problemrelated to a Service that was previouslyselected. This screen loads a web page inan iframe, which is already available inthe application management provided tocustomers.

6) Attributes Screen: The Attributes screen,illustrated in Figure 5 shows a table withall the attributes of a given Service, andwhen there is data available shows thecorresponding graph with the historicalvalues of the selected attribute. The graphcharts were developed using the AM-CHARTS framework.

Fig. 5. Attributes of Service Screen

4 EVALUATION

To evaluate the SQM Mobile App, several testswere performed in order to analyze its perfor-mance and usability. These tests were carriedout under different end-user environments, in-cluding stress tests and end-user interactivity.The identified suite of tests is briefly listed inTable 1.

TABLE 1Evaluation Test Suites

Type of Test Objectives

Stability To analyze the behavior of the applicationduring a certain period of time

(between 1 to 2 weeks)

Traffic data Measuring the amount of data betweenthe application and the server,

and vice versa

Response time Measuring the changing timebetween application screens

Usability End-user tests to verify usabilityand if the application is intuitive

The Stability tests were performed using theSQM Mobile App during 3 weeks, for all thetasks it allows. Tests were performed at least3 times a day at intervals of (approximately) 3hours.

The tests were performed several times aday because the data produced by Services areconstantly changing, making therefore possibleto determine the behavior of the application inview of this constant change of data.

To test the Usability a group of ten userstested the application taking into account thepredetermined settings. The responses of eachuser, in relation to the expected behavior of theapplication, were then collected for analysis.

For Traffic tests and Response time tests,the Chrome browser Debug Tool (in the mobileTablet) was used. With the Debug Tool it waspossible to check each application screens load-ing time and the amount of data transferred.

In order to test all application scenarios, thetest suite was carried out taking under threetypes of connection:

• Wi-Fi connections in business environment(internal network)

• Wi-Fi connections in residential environ-ment (home network)

• Mobile data connection (4G)Each screen of the SQM Mobile App was

opened 20 times, so the “charging” of eachscreen was carried out 20 times in a row withboth the charging times and transferred data col-lected for analysis.

The application tests were performed with a

CARDOSO 9

Samsung Tablet 4 10.1 with 16 GB of internalstorage memory and 1.5 GB of RAM.

4.1 Analysis of Test Results

Due to the type of tests performed, the resultsare better analyzed using “box plots”, makingpossible to verify the maximum, minimum andmean values for each sample in the same graphand for the different connection types. One ofthe factors that led to the choice of this typeof chart is that outliers are “discarded”. Thisproperty is highly valued in the analysis ofsuch data, since the connections to the serversmay suffer traffic peaks momentarily, causingvalues beyond “expected”, which would leadto incorrect analysis of the performance of theapplication.

During 3 weeks the App was tested Stabil-ity of application, at least 3 times a day, forall the tasks it allows. The application alwaysresponded as expected, showing no data loadproblems.

The Traffic and Response time values werecollected from the Chrome browser Debug Toolmeasured for each of the screens that wereloaded. The following values were obtained(Internal refers to when the tablet is connectednetwork in business environment, Home refersto connected in residential environment andMobile refers to when the tablet is connectedto a mobile data connection):

1) Login: Internal:1.546 seconds, Home: 1.586seconds and Mobile is 1.571 seconds.Toload this screen were transferred 1.5 KB.

2) Home Screen: Internal: 8.851 seconds,Home: 8.868 seconds and Mobile is 8.337seconds. To load this screen were trans-ferred 330KB.

3) Service Problem Screen: Internal: 4.088seconds, Home: 4.337 seconds and Mobileis 4.183 seconds. To load this screen weretransferred 340KB.

4) Dependencies Screen: Internal: 1.789 sec-onds, Home: 1.828 seconds and Mobile is1.774 seconds. To load this screen weretransferred 1.5KB.

5) Map Service Screen: Internal: 5.908 sec-onds, Home: 6.527 seconds and Mobile is

6.5205 seconds. To load this screen weretransferred 481KB.

6) Attributes Screen(Figure 6): Internal: 4.695seconds, Home: 7.098 seconds and Mobileis 5.995 seconds. To load this screen weretransferred 4,7KB.

Fig. 6. Loading Time of screen Attributes

In order to determine a possible maximumvalue for the transferred data on a possibleusage of the application two tests were alsomade: Check all the attributes of a service; Checkall the attributes of all the services of a logical view

For the first case a value of 381.9 KB wasreached, with 691.4 KB for the second case.

In relation to Usability tests, each screen ofthe SQM Mobile App was opened 20 times bythe group of 10 users. All users indicated thatthe application responded as intended and thattheir perception about loading (charging) timesof the displays were within the prescribedstandards. Half of the testers were employeesof Nokia, and they further indicated that theapplication was behaving as expected, havingadditionally the “form” of data presentationsimilar to other company’s products.

As expected, when users were connected tothe Nokia’s internal network the loading timeswere lower than when connected to a homenetwork or to a mobile network.

The SQM Mobile App was developed assum-ing that it would be used mainly by technicianswhen they are away of their workplace, orwhen they are on the move, so the most usedconnection would be the mobile network.

From the results of the tests, it could beconcluded that there was not observed a majorimpact on the performance of the App, evenwhen using a mobile networks.

10 DASHBOARDS OF SERVICE FULFILMENT AND ASSURANCE FOR MOBILE

Regarding the amount of data that is trans-ferred from/to the the SQM Platform, it is alsoeasily supported by existing mobile networks.

5 CONCLUSION

The telecommunications industry considersOSS an essential mechanism to automate andcontrol businesses operations, and for drivingimprovements in internal operational perfor-mance. One of the key areas in OSS is the Ser-vice Fulfilment and Assurance (SFA), for whichNokia is developing mobile applications ableto produce dashboards with key informationrequired by CTOs in the telecommunicationsindustry.

The objectives of the work proposed in thisproject is to develop a mobile application capa-ble of displaying OSS and Service Fulfilmentand Assurance (SFA) data from network ele-ments in real-time, and to evaluate whetherthe performance of an application developedin a multi-platform environment.A preliminaryresearch on specific telecom operations pro-cess models allowed to consolidate the under-standing of how a large telecommunicationsoperator works, and the key requirements forproducts and services targeted to these typesof customers.

Another study gathered information on thediversity of mobile Operating Systems anddevelopments frameworks, as well as on thediverse charting libraries available, allowing abetter understanding on the level of difficultyfor the design and on the performance to beexpected from applications developed usingthose frameworks and libraries, targeted to themain mobile platforms in the market (Androidand iOS).

Finally, from the prototype developed andthe analysis of its performance in terms ofStability, Usability, Response Times and Trafficin the network, it was possible to concludethat the development using a multiplatformenvironment such as the Phonegap frameworkis a good alternative to the development ina Native mode. The developed application re-sponds as desired, matching user expectationsand the loading times for all of the screensof the application fell within Nokia’s standard

values. As such, it has been considered byNokia not worth the additional effort of devel-oping the application in Native mode, just forcomparison, as the objectives were met usingthe multiplaform environment.

REFERENCES

[1] S. Xanthopoulos and S. Xinogalos, “A ComparativeAnalysis of Cross-platform Development Approaches forMobile Applications,” in Proceedings of the 6th BalkanConference in Informatics, ser. BCI ’13. New York, NY,USA: ACM, 2013, pp. 213–220. [Online]. Available:http://doi.acm.org/10.1145/2490257.2490292

[2] “Nokia Networks.” [Online]. Available:http://networks.nokia.com/portfolio/products/operations-support-systems

[3] L. Corral, A. Sillitti, and G. Succi, “Mobile MultiplatformDevelopment: An Experiment for Performance Analysis,”Procedia Computer Science, vol. 10, no. 0, pp. 736–743,2012. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S1877050912004516

[4] G. Paes, A. Silva, J. Simeoni, J. Nascimento, andE. Tanaka, “Impacto da adocao do Phonegap na Interfacede aplicacoes moveis,” in Proceedings of the 12th BrazilianSymposium on Human Factors in Computing Systems,ser. IHC ’13. Porto Alegre, Brazil, Brazil: BrazilianComputer Society, 2013, pp. 307–309. [Online]. Available:http://dl.acm.org/citation.cfm?id=2577101.2577177

[5] A. Charland and B. Leroux, “Mobile ApplicationDevelopment: Web vs. Native,” Commun. ACM, vol. 54,no. 5, pp. 49–53, 2011. [Online]. Available: http://doi.acm.org/10.1145/1941487.1941504

[6] “PhoneGap.Easily create apps using the web technologiesyou know and love: HTML, CSS, and JavaScript,” p.Easily create apps using the web technologies you.[Online]. Available: http://phonegap.com/

[7] “Titanium Mobile Development Environment.” [Online].Available: http://www.appcelerator.com/titanium/

[8] “Google’s iron grip on Android: Controlling opensource by any means necessary.” [Online]. Available:http://arstechnica.com/gadgets/2013/10/googles-iron-grip-on-android-controlling-open-source-by-any-means-necessary/

[9] “Industry Leaders Announce Open Platform forMobile Devices.” [Online]. Available: http://www.openhandsetalliance.com/press 110507.html

[10] J. a. F. U. Ribeiro, “Heurısticas para avaliacao deaplicacoes multiplataforma que permitem a interacao comgraficos em dispositivos touchscreen,” 2014.

[11] “AMCHARTS - JavaScript Charts and Maps.” [Online].Available: http://www.amcharts.com/

[12] “The GeoJSON Format Specification.” [Online]. Available:http://geojson.org/geojson-spec.html

[13] “Here Developer Portal.” [Online]. Available: https://developer.here.com/