Developing a Geo-positioning C# Framework for Radio Network

Optimization based on 3G Network Recordings

Ruben Borralhoruben.borralho@ist.utl.pt

Instituto Superior Tecnico, Lisboa, Portugal

May 2017

Abstract

With constant traffic increase in cellular networks, it became demanding and complex for operators tomanage and monitor its networks in order to provide desirable Quality of Service (QoS) to its users. Due tosuch situation, this project appears as a solution to costs reduction in terms of network monitoring and man-agement. The objective is to produce and implement a framework that collects protocol events exchangedwithin network elements, stored at the Radio Network Controller (RNC), called traces, gathering usefulinformation from them and present results relative to network performance. To achieve this goal, a C#application was developed encompassing all procedures since traces collection to network performance met-rics visualization. It also makes use of a Geolocation algorithm in order to attribute latitude and longitudecoordinates to traces and so, to be possible associate network performance metrics to specific locations. Theprogram was developed under certain high quality parameters, following Extreme Programming concepts aswell as S.O.L.I.D. Principle. The first one takes to code development with bugs occurrence minimizationand early errors detection. Unit Tests usage and Code Review by different developers contributes to suchscenario. S.O.L.I.D. Principle complements the benefits of Extreme Programming and also encompasses aset of practices which takes to the production of an organized code, well structured, modular, allowing newfeatures addition easily, and comprehensive to future usage by other developers. A deep study of traces wasdone in order to know which is the relevant information contained on them. A set of use cases was initiallydefined and respective results were obtained to radio frequency metrics in terms of coverage, with RSCP orEc/N0 levels, and also dropped and blocked calls location. Comparisons of such results were then performed,using drive tests as reference. In one of these comparisons, specifically in Tapada das Necessidades, it wasverified a difference between average RSCP value received of just 1.3 dB between traces and drive tests.Keywords: QoS, SON, Extreme Programming, S.O.L.I.D. Principles.

1. Introduction

1.1. Motivation

Quality of Service (QoS) providing is one of the majorconcerns from telecommunications operators nowa-days. Users increasing demand, growing traffic orusage of more powerful applications are aspects tobe fulfilled. In order to know if their network per-formance is within reference parameters, measuresof its performing must be done. Methods allowingthese measures to be done in an effective and cost re-duced way are valuable. Typical practices, like drivetests, require large operation expenditure (OPEX).Moreover, with the increasing number of network pa-rameters to monitor and set, the network extensionwith the augmented number of base stations and theparallel operation of technologies (Second Generation(2G), Third Generation (3G) and Long Term Evo-lution (LTE)) take this expenditure to unsustainablevalues [1]. This factor motivates the search of alter-native methods that allow to reduce network moni-toring costs and increasing the range of monitored ar-eas. It is here where Self-organizing Networks (SONs)

concept came up. It is a collection of functions forautomatic configuration, optimization, diagnosis andhealing of the network in a remote manner. One wayof implement solutions based on SON concept is thecollection of protocol messages exchanged within ter-minal and network elements which contain valuableinformation about network conditions experienced byusers. This type of solutions increase effectiveness innetwork management, widen monitored areas and re-ducing operational costs.

1.2. Objectives

There are two main objectives regarding this work.Firstly, to analyze Universal Mobile Telecommunica-tions System (UMTS) layer 3 protocol messages tounderstand which relevant information can be takenfrom them, in order to acquire network performancemetrics. Then, it is suppose to create a C# applica-tion, capable of collect identified data from protocols,producing use cases visualization in terms of networkperformance. This enters directly with SON concept,in a way that allows the remote analysis of the net-work performance, in real-time, in a wide area and

1

avoiding to expend resources in field measures. Notonly QoS metrics will be produced but, a geograph-ical representation of them will also be provided al-lowing to associate performance indicators to specificlocations. The location is acquired with the usageof an Observed Time Difference (OTD) based Geo-positioning algorithm, already developed. The workwill focus on 3G technology and in a specific set ofdata; however, the developed application should sim-plify features addition, being developed in a main-tainable way.

2. Background

This section aims to supply information about theenvironment where this project is inserted.

2.1. Network Performance Data Collection

There are several methods used to collect data fromnetworks in order to understand not only if the net-work is providing the required and established qualityto the users, but also to help in its planning and op-timization.

2.1.1 Performance Management

The Performance Management (PM) involves eval-uation and reporting of network elements behaviorand effectiveness, by gathering statistical informa-tion, maintaining and examining historical logs, de-termining system performance and altering the sys-tem modes of operation [2]. It includes measurementsof network and applications traffic in order to providea consistent and predictable level of service at a giveninstance and across a defined period of time. Accord-ingly, PM involves network monitoring, applicationsand service activity and design and configuration ad-justments.

KPIs

Key performance indicators (KPIs), in telecommuni-cation networks, are measures of the network per-formance. They result from statistical calculationsbased on counters installed along network elements(PM data), that can register, among many other in-dicators, the number of voice calls performed as wellas data calls, blocked calls, dropped calls, handovertypes or failed handovers.

KPIs represent a crucial management factor intelecommunication networks, allowing to get anoverview of the entire network performance and qual-ity, identifying performance gaps between currentand desired performance and providing indicationsconcerning the progress of closing those gaps [3].There are three types of KPIs, RATIO KPI reflect-ing the percentage of a specific case occurrence toall cases, MEAN KPI reflecting a mean measurementvalue based on a number of sample results and the

CUM KPI which represents a cumulative measure-ment which is always increasing [4].

2.1.2 Configuration Management

The Configuration Management (CM) provides theoperator with the ability to assure correct and effec-tive operation of the 3G network as it evolves. Itencompasses control and monitoring mechanisms toverify the actual configuration of network elementsand resources. These actions may be initiated by theoperator or by functions in the Operations Systemand can be performed as part of implementation pro-grammes, optimisation programmes and to generalQoS maintenance [5]. The CM service componentsare the System Modification Service component andSystem Monitoring Service component. The first oneis an action performed to introduce new or modifieddata into the system due to optimisation or configura-tion. The second referenced component, provides theoperator with the ability to receive reports on the con-figuration of the entire network, or parts of it, frommanaged Network Elements. In terms of CM func-tions, they encompasses operator assistance in mak-ing the most timely and accurate changes, ensure thatCM actions will not result on secondary effects, trafficshould be protected from effects of CM actions andthere must exist mechanisms to overcome data incon-sistencies [6].

2.1.3 Drive Tests

Drive test is a test performed in cellular networks andconsists on network data collection on a moving vehi-cle. It provides an accurate real-world capture of theRadio Frequency (RF) environment under a particu-lar set of network and environmental conditions. Thecollected data depends on the needs, and it could berelative to voice or data communications as well ascoverage analysis and RF metrics, checking for ex-ample the interference level. The most common rea-sons to do drive tests are the network performanceanalysis, integration testing of new sites, changes onsites parameters verification, marketing and bench-marking. The hardware required for a drive test is anotebook with specific installed software, at least onemobile phone and a Global Positioning System (GPS)device. Although being of great value due to its re-liability, drive tests brings huge costs to the mobileoperators in terms of both equipment and manpower.

2.1.4 Traces

When connected to a Node B from a certain RNC, aUser Equipment (UE) is constantly exchanging datawith these network elements, either to establish anytype of communication or to inform about its com-munication conditions. All this data is collected andlogged at the RNC from that area and represents apowerful feature to analyze and monitor network per-formance. This data is called traces, and they are

2

layer 3 protocol events resulting from communicationbetween RNC and network elements attached to it,UE (via Node B), Node B, other RNCs and Core Net-work (CN).

Traces represent a huge amount of information,providing really useful data of the communicationsquality. As an example, they contain measurementsmade by UEs relative to the quality of signal that theyare receiving with the storage of RSCP or Ec/N0svalues, or information relative to cells to which theyare connected, with Scrambling Codes (SCs) and Ac-tive Set Cell IDs information. It includes also dataconcerned to UE identification (IMSIs), PropagationDelays and Time Spans, among others. A droppedor blocked call, as well as its causes, is reported andstored at RNC in the form of traces. Additionally, byprocessing and crossing traces information it is pos-sible to reach the location of an UE when it sendsor receives any event/message. This factor representsa very powerful tool where it is possible to associatenetwork events to specific locations, monitor a routemade by a generic user, checking network parame-ters during its movement or even know which kindof device has better performance in both specific andgeneral situations.

2.2. GPEH Traces Collector Feature

The developed work is based on a traces data collec-tion feature, specifically General Performance EventHandling (GPEH) from Ericsson. This tool is placedat the RNC and collects all the protocols received andsent by it as well as the ones generated internally.

Figure 1: GPEH location at RNC.

The Ericsson feature is used to create and log eventsin a 15 minutes Result Output Period (ROP), i.e., 15minutes of all layer 3 signalling exchanged in the net-work belonging to that RNC [7]. A ROP is dividedin a set of files, named Main Processors (MPs), withall communication events exchanged in the networkon a specific area, covered by a RNC. The events onthe MPs are stored in parallel, i.e., each MP file hasevents from minute zero to fifteen and not sequen-tially. The first and last files contain specific infor-mation and not the normal sequence of events. Whilethe first one works as a reference file, last file containsINTERNAL IMSI events, representing the UEs that

performed communication on that area, even if it wasonly signalling. For the same IMSI (UE) it could ex-ist more than one INTERNAL IMSI event in lastfile, depending on the activity of the UE. If a UEestablished two phone calls in a 15 minutes periodbelonging to the same ROP, its last file will containsat least two INTERNAL IMSI events for that UE,with same IMSI but different triggering time.

All other events are stored and distributed throughthe remaining files but not explicitly associated to aUE.

2.3. GPEH - RNC and Protocols

Ericsson’s GPEH feature is strategically placed atRNC because of the functions performed by this net-work element from which useful information relatedto signalling and data transmission over the radio in-terface can be taken. Some of these functions encom-passes Call Admission Control, where the RNCcalculates the current traffic load for each individualcell and decides whether the interference level is or notacceptable, rejecting the call in negative case (blockedcall), radio links set-up or release and maintenanceor Power Control for the efficient operation of aCDMA network, where the transmitted power of allusers is controlled. Handover is also managed bythe RNC which uses measurement values supplied byNode B and UE to decide whether a different cell isbetter suited for a current connection.

The information of each of these processes is re-ported via layer 3 protocols, specifically, the ones de-scribed below:

• RRC - The RRC sub-layer controls the sig-nalling between UE and UTRAN providing sig-nalling transfer services to higher layers [8]. Sig-nalling messages are encapsulated within RRCmessages for transmission over the radio inter-face; on the UTRAN side, the RRC configuresthe broadcast channels that are broadcast in eachcell and, on request, it sets up the radio bearersover which applications can exchange data be-tween UE and UTRAN.

To carry out all its tasks, the RRC layer collectsmeasured values from all other layers, in orderto generate configuration instructions for them,using suitable algorithms. So, it is possible tosum-up its services in Broadcast, Paging and No-tification as well as Dedicated Control services.

• NBAP - is another control signalling proto-col, which controls the interface resources andproviding the means for Node Bs and RNC tocommunicate. One peer entity of the NBAP re-sides at the Node B and the other at the RNC,which controls the Node B. It also has an inter-face with the RRC protocol to provide RRC, thenecessary information to operate. NBAP mainfunctions are summed up as follows:

3

– Advertises RNC about changes that phys-ical procedures performed at the Node Blevel, could influence the conditions of thelogical resources owned by RNC.

– Establishes and maintains a control connec-tion to initiate set-up and release of dedi-cated user plane connections, i.e., connec-tions to user data transmission.

– Provides Node B with ability to report fail-ure or restoration of a transmission on radiolinks.

• RANAP - is the only signalling protocol definedbetween the UTRAN and CN and it is used byboth CS and PS technologies to access the ser-vices provided by UTRAN. It controls the re-sources between UTRAN and UE, being on topof this interface signalling transport layers. OneRANAP entity resides on the RNC and the otherin the MSC or SGSN (CN elements). It pro-vides the means for the CN to control the es-tablishment, modification and release of the Ra-dio Access Bearers (RABs) between UE and CN.When analyzed its messages, it could be found in-formation relative to relocation of Serving RNC(SRNC) due to UE mobility or set up and releaseof its connections. Paging UEs, signalling due tomobility management and UEs tracing are alsofeatures of RANAP protocol.

• RNSAP - is a control plane protocol provid-ing control signalling across the interface betweenRNCs. It is executed by two RNCs where onetakes the role of SRNC, that handles the connec-tion to the UE and another acts as Drift RNC(DRNC) which may borrow resources from a cer-tain cell when asked by the SRNC. The RNSAPis responsible for bearer management signallingand is used to set up radio links, allowing theSRNC to control those radio links using dedi-cated resources in a Drift RNS (DRNS). Thus,inside this protocol messages, it can be foundinformation relative to radio and mobility sig-nalling between RNSs, including support of han-dover, radio resource control and synchronisa-tion. Summed up, radio link set-up, addition ordeletion as well as measurement reporting andglobal resources management through informa-tion exchange between RNCs, are the main func-tions of this protocol.

• SABP and PCAP are also layer 3 protocolsfrom which messages are collected by GPEH fea-ture but with less relevance in this work. How-ever, as a brief insight, SABP protocol dealswith the communication between RNC and CellBroadcast Centre (CBC) domain from CN. So itdefines cell broadcast information that is trans-mitted to UEs [9]. PCAP protocol deals withcommunication between RNC and Stand-Alone

SMLC (SAS). SAS is a network element, thatcan be integrated in the RNC, which function isto handle positioning measurements and calcula-tion of UEs position. This way, PCAP providessignalling services between RNC and SAS [10].

2.4. GPEH - Event Types

According to the protocols described above, GPEHfeature presents two type of events, the RNC Inter-nal Events and the Inter-node Events. RNC Inter-nal Events are generated internally at specific trig-gering conditions for each event due to either mea-surements coming from nodes and from UE or RNCalgorithm events. As example, the INTERNAL IMSIevent already referred, is triggered every time a newUE establish any type of connection in the RNC cov-erage area. Inter-node Events refers to layer 3 de-scribed protocols. Accordingly, these events can be-longs to the RRC, NBAP, RANAP, RNSAP, PCAPand SABP protocols and only information establishedby GPEH is hold from them, allowing to record spe-cific information as well as the entire protocol messagecontent.

Besides this distinction there common fields to allof them, like the event name and identification.

3. Implementation

This project implementation encompasses the twomain objectives described in Section 1.2. Some usecases were also defined, which results achievement wasa priority. These use cases are the cell footprint thatis a representation in terms of RSCP level of the areascovered by a cell and best server, where it is aimed toshow the areas were a cell is best server, i.e., wheremost of the users is served by that cell. The BestServer use case should also be acquired in terms ofRSCP. Dropped calls detection and location is also aproposed use case.

3.1. Network Events Selection

Cell footprint and best server use cases, concern onRF metrics, specifically the RSCP. To get them, itwas detected an event, the RRC MEASUREMENTREPORT, from the RRC protocol, that is sent byUEs with this metric. Since both situations dependson RSCP, the RRC MEASUREMENT REPORTevent allows the production of both use cases. Thisevent has also important fields that must be collectedin order to use as input to the OTD Geo-positioningAlgorithm.

To identify Dropped Calls a RNC Internal Eventcan be used, the INTERNAL SYSTEM RELEASE.This event is triggered every time one or severalRABs or standalone RRC CONNECTION RE-LEASE (RRC protocol message to disconnect an UE)appears and the release cause is not a normal one.

With such events identification, it is possible to de-velop an application that will take the relevant infor-

4

mation from them and produce the desirable networkperformance results.

3.1.1 Events IMSI Identification

The events identification and association by user, isdone by IMSIs attribution, contained in last ROP file,to events that do not contain this information. In or-der to achieve this objective, it is important to under-stand how this event is generated within the network.INTERNAL IMSI events are triggered when an IMSIis associated to a new UE CONTEXT (UE identifierin the area), at the reception of RANAP COMMONID after a successful RRC connection setup or at thereception of an IMSI in a RANAP RELOCATIONREQUEST. The existence of common fields and inmuch of the time unique, between INTERNAL IMSIevents and the others, like UE CONTEXT and RNCMODULE ID can also help on this association.

3.1.2 Phone Call Organization

Phone calls and other types of communications def-inition, is also of interest in order to trace a user,observing the communication conditions during thatperiod. This procedure is initiated with the RRC pro-tocol where an RRC connection establishment is ini-tiated by the UE that sends a RRC CONNECTIONREQUEST to the RNC. After this, the RNC sendsa RRC CONNECTION SETUP and, if everythingis as it is supposed to, the procedure continues withthe message RRC CONNECTION SETUP COM-PLETE, concluding the RRC connection establish-ment.

To release a connection, the signalling RRC releaseprocedure is used. This procedure is initiated at theRNC side, which sends the message RRC CONNEC-TION RELEASE when the UE state is in agreementwith such situation. When the release message is re-ceived by the UE it answers with the message RRCCONNECTION RELEASE COMPLETE and theprocedure finishes with the UTRAN releasing all theUE dedicated resources.

Another factor that can be used to a Phone Callidentification, after a successful IMSI attribution toevents, is the existence of three unique fields withinevents belonging to a same communication. Thesefields are UE CONTEXT, RNC MODULE ID andIMSI that have equal values within events from asame communication and cannot be repeated in dif-ferent ones, at the same time.

3.2. Application Development

The developed application encompasses three majorsteps. A parsing component where selected traces areread and stored in suitable data structures, a dataflux within OTD Geo-positioning Algorithm compo-nents, supplying all needed data for them to work anda final binning process that will allow a comprehen-sive geographical visualization of the results. Also to

highlight, the application was developed taking intoaccount the already mentioned practices and princi-ples in order to produce an high quality code.

3.2.1 Programming Practices and Principles

Starting by the steps to achieve an high quality devel-opment, Extreme Programming (XP) and S.O.L.I.D.Principle were followed.

Extreme Programming includes Test Driven Devel-opment (TDD) process in which three activities aretightly interwoven: coding, testing, in the form of unittests and design, in the form of refactoring. Unit test-ing refers to a program developed to exercises somespecific part of the source code in order to assure thatthe expected result from it is being achieved; refac-toring consists on improving the internal structure ofan existing program source code, while preserving itsexternal behavior. XP also covers Code Review andPair Programming concepts. The first is a practicewhere after a developer finishes his work another onereview the code. This review consists on searching forbugs or errors, bad code structure, design and tests re-liability. Pair Programming involves having two pro-grammers working at a single machine. One developeroperates the keyboard while the other watches, learn,asks, talks, make suggestions and tries to help on bugavoidance or finding.

While Extreme Programming mainly focus on er-rors and bugs avoidance or early detection, S.O.L.I.D.Principle, besides also contributes for that factor, re-lies on good design and structure of the code. Theprincipal concern here is to have a decoupled andmodular code, by facilitating code changes as wellas features addition. It is also important to facili-tate the comprehension by another developers, whenreading or working with the code. S.O.L.I.D. Prin-ciple is in fact composed by a set of principles thatallows to achieve those targets: Single ResponsibilityPrinciple, Open-Closed Principle, Liskov SubstitutionPrinciple, Interface Segregation Principle and Depen-dency Inversion Principle [11].

3.2.2 Application Components

Data Structures Definition

In order to organize all the information collected fromGPEH, it is important to define well suit data struc-tures to store that information. Four different datastructures, were initially established. All events areconsidered TraceEvent data structures, where onlycommon information to all of them was sored. Fromthis class another two were derived with more spe-cific information. The NbapTraceEvent and RrcMea-sureTraceEvent data structures contain specific infor-mation from its respective events, NBAP RADIOLINK SETUP REQUEST and RRC MEASURE-MENT REPORT. The information collected here iscrucial to the OTD Geo-positioning algorithm and isjoined together in another data structure, the fourth

5

one, called MeasurementReport. So, TraceEvent andMeasurementReport are the main classes and imple-ment the interface IPoint, in order to ”obligates” theexistence of latitude and longitude coordinates fields,and the interface ITimedPoint to the triggering eventtime field existence.

Figure 2: Data Structures Hierarchical Organiza-tion.

IMSI Addition Component

To allow events identification it was followed theknowledge acquired in Section 3.1.1. To accomplishthis task Internal IMSI events were previously loadedfrom ROP and stored. Then, per each event, thefollowing process is done: from IMSI repository, theevents with RNC MODULE ID and UE CON-TEXT fields equals to the ones of the received eventare chosen. After this, time relations were used tocorrectly add the IMSI to the event.

Phone Call Definition Component

In this component, since events already have IMSI atthis stage, it was used the triple identifier approach,with the comparison between IMSI, UE CONTEXTand RNC MODULE ID fields. This way, all eventswith same values for this triple were stored together,as a phone call (or any other communication type).This definition does not need begin or end call events.When, for a sequence of events belonging to a certainIMSI, there is a change in the UE CONTEXT orRNC MODULE ID fields, it means that a differ-ent communication was established by the UE of thatIMSI. With the creation of groups of events with sameIMSI, RNC MODULE ID and UE CONTEXT, dif-ferent phone calls were being collected with the de-sired UE identification.

Geolocation Algorithm Integration

The integration of a Geolocation algorithm is an im-portant step on this work, since it will allow to as-sociate performance metrics to locations. An OTDbased Geolocation algorithm developed at Celfinetwas used [12]. This algorithm is composed by threecomponents, a Geolocation component that worksand locates only MeasurementReport instances, andtwo other components, Smooth and Interpolation,that will help to provide the location to all otherevents.

So, the first step is to feed the Geolocation compo-nent with the MeasurementReport objects previouslycreated. After processed, two sets of MeasurementRe-ports are obtained, the located and non-located ones.Then it is applied the Smooth component to the po-sitioned MeasurementReports to erase time and ve-locity inconsistencies, avoiding absurd or incoherentlocations. The, all events location is got, by interpo-lating the positioned and smoothed MeasurementRe-ports with all the other non-positioned events. Af-ter this process, it does not make sense to continueworking with different types of data structures andaccordingly, a common one was used from this stepon, called NetworkEvent.

Binning Component

The Binning process is a way of work the informa-tion contained in the processed and located traces,with the objective of improve the results geographicalvisualization quality. If all events from ROP were in-dependently represented in a graphical environment,in order to see its location in a map, it would be ahuge mess, since there would be too many points. So,Binning represents a much more efficient way of doingthis representation. This method stands in groupingevents from a certain area and applying a mathemat-ical method (median, mean...) to attribute a param-eter value (depending on the use case to be observed)to that region based on that parameter value in eachevent.

The objective is to divide the map into a grid. Thesquares of the grid have a certain area, defined by theuser. When the Binning method is applied to events,it converts them latitude and longitude coordinatesinto Cartesian ones, indicating in which square of thegrid the event belongs. Let us imagine that there aresix events with the following RSCP values: Event 1:-110 dBm, Event 2: -90 dBm, Event 3: -115 dBm,Event 4: -70 dBm, Event 5: -85 dBm and Event 6:-90 dBm, which respective location is as shown inFigure 3.

If the Binning method is the median, Events 1 and2 will originate a median value of -100 dBm, Event 3of -115 dBm and Events 4, 5 and 6, a median of -85dBm. The result would be as shown in Figure 4.

6

Figure 3: Events Representation Without Binning.

Figure 4: Events Binning Representation.

4. Results

After concluded all the processes, a platform devel-oped in Celfinet, called Labs, was used to geograph-ical representation of the application outputs. It isimportant to highlight that the binning area usedcorresponds to the entire world as a grid, where eachsquare represents an area of 50x50 m2. The data usedto achieve these results is collected from a genericRNC responsible for Node Bs at Lisboa city. It wascollected on April 30, 2015 within 11.30h and 12.15hrepresenting three ROPs.

Although obtained various use cases visualization,here will be focused the ones concerned with the signallevel in terms of RSCP.

4.1. Use Cases Visualization

Using the referred visualization platform and the re-sults from application processing, cell footprint andbest server, in terms of RSCP, use cases were pro-duced, as shown in Figures 5 and 6 respectively.

4.2. Use Cases Results Validation

Drive tests were used as comparison since representsone of the most reliable data from network perfor-mance. However, use cases traces based validation is

Figure 5: Cell Footprint Labs Representation.

Figure 6: Best Server RSCP Labs Representation.

a complex process and difficult to achieve. The num-ber of processed ROPs due to lack of available data,representing only 45 minutes of communications in ageneric day, cannot be representative of the real sce-nario that is verified in Lisbon city. It must also beconsidered that the OTD based Geo-location Algo-rithm used to achieve the events location has an as-sociated positioning error as shown in Table 1. Drivetests also have a problem due to the fact that theyrely on outdoor environment metrics collection, whiletraces data is from both outdoor and indoor envi-ronments. So, even when huge differences are foundbetween the comparison of these two types of data,it does not mean that, in this case, traces process-ing went wrong. To minimize this problem, it wasconsidered that 80% [13] of the traffic is indoor andin general, it represents an average attenuation of 10dBm [14] when compared with drive tests data (out-door).

Table 1: OTD Geo-location Algorithm PositioningError

ResultsOTD Geo-location

AlgorithmUrban

GeolocationError [m]

Median 249.2Mean 290.8

Filter Error[m]

Median 216.1 (∼ -13.3%)Mean 295.6 (∼ -19.6%)

Qualitative and quantitative analysis were per-formed from certain Lisbon areas, most of them gar-

7

dens, in order to avoid as much as possible build-ings and hence, indoor traffic. The best results wereachieved in Jardim da Tapada das Necessidades. Interms of qualitative analysis, in Figure 7, it is possi-ble to see some similarities (although also some dif-ferences) between traces and drive tests trough thegarden. It was noticed some signal degradation in cer-tain areas in both cases but in general, traces seemsto report higher signal degradation.

Figure 7: Best Server RSCP comparison betweentraces (left) and drive tests (right) in Jardim daTapada das Necessidades.

In terms of quantitative analysis, RSCP values ofall binning samples present in the images in the com-parison between drive tests and traces in Jardimda Tapada das Necessidades, were used. Cumula-tive Distribution Functions (CDFs) were produced totraces, drive tests and drive tests with indoor attenu-ation. Figure 8 shows the RSCP trends for the threescenarios. As expected, the difference between drivetests and traces is higher when indoor attenuation isnot considered. On the other hand, when used the ap-proximation with indoor attenuation, the results arereally close. The average RSCP level difference is of1.3 dB - Table 2 - between the two data types. Thisis a good result but how it was explained, more datashould be processed from traces, from an extendedperiod, in order to be completely sure about the re-sults.

Figure 8: RSCP level CDFs from drive tests, drivetests with indoor attenuation and traces in Jardim daTapada das Necessidades.

Table 2: Comparison between Jardim da Tapadadas Necessidades traces and drive tests median andaverage RSCP error values.

Error Comparisonbetween Traces and Drive Tests

Operation[dB]

DriveTests

Drive Tests withIndoor Attenuation

Median 12 4Average 9.33 1.33

4.3. Algorithm Analysis

4.3.1 Processing Time Optimization

From the components developed during this project,Parser is probably the one with more impact in termsof processing time, which was initially more than 1.30h. Some optimization was done reducing this time to14 minutes. Phone call definition through the usageof a unique triple, UE CONTEXT, RNC MODULEID and IMSI was a faster process when compared withthe RRC protocol messages sequence analysis, whichis a more complex method. Substitution of List byDictionary data structures, which presents a O(1) ac-cess complexity against O(N) in Lists, was anotherimportant optimisation. Early events filtering as wellas its information, avoiding useless processing, hard-disk drive accesses reduction and increasing integersusage instead of strings, also contributed to such re-sult.

4.3.2 Succeed Applied Methodologies

All practices already mentioned in terms of code de-velopment and of course, a consciousness of the con-cepts from S.O.L.I.D. Principle, which were carefullyfollowed, allowed to achieve an high quality code aswas desirable.

SonarQube is a tool that allows to measure the codequality, providing four metrics to this evaluation. Ithelps to understand if S.O.L.I.D. Principle practicesand also some of Extreme Programming ones werecorrectly applied. Such metrics have to do with codeprone to bugs appearance, how vulnerable to outsidethreats it is, the code coverage in terms of unit testsand Code Smells. Code Smells is a quality metricthat allows to understand how much degraded is thecode becoming in terms of complexity, confusion andbad structure. These factors, when not fulfilled canalso originate problems and bugs. Examples of suchdegradation are the introduction of duplicated code,uncovered code and too big classes. Such tool resultsare shown in Figure 9.

In terms of Code Coverage, besides not shown, avery good value of 83% of coverage, was obtained.The resulting metrics presented in Figure 9 are greatresults. For example, the 14 vulnerabilities have all todo with ”Console.WriteLine” commands, whose func-tion is print characters in the terminal. It is an op-eration that can be easily erased and its use is most

8

Figure 9: SonarQube Metrics.

of the times for debugging. In terms of Code Smells,174 of them were detected 174, which implies a debtof 4 days. This means that the changes to performin order to erase their existence has a estimation ofcompletion of 4 days. It could seems too much time,but taking into account that this is a 8500 lines codeand comparing with other projects, it is a really goodresult. Finally, duplications are minimal on the pro-gram, existing only 1.8% of them, corresponding to10 blocks.

4.3.3 Modular Code

All the applied programming methodologies and tech-niques, contribute to the creation of a Modular Code.It defends the enforcement of logical boundaries be-tween components, improving decoupled code andminimizing dependencies, what results in easier codemaintainability. With this achievement, modifica-tions in a module or component does not change theremaining code and hence, other components func-tionality. It is possible to add functionalities withoutchanging the ones already developed. Another im-portant feature from modular programming is codereusing, in a way that allows one module to be ap-plied in different situations. New features additionand when bugs were discovered, shows the modularway in which the code is constructed. The conse-quences of modifications are really scarce and the unittests existence allows to detect components behaviourchanges rapidly.

5. Conclusions

This project presented two main problems to work on.Firstly, traces data analysis was done, to understandwhich type of metrics of network performance can betaken from them, in order to remotely analyse thenetwork and the service quality that is being providedto costumers. Besides avoiding the need to be in thefield, this kind of analysis allow to save money by theoperators, which need to pay people and buy softwareto have someone in the field collecting such metrics.

Secondly, the challenge was to develop an applica-tion that processes all the relevant information fromtraces. The application should make use of Geolo-cation algorithms, which determine the location ofthe collected data, producing network performance

indicators that are associated to geographical posi-tions. KPIs are also interesting measures to be ac-quired from such processing. The main objective wasnot only the application development but also to op-timise it as much as possible. This optimization isdesirable in order to reduce the processing time sincethe ideal scenario was to get data processed from eachgroup of traces in 15 minutes, which is the period ofeach group reception. The fact that this applicationwill work as a basis to future features addition, de-mands an high quality code production. Code robust-ness and good structure, bugs and errors avoidance,ease on its detection and future usage by other devel-opers, for both taking part of the application featuresor to add new ones, required several programmingpractices and principles to be followed.

Starting with the protocol analysis, a set of usecases was initially defined. However, only cell foot-print, best server RSCP and dropped call use caseswere discussed here. After understanding the proto-cols organization in UMTS and analyzing the mes-sages collected by the GPEH feature, it was possi-ble to detect which ones fit the mentioned use cases.An interesting fact is that usually, only one messagefrom the protocol is necessary to construct the usecase. That was confirmed in the dropped call one,where the event INTERNAL SYSTEM RELEASEdetection allows its immediate identification. To theremaining use cases, the event MEASUREMENTREPORT can be used since it has all the necessaryfields to achieve the desirable results. Traces analysisalso helped in events IMSI attribution. This is rele-vant, because allowed to define a full communicationfrom a generic UE and tracing it, as well. For thefull communication definition it was concluded thatit makes more sense to use the unique triple IMSI,UE CONTEXT and RNC MODULE ID to associateall events belonging to the same communication.

Concerning the application development, defineduse cases production was accomplished, as shown inFigures 5 and 6. In terms of these results validation,it is difficult to get reliable indicators due to the lim-ited number of processed data along with comparablesituations from real world in the specific conditionswhere these results were obtained. Besides limita-tions in the comparisons, there is also the positioningerror, from the Geolocation algorithm, which is notdirectly part of this thesis but influences the results.However, in terms of best server RSCP, some com-parisons were performed with drive tests even thoughfrom different dates. Some coherence was found inthe comparisons, in both qualitative and quantita-tive analysis. In Tapada das Necessiades, consider-ing drive tests with indoor attenuation, only 1.33 dBand 4 dB difference was verified in comparison withprocessed traces, for the average and median valuesrespectively. Nonetheless, more data is needed in or-der to assert the results validity. This missing datarelies in higher number of processed ROP but also inexternal information, that allows to get a real world

9

use case to proceed to such verifications.In terms of code quality, due to tools, practices and

principles followed, a modular code was built, with noduplications, decoupled and tested. All the principlesdetailed during this document are visible in the code.This situation contributes to a better understandingby other developers when using the application, toimprove it or just to use it and get results. Featuresaddition is simplified due to either modular code ortests existence, which contributes to bugs avoidancewhen changes are performed. The step that probablyis farther from what was desirable, is the processingtime of the application. Besides the parser compo-nent, which got a considerable optimisation work, go-ing down from one hour and a half processing time tofourteen minutes, the Geolocation algorithm compo-nents take too long to finish, resulting in almost twohours and forty five minutes to complete one ROPprocessing. However, this time is relative since it de-pends on the number of events to process and has agreat dependence of the workstation where the appli-cation is running.

This project allowed the creation of a framework totraces processing and analysis. It was developed in away that easily grants the addition of new features,like new events processing, new use cases, new Geolo-cation algorithms and its usage with other telecom-munication technologies, 2G and LTE, or with tracesfrom different vendors.

References

[1] Ole Grondalen Olav Osterbo. Benefits of self-organizing networks (son) for mobile operators.Journal of Computer Networks and Communica-tions, Volume 2012, September 2012. Article ID862527.

[2] Dr. Shantharam Nayak Shankar N. Perfor-mance management in network management sys-tem. International Journal of Science and Re-search (IJSR), 4:2505–2507, May 2015. PaperID: SUB154796.

[3] Thomas Ron Webber Al. Key Performance In-dicators - Measuring and Managing the Maite-nance Function. IVARA - Work Smart, 935 Shel-don Court, Burlington Ontario. Canada. L7L5K6, 11 2005.

[4] 3GPP, 650 Route des Lucioles - Sophia AntipolisValbonne - FRANCE. ”3GPP TR 32.814 V7.0.0(2007-03) 3rd Generation Partnership Project;Technical Specification Group Services and Sys-tem Aspects; Telecommunication management;UTRAN and GERAN Key Performance Indica-tors (KPI) (Release 7)”, 2007.

[5] ETSI, 650 Route des Lucioles - Sophia AntipolisCedex - FRANCE. ”ETSI TS 132 631 V4.0.0(2001-06) Universal Mobile Telecommunications

System (UMTS); Telecommunication Manage-ment; Configuration Management; Generic net-work resources IRP: requirements (3GPP TS32.631 version 4.0.0 Release 4)”, 06 2001.

[6] 3GPP, 650 Route des Lucioles - Sophia An-tipolis Valbonne - FRANCE. ”3GPP TS32.600 V10.0.0 (2010-06) 3rd Generation Part-nership Project; Technical Specification GroupServices and System Aspects; Telecommunica-tion management; Configuration Management(CM); Concept and high-level requirements (Re-lease 10)”, 06 2010.

[7] Ericsson. General Performance Event Handling- RNC, 11 2014.

[8] ETSI, 650 Route des Lucioles F-06921 SophiaAntipolis Cedex - FRANCE. ”3GPP TS 25.331V14.1.0 (2016-12) 3rd Generation PartnershipProject; Technical Specification Group Radio Ac-cess Network; Radio Resource Control (RRC);Protocol Specification (Release 14)”, 14.1.0 edi-tion, 12 2016.

[9] 3GPP, 650 Route des Lucioles - Sophia Antipo-lis Valbonne - FRANCE. ”3GPP TS 25.419V13.0.0 (2015-12) 3rd Generation PartnershipProject; Technical Specification Group Radio Ac-cess Network; UTRAN Iu-BC Interface: ServiceArea Broadcast Protocol (SABP) (Release 13)”,12 2015.

[10] 3GPP, 650 Route des Lucioles - Sophia Antipo-lis Valbonne - FRANCE. ”3GPP TS 25.453V13.1.0 (2016-03) 3rd Generation PartnershipProject; Technical Specification Group Radio Ac-cess Network; UTRAN Iupc interface Position-ing Calculation Application Part (PCAP) sig-nalling (Release 13)”, 03 2016.

[11] Robert C. Martin (”Uncle Bob”). The prin-ciples of ood. Online, 05 2015. Availableat: —http://butunclebob.com/ArticleS.

UncleBob.PrinciplesOfOod.

[12] P. Vieira N.O. Silva N. Fernandes A. RodriguesL. Varela. Improving Accuracy for OTD Based3G Geolocation in Real Urban/Suburban En-vironments. 17th International Symposium onWireless Personal Multimedia Communications(WPMC2014), 2014.

[13] Nokia. Infographic: In-building wireless forall. Insight Nokia e-magazine, 09 2014.Available at: https://insight.nokia.com/

infographic-building-wireless-all.

[14] Bahreini Y. Siwiak K. ”Radiowave Propagationand Antennas for Personal Communications”.Artech House, 3rd edition, 2007.

10