Development of a tool for GSM networks performance...

Final Degree Thesis

Development of a tool for GSM networksperformance analysis and evaluation

Telecommunications Engineering

Author: Cristina Parra Fernandez

Supervisor: Josep Paradells Aspas

Year: 2013

Acknowledgements

First, I would like to thank Josep Paradells Aspas, the director of this thesis, and the WirelessNetworks Group for giving me the opportunity to carry out my project. I also would like tothank my workplace colleagues for making of these months such a good experience with theircompany. And, finally, thanks to all who have had to bear me during this time.

iii

Resum

Les comunicacions mobils han experimentat un gran creixement durant els ultims anys a lanostra societat i aquest segueix augmentant. Per tant, es important disposar d’una xarxa ca-pac de proporcionar prou capacitat i una qualitat de servei mınima. Existeixen lleis per tal deregular les condicions mınimes de la qualitat de servei oferta pero, normalment, els informesper acreditar aquests mınims els fan les mateixes operadores. Com a consequencia, els resultatspoden no ser del tot fiables sobretot quan trobem usuaris que no perceben la qualitat de serveique els operadors diuen oferir.

Aquest projecte estudia els protocols implementats per diverses operadores i intenta propor-cionar un sistema d’avaluacio interactiu on l’usuari final es capac de realitzar mesures de laxarxa. Per aconseguir aquest objectiu s’ha desenvolupat una aplicacio en llenguatge Python ientorn Linux. Aquesta aplicacio s’executa des d’un ordinador despres que s’hagi capturat traficde senyalitzacio GSM. Com a resultat obtenim Indicadors Clau de Rendiment de la xarxa estu-diada. Finalment, estenent l’us de l’aplicacio en el temps i sobre prou territori, seria possibleproveir els parametres de qualitat tambe publicats per les operadores i avaluar el seu funciona-ment.

Tant l’estudi dels protocols com l’eina desenvolupada estan pensats per ser utilitzats tambeen docencia.

iv

Resumen

Las comunicaciones moviles han experimentado un fuerte crecimiento en los ultimos anos ennuestra sociedad y este sigue aumentando. Por lo tanto, es importante disponer de una redcapaz de proporcionar suficiente capacidad y una calidad de servicio mınima. Aunque existenleyes para regular las condiciones mınimas de la calidad de servicio ofertada, los informes paraacreditar estos mınimos suelen estar hechos por los propios operadores. En consecuencia, losresultados pueden no ser del todo fiables sobretodo cuando nos encontramos con usuarios queno perciben la calidad de servicio que los operadores dicen ofrecer.

Este proyecto estudia los protocolos implementados por distintos operadores e intenta propor-cionar un sistema de evaluacion interactivo donde el usuario es capaz de realizar medidas de lared. Para conseguir este objetivo, se ha desarrollado una aplicacion en lenguaje Python y en-torno Linux. Esta aplicacion se ejecuta desde un ordenador despues de haber capturado traficode senalizacion GSM. Como resultado se obtienen Indicadores Clave de Rendimiento de la redestudiada. Finalmente, extendiendo el uso de la aplicacion en el tiempo y sobre suficiente terri-torio, serıa posible proporcionar parametros de calidad tambien publicados por los operadoresy evaluar su funcionamiento.

Tanto el estudio de los protocolos como la aplicacion desarrollada estan pensados para serutilizados tambien en docencia.

v

Abstract

Mobile communications have had an strong growth in our society in the recent years and it keepsincreasing. Therefore, it is important to dispose of a network able to provide enough capacityand a minimal quality performance. There are laws to regulate the minimal conditions of theoffered quality of service but, normally, the reports to prove these minimal conditions are madeby the operators themselves. Thus, might make these measures not much reliable especiallywhen some users do not perceive the quality that operators claim to offer.

The present work studies the protocols implemented by several operators and tries to providean interactive evaluation system where the customer is able to perform the measures over thenetwork. To achieve this goal, an application will be implemented in Python language under aLinux environment designed to work within a computer, after GSM signaling traffic has beencaptured. As a result the application will return some Key Performance Indicators of the studiednetwork. Finally, extending the usage of this application throughout enough range and periodtime, it would be possible to provide quality parameters also published by operators and toevaluate their performance.

Both the study of the protocols and the application developed are intended to be used alsoin teaching.

vi

Contents

1 Introduction 1

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Objectives and motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Structure of the report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Background: GSM 4

2.1 General architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1 Mobile Station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.2 Base Station Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.3 Network and Switching Subsystem . . . . . . . . . . . . . . . . . . . . . . 6

2.1.4 Operation and Support Subsystem . . . . . . . . . . . . . . . . . . . . . . 6

2.2 GSM logical channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.1 Traffic Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.2 Signaling channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Signaling in the Air interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.1 Layer 1: Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.2 Layer 2: Data Link Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.3 Layer 3: Network Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Design and development 25

3.1 General scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Tools and platforms used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2.1 Mobile Terminal: Samsung SIII . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2.2 MicroSIMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2.3 xgoldmon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2.4 Wireshark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.5 Programming language: Python . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.6 SPE Python IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4 Protocols analysis 28

4.1 Signaling before a procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2 Connection establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.3.1 Attach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.3.2 Detach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.3.3 MOC and MO-SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

viii

4.3.4 MTC and MT-SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.3.5 MT-SMS in a call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.3.6 Nonsynchronized intra-BSC handover or intra-MSC handover . . . . . . . 414.3.7 Synchronized intra-BTS handover . . . . . . . . . . . . . . . . . . . . . . 424.3.8 Signaling during a communication . . . . . . . . . . . . . . . . . . . . . . 43

4.4 Connection release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.5 Key Parameter Indicators (KPIs) . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.5.1 General delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.5.2 Particular times or delays . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.5.3 Measurement parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5 Algorithm and results 485.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.3 Test and results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.3.1 Study of the results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.3.2 Capture 1: Movistar Attach . . . . . . . . . . . . . . . . . . . . . . . . . . 605.3.3 Capture 2: Orange MT-SMS . . . . . . . . . . . . . . . . . . . . . . . . . 635.3.4 Capture 3: Vodafone MT-SMS in a MOC . . . . . . . . . . . . . . . . . . 67

6 Conclusions 716.1 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

A Source Code 74

ix

List of Figures

2.1 GSM network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 GSM logical channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 GSM Air interface layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.1 GSM Standard MO connection establishment . . . . . . . . . . . . . . . . . . . . 29

4.2 MO connection establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.3 GSM Standard MT connection establishment . . . . . . . . . . . . . . . . . . . . 31

4.4 MT connection establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.5 GSM Standard attach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.6 Attach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.7 Detach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.8 GSM Standard MOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.9 MOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.10 GSM Standard MO-SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.11 MO-SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.12 GSM Standard MTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.13 MTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.14 GSM Standard MT-SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.15 MT-SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.16 MT-SMS in a call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.17 Nonsynchronized intra-BSC handover or intra-MSC handover . . . . . . . . . . . 42

4.18 GSM Standard synchronized intra-BTS handover . . . . . . . . . . . . . . . . . . 42

4.19 Synchronized intra-BTS handover . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.20 GSM Standard signaling during a communication . . . . . . . . . . . . . . . . . . 43

4.21 Signaling during a communication . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.22 Connection release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.1 Example of a capture displayed in Wireshark . . . . . . . . . . . . . . . . . . . . 48

5.2 Map of the BTS surrounding the campus . . . . . . . . . . . . . . . . . . . . . . 53

5.3 Movistar attach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.4 output.txt (Movistar attach) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.5 Receiving level and Mean BER of the serving cell (Movistar attach) . . . . . . . 62

5.6 Orange MT-SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.7 Receiving level and Mean BER of the serving cell (Orange MT-SMS) . . . . . . . 64

5.8 Receiving level of the neighbour cells (Orange MT-SMS) . . . . . . . . . . . . . . 65

5.9 output.txt (Orange MT-SMS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.10 Vodafone MT-SMS in a MOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

x

5.11 output.txt (Vodafone MT-SMS in a MOC) . . . . . . . . . . . . . . . . . . . . . 685.12 Receiving level and Mean BER of the serving cell (Vodafone MT-SMS in a MOC) 695.13 Receiving level of the neighbour cells (Vodafone MT-SMS in a MOC) . . . . . . 70

6.1 Mobile applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

xi

List of Tables

5.1 Coverage related to signal strength . . . . . . . . . . . . . . . . . . . . . . . . . . 505.2 RXQUAL values and corresponding BER . . . . . . . . . . . . . . . . . . . . . . 505.3 ARFCN Table for common GSM systems . . . . . . . . . . . . . . . . . . . . . . 515.4 Establishment time comparative . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.5 Connection establishment KPIs comparative . . . . . . . . . . . . . . . . . . . . . 545.6 Attach KPIs comparative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.7 Detach KPIs comparative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.8 MOC KPIs comparative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.9 MO-SMS KPIs comparative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.10 MTC KPIs comparative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.11 MT-SMS KPIs comparative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.12 MT-SMS in a call KPIs comparative . . . . . . . . . . . . . . . . . . . . . . . . . 595.13 Serving cell KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

xii

Acronyms

ABM Asynchronous Balanced ModeAGCH Access Granted ChannelAuC Authentication CenterAUTN Authentication TokenBCCH Broadcast Control ChannelBCCH-FREQ-NCELL BCCH frequency of a neighbour cellBCD Binary Coded DecimalBSC Base Station ControllerBSIC Base Station Identity CodeBSS Base Station SubsystemBTS Base Transceiver StationCBCH Cell Broadcast ChannelCCCH Common Control ChannelsCEPT Conference Europeenne des Administrations des Postes et des

TelecommunicationsCKSN Ciphering Key Sequence NumberCM Connection ManagementCM-CC Call Control (CM Sublayer)CM-SMS Short Message Service (CM Sublayer)CP Control ProtocolDTAP Direct Transfer Application PartEIR Equipment Identity RegisterEPS Evolved Packet SystemETSI European Telecommunications Standard InstituteFACCH Fast Associated Control ChannelFCCH Frequency Control ChannelFDMA Frequency Division Multiplex AccessGMSC Gateway Mobile Services Switching CenterGPRS General Packet Radio ServiceGSM Global System for Mobile CommunicationsHDLC High level Data Link ControlHLR Home Location RegisterHSN Hopping Sequence NumbersIMEI International Mobile Equipment IdentityIMEISV International Mobile station Equipment Identity and Software

VersionIMSI International Mobile Subscriber IdentityKPI Key Parameter IndicatorLA Location AreaLAC Location Area CodeLAI Location Area IdentificationLAPD Link Access Procedure for D ChannelLAPDm Link Access Procedure for Dm ChannelLTE Long Term EvolutionM2M Machine to Machine

xiii

MAIO Mobile Allocation Index OffsetMCC Mobile Country CodeME Mobile EquipmentMM Mobility ManagementMNC Mobile Network CodeMO Mobile OriginatedMOC Mobile Originated CallMO-SMS Mobile Originated Short Message ServicesMS Mobile StationMSC Mobile Switching CenterMT Mobile TerminatedMTC Mobile Terminated CallMT-SMS Mobile Terminated Short Message ServicesNCH Notification ChannelNMS Network Management SystemN(R) Received Sequence NumberN(S) Send Sequence NumberNSS Network and Switching SubsystemOMC Operation Maintenance CenterOSS Operation and Support SubsystemPCH Paging ChannelPDU Protocol Data UnitsPLMN Public Land Mobile NetworkPSTN Public Switched Telephone NetworkQoS Quality of ServiceSABM Set Asynchronous Balanced ModeSACCH Slow Associated Control ChannelSGSN Serving GPRS Support NodeRAC Routing Area CodeRACH Random Access ChannelRAI Route Area IdentificationRAND Random numberRFN Reduced Frame NumberRP Reply PathRPDU Relay transfer Protocol Data UnitsRR Radio Resource managementRRC Radio Resource ControlRXLEV Received signal level of the serving cellRXLEV-CELL received signal level of a neighbour cellRXQUAL Received Signal QualitySACCH Slow Associated Control ChannelSCH Synchronization ChannelSDCCH Stand-alone Dedicated Control ChannelSETSI Secretarıa de Estado de Telecomunicaciones y para la Sociedad de

la InformacionSIM Subscriber Identity ModuleSM-SC Short Message Service Center

xiv

SME Short Message EntitySMS Short Message ServicesSMS-GMSC SMS Gateway Mobile Switching CenterSM-CP Short Message Control ProtocolSM-RP Short Message Relay ProtocolSM-TP Short Message Transport ProtocolSRES Signed ResponseSVN Software Version NumberTA Timing AdvanceTBF Temporary Block FlowTCH Traffic ChannelTDMA Time Division Multiplex AccessTLLI Temporal Logical Link IdentifierTMSI Temporary Mobile Subscriber IdentityTP Transfer ProtocolUMTS Universal Mobile Telecommunications SystemUSRP Universal Software Radio PeripheralXRES Expected User ResponseVLR Visited Location RegisterWCDMA Wideband Code Division Multiple Access

xv

Chapter 1

Introduction

1.1 Introduction

Mobile communications have become essential in our society. The firsts Global System for Mo-bile Communications (GSM) networks were introduced in Europe in 1992 and, in two decades,their usage have experienced a strong growth both in the number of users and in the assortmentof services provided.

GSM system is still widely used even though the development of 3G and 4G technologies.Some operators are considering to reuse the bands assigned for GSM to Long Term Evolution(LTE) systems. However, GSM is still the system that offers the best coverage range and can bevery useful for low consumption applications such as Machine to Machine (M2M) which involvestechnologies that allow wired and wireless systems to communicate with other devices of thesame type.

There is an standard for GSM but, as an standard, it only contains the recommended im-plementation of GSM and defines several optional parameters and procedures. Therefore, everyoperator performs GSM with multiple variations. With this situation, it seems useful to havea kind of a guide of the actual protocols implemented by the operators in case someone has towork with GSM traffic. This project tries to provide this sort of guide for the operators available.

Another important issue is that a network able to support all its customers and ensure a minimalquality performance must be provided. To prove that this service is provided, operators mustpublish Key Parameter Indicators (KPIs) from their networks so certification agencies can cer-tify them. In Spain, the order ITC/912/2006 regulates the Quality of Service (QoS) conditionsof the communication services and the information related to the QoS offered by operators canbe found at the Secretarıa de Estado de Telecomunicaciones y para la Sociedad de la Informacion(SETSI)1. Even with this regulation, sometimes users may not perceive the same quality thatthe operators claim to provide. In this respect, the present project tries to provide an interactivemeasurement method where the customer can perform these measures.

1Publicacion niveles calidad de servicio from Ministerio de Industria, Energıa y Turismo [1]

1

1.2 Objectives and motivation

The aim of this project is, first of all, to understand the GSM signaling and its adaptation withthe 3G - and now also 4G - technology coexistence implemented by several operators. As aresult, an study of all procedures for each operator should be carried out. This will permit toanalyse more easily GSM signaling captures and might be useful in teaching.

In the second place, this project tries to provide a tool which makes possible for users to evaluatethe service perceived at their phones, in other words, to prove the QoS actually perceived byGSM customers.

The last objective is to evidence that using this tool it should be possible to perform sev-eral measures from different operators and obtain a comparison between the service offered bythese operators. Performing enough captures covering the network range would also be possibleto evaluate the performance of GSM networks depending on the operator. This tool could alsohelp students to get an idea of the average service offered.

It should be remarked that comparing operators performance is not an objective but demonstratethat this could be done with the tool developed.

1.3 Structure of the report

This report is structured in six chapters. In the first place, Chapter 1: Introduction presentsa general view of the project with a brief explanation of the GSM mobile communications andits current situation. Also, this chapter explains the motivation, the objectives and the structureof the project.

In the second place, some GSM technology is introduced in Chapter 2: Background: GSM.First with a short explanation of GSM and its structure, then presenting the logical channelsused in GSM and, finally, focusing on the Air interface and the signaling protocols of the Lay-ers 2 and 3. However, any further explanation of GSM theory will be explained later on if needed.

Next, Chapter 3: Design and development introduces the general scenario of the projectand also a brief overview of the hardware and software used.

Based in the captures from GSM signaling traffic taken with the software presented on theprevious chapter, Chapter 4: Protocol analysis exposes and studies the protocols used bythe operators. The recommended implementations defined on the GSM standard are explainedand then these are compared with the ones observed in the captures in order to know the vari-ations introduced by the operators. Later on, this chapter defines a set of KPIs that could beused to evaluate the behaviour of the network.

The usage method of the program developed is explained in Chapter 5: Algorithm and re-sults. It is also explained how the algorithm is implemented. In addition, this chapter includessome GSM theory in order to understand some of the parameters used in the algorithm. Then,it follows a study of the mean results of testing the script for each procedure and operator and a

2

particular analysis of a capture for each operator in order to check the performance of the script.

To sum up, Chapter 6: Conclusions takes out the conclusions of the project and also pro-poses possible future work related.

Finally, the entire code from the script developed can be found in Appendix A: SourceCode.

3

Chapter 2

Background: GSM

Before the implementation of the GSM system, the mobile networks implemented in differentcountries were normally incompatible. That is why the Conference Europeenne des Admin-istrations des Postes et des Telecommunications (CEPT) created the Groupe Special Mobilecommitte in 1982 in order to develope a standard for digital mobile communications. The GSMgroup became a technical committee of the European Telecommunications Standard Institute(ETSI) after its founding in 1989. The official start of the GSM networks was in 1992.

GSM was intended to be an international system and it is considered a 2G system, in otherwords, a completely digital system. It uses a cellular structure whose basic idea is to partitionthe available frequency range and to assign only parts of the complete frequency spectrum toany Base Transceiver Station (BTS). Consequently, it is possible to reduce the range of a basestation in order to reuse the limited frequencies as often as possible. On the other hand, thisreuse of frequencies presents some drawbacks:

• Increasing the number of BTS increases the cost of infrastructure and access lines.

• As a mobile system, it must support handover.

• The networks have to know the approximate location of each Mobile Station (MS) in orderto deliver an incoming call.

• To assure the points above, the system requires a more extended signaling than fixednetworks.

In the beginning, GSM traffic was almost exclusively due to speech communications, however,the Short Message Services (SMS) soon became extremely popular.

2.1 General architecture

A GSM network can be divided into four main parts as shown in Figure 2.1. Although thepresent project focuses on the communication between the MS and the BTS, here is a briefexplanation of the GSM network architecture:

4

Figure 2.1: GSM network

2.1.1 Mobile Station

The MS consists of the Mobile Equipment (ME) and the Subscriber Identity Module (SIM).Sometimes it is considered as a part of the Base Station Subsystem (BSS).

Each Mobile Equipment has a unique International Mobile Equipment Identity (IMEI) numberwhile, on the other hand, each SIM has a unique International Mobile Subscriber Identity (IMSI)number.

The SIM determines the directory number and the calls billed to a subscriber and also per-mits access to a particular network. Physically, it is a chip which the user inserts in the MEand contains algorithms used for authentication and subscriber information. It communicatesdirectly with the Visitor Location Register (VLR) and indirectly with the Home Location Reg-ister (HLR). Nowadays, there are also MicroSIM cards and even NanoSIM cards. They hold thesame amount of data as regular SIM cards, the only difference is their size each time closer tothe chip size.

2.1.2 Base Station Subsystem

The BSS provides the air interface connectivity between the MS and the Network and SwitchingSubsystem (NSS) and is responsible for the transmission and reception. This subsystem is alsoassociated with channel management, transmission functions and radio link control.

The BSS consists of both BTS and Base Station Controller (BSC). A BTS contains trans-mitter and receiver equipment as well as few components for signal and protocol processing. Forinstance, power control, ciphering and error protection coding. Several BTS are controlled byone BSC.

5

On the other hand, the essential control and protocol intelligence resides in the BSC. Its func-tions include protocol functions for radio channel allocation, channel set up and management ofhandovers.

2.1.3 Network and Switching Subsystem

The NSS controls several BSSs and its main function is to manage the communication betweenmobile users and other users performing call processing and subscriber related functions. Itconsists of several systems described bellow:

• The Mobile Switching Center (MSC) routes all calls and provides management functionssuch as allocation and administration of radio resources for the mobility of the users.

• The Short Message Service Center (SM-SC) supports the sending and reception of textmessages.

• The Gateway Mobile Services Switching Center (GMSC) interconnects the GSM networkand the PSTN. It can access the HLR for routing assistance.

• The SMS Gateway Mobile Switching Center (SMS-GMSC) does the same function as theGMSC but for short message services. It stores temporarily incoming SMS and, if thereceiver is not available, queues them for retry.

• The HLR database has a record for all subscribers registered with a network operator. Itstores permanent data about subscribers, for instance, each user’s telephone number, ser-vice subscriptions, location, permissions and authentication data. This register is locatedwithin the MSC.

• The VLR stores only part of the subscriber data in the HLR and only while this subscriberroams in the VLR area. Its aim is not to overload the HLR and is also located within theMSC.

• The Authentication Center (AuC) is a register which stores and/or generates confidentialdata and keys in order to authenticate and authorize services access.

• The Equipment Identity Register (EIR) stores a list of GSM terminals unique identifiers,IMEIs. Since the identities of a subscriber and its ME are separate, it would be easy tosteal GSM mobile telephones. In order to discourage these thefts, the EIR database canbar an IMEI if the terminal is reported as stolen.

2.1.4 Operation and Support Subsystem

The Operation and Support Subsystem (OSS) is composed by the system software and theOperation Maintenance Center (OMC) which allows to monitor GSM systems. This subsystemis connected to components of the BSS and the NSS and also controls the traffic load of theBSS.

6

2.2 GSM logical channels

Later on, we will discuss about physical and logical channels. Physical channels are definedin frequency and time domains, on the other hand, logical channels are mapped on physicalchannels and give a function to these physical channels. Logical channels can be divided intoTraffic Channels (TCH) and Signaling Channels.

Figure 2.2: GSM logical channels

2.2.1 Traffic Channels

These channels transmit voice and data traffic but any control information. There are twomodes of operation in TCH: full rate (TCH/F, 22.8 Kbps) or half rate (TCH/H, 11,4 Kbps).In the latter, the channel is split into two half rate channels which can be assigned to differentsubscribers.

2.2.2 Signaling channels

In order to control and manage a cellular network, a lot of signaling is needed. Depending onits aim, signaling channels are divided into three groups.

Broadcast Channels (BCH)

These are downlink channels used by the BSS to broadcast common information to all MS in acell. This group includes three channels:

• Broadcast Control Channel (BCCH): this channel broadcasts the organization of the radionetwork. That is to say, radio channel configuration, synchronization information andregistration identifiers.

7

• Frequency Correction Channel (FCCH): this channel broadcasts information about cor-rection of the frequency used. It is only visible in Layer 1.

• Synchronization Channel (SCH): this channel broadcasts information to identify a BTS -such as the Base Station Identity Code (BSIC) - and for frame synchronization - such asthe Reduced Frame Number (RFN) -. It is also only visible in Layer 1.

Common Control Channels (CCCH)

This group is in charge of access management functions and includes five channels:

• Random Access Channel (RACH): this is an uplink channel accessed by MS using slottedAloha to ask for a dedicated channel.

• Access Grant Channel (AGCH): this is a downlink channel used to assign an Stand aloneDedicated Control Channel (SDCCH) or a TCH to a MS.

• Paging Channel (PCH): this is also a downlink channel used for paging to find a MS inparticular.

• Notification Channel (NCH): this is a downlink channel used to inform MS about incominggroup and broadcast calls.

• Cell Broadcast Channel (CBCH): this channel broadcasts the messages of the SMS CellBroadcast, sharing a physical channel with the SDCCH.

Dedicated Control Channels (DCCH)

This group contain three bidirectional channels:

• Stand alone Dedicated Control Channel (SDCCH): is a dedicated signaling channel usedfor signaling between the MS and the BSS when there is no active TCH. This channel isrequested on the RACH and assigned on the AGCH.

• Slow Associated Control Channel (SACCH): is always assigned and used with a TCH oran SDCCH. This channel carries information for the correct radio operation. When thereis no signaling data to transmit, the MS sends a Measurement Report message.

• Fast Associated Control Channel (FACCH): this channel is also assigned in connectionwith a TCH as an additional bandwidth for signaling.

2.3 Signaling in the Air interface

The Air interface is an essential part in any mobile communication and also has a fundamentalrole in the quality of service offered.

GSM stack is a layered architecture as it can be seen in the Figure 2.3. Signaling at theAir interface is mainly controlled by Layer 3, Network Layer. Layers 1 and 2, Physical and DataLink Layer, provide the mechanisms for the protected transmission of signaling messages senton Layer 3.

8

Figure 2.3: GSM Air interface layers

2.3.1 Layer 1: Physical Layer

Layer 1 is the physical connection between the MS and the BTS and includes all techniquesand mechanisms to perform this connection. In addition, it can also include signal processingfunctions. This layer combines frequency and time multiplexing - Frequency Division MultiplexAccess (FDMA) and Time Division Multiplex Access (TDMA) - to provide logical channels.FDMA divided the frequency band into carriers or channels of 200 kHz while TDMA divideseach channel into 4,615 ms frames and each of them into eight timeslots.

2.3.2 Layer 2: Data Link Layer

Layer 2 establishes a data link on the logical channels to allow reliable transmission of signal-ing messages on Layer 3. Signaling used in Layer 2 is Link Access Procedure for Dm Channel(LAPDm), a modified version of Link Access Protocol for D Channel (LAPD) for GSM Air inter-face similar to High level Data Link Control (HDLC). Moreover, its functions include organizingLayer 3 information into frames, sequence control to assure the frames order and detecting errorson a data link. Here follows a brief explanation of the different LAPDm frames:

• Information Frames (I): they transport user data from the network layer and include flowand error control information on the SDCCH and the FACCH. These frames are acknowl-edged by the receiver explicitly with a supervisory frame or implicitly with another infor-mation frame. To perform this flow control, these frames include the parameters ReceivedSequence Number (N(R)) and Send Sequence Number (N(S)). The sender increments N(S)once the message is sent whereas the receiver checks if the received N(S) matches with itsN(R) value and then increments N(R).

• Supervisory Frames (S): are used for flow and error control when there is no data to besend. These frames serve to control the connection - initialize, disconnect and reset - aswell as the retransmission of information frames during data transfer.

◦ Receiver Ready (RR): Acknowledges that an I frame has been received sending theN(R) value.

9

◦ Receiver Not Ready (RNR): informs that no more I frames can be accepted. Thetransmitter will have to wait for an RR frame.

◦ Reject frame (REJ): indicates a transmission error and which is the first I frame tobe resend.

• Unnumbered Frames (U): are unacknowledged frames used to exchange session manage-ment and control information between connected devices.

◦ Set Asynchronous Balanced Mode frame (SABM): serves to initiate a Layer 2 con-nection.

◦ Request Disconnect frame (RD): serves to take a Layer 2 connection out of service.

◦ Unnumbered Acknowledge frame (UA): is used to answer a SABM frame or a RDframe. It acknowledges that a Layer 2 connection is initiated or taken out of service.

◦ Unnumbered Information frame (UI): is used to broadcast common control messagesand also messages sent on the SACCH.

2.3.3 Layer 3: Network Layer

This Layer contains all the functions to establish, maintain and terminate mobile connections aswell as control functions for additional services. Messages in Layer 3 are divided into differentsublayers, namely, Radio Resource management (RR), Mobility Management (MM) and Con-nection Management (CM).

Our purpose is not to explain the entire GSM system, but, since later we will study the ex-change of messages in the Air Interface, it is necessary to include the following list that detailsall the information carried by the messages. There are more messages defined in the standardthat the ones include in this list, that is because only the messages that have been captured areincluded. Several concepts will be referenced as it would be too dense and extensive to explainthem all in the present memory.

Radio Resources management messages (RR)

The RR sublayer is in charge of managing the logical as well as the physical channels on the Airinterface.

Paging messages:

• Paging Request Type 1:Downlink message sent on the PCH up to two MSs to trigger channel access. It includes:

◦ Page mode

◦ Channels needed

◦ Mobiles identity

• Paging Request Type 2:Downlink message sent on the PCH up to two or three MSs to trigger channel access. Twoof the MSs are identified by their Temporary Mobile Subscriber Identity (TMSI) and thethird by its TMSI or IMSI. It includes:

10

◦ Page mode

◦ Channels needed


• Paging Request Type 3:Downlink message sent on the PCH to four MSs to trigger channel access. All the mobilesare identified by their TMSI). It also includes:

◦ Page mode

◦ Channels needed


• Paging Response:Uplink message sent on the SDCCH in response for the paging request message establishingthe main signaling link. It includes:

◦ Ciphering Key Sequence Number (CKSN): a brief explanation of CKSN can be foundin GSM Networks: Protocols, Terminology and Implementation (p. 332) [2].

◦ Mobile Station Classmark 2: information element that provides the network withinformation concerning aspects of both high and low priority of the MS equipment.1


It includes a layer 2 SABM U Frame. The network acknowledges this connection with adownlink Paging Response message plus a layer 2 UA Frame.

Channel establishment messages:

• Immediate Assignment:Downlink message sent on the AGCH to the MS in idle mode to assign an SDCCH afterthe BTS has received a Channel Request.

◦ Page mode

◦ Dedicated mode or TBF 2

◦ Channel description

◦ Request reference: The purpose of this parameter is explained in the Channel requestmessage.

◦ Timing advance value: An explanation of this concept can be found in GSM Archi-tecture, Protocols and Services (p. 74) [4].

◦ Mobile allocation: selection of frequencies from the serving cell that are applicablefor the MS and the hopping sequence. 3

1GSM 04.08 Technical Specification (p. 285) [3]2Temporary Block Flow (TBF) is a connection established between a MS and a BTS to enable packet exchanges

between the BTS and MS entities in General Packet Radio Service (GPRS) networks.3GSM Networks: Protocols, Terminology and Implementation (p. 353) [2]

11

Miscellaneous messages:

• Channel Request:Uplink message sent on the RACH when the MS is in idle mode. It does not followthe basic format. As it is explained in GSM 04.08 Technical Specification (p. 39) [3],this message identifies the channel type that the MS prefers and contains the reason forconnection request, for instance, answer to paging or emergency call. It also contains arandom sequence - called request reference - used to distinguish a single user from theothers that could be trying to get a channel too.

• Classmark Change:Uplink message sent on the SDCCH to indicate a classmark change. It informs of thetechnical capabilities of the MS.

◦ Mobile station classmark 2 (previously explained in the Paging Response message)

◦ Mobile station classmark 3: information element that provides the network withinformation concerning aspects of the MS. 4

It includes a layer 2 I Frame.

• GPRS Suspension Request:Uplink message sent on the SDCCH after sending a Classmark Change message. Whena MS with its IMSI attached for GPRS services enters the dedicated mode and the MSlimitations make it unable to handle both dedicated mode and either packet idle mode orpacket transfer mode simultaneously, the MS shall perform the GPRS suspension proce-dure.

◦ Temporal Logical Link Identifier (TLLI): a logical link is uniquely addressed with aTLLI. 5

◦ Routing Area Identification (RAI)

- Mobile Country Code (MCC): three digits that uniquely identify a country.

- Mobile Network Code (MNC): two digits that uniquely identify a Public LandMobile Network (PLMN).

- Location Area Code (LAC): four digits assigned by the operator that identify aLocation Area (LA).

- Routing Area Code (RAC): is a subset of GSM LA used for GPRS. 6

◦ Suspension cause


• Measurement Report:Uplink message sent on the SACCH to report measurement results about the dedicatedchannel and up to 6 neighbour cells (uplink measurements). These reports serve as inputsfor handover and power control algorithms. In an active connection, it is sent every 480ms and contains:

4GSM 04.08 Technical Specification (p. 288) [3]5GSM Architecture, Protocols and Services (p. 245) [4]6GPRS Overview (p. 7) [5]

12

◦ MEAS-VALID: Validity of the measures.

◦ RXLEV: Received signal level (dBm). This parameter is measured on all slots andon a subset of slots.

◦ RXQUAL: Received Signal Quality measured as bit error ratio (%) before error cor-rection by averaging. This parameter is also measured on all slots and on a subset ofslots.

◦ NO-NCELL-M: Number of neighbour cells from which we have information.

◦ RXLEV-CELL: Measurement of the received signal level from each neighbour cellduring the MS unused time slots.

◦ BCCH-FREQ-NCELL: BCCH frequency of each neighbour cell.

◦ BSIC-NCELL: BSIC parameter of each neighbour cell.

It includes a layer 2 UI Frame.

Ciphering messages:

• Ciphering Mode Command:Downlink message sent on the SDCCH to indicate that all data in both directions is goingto be encrypted. It also informs about the algorithm used.

◦ Cipher mode setting: indicates if the information must be ciphered and with whichalgorithm.

◦ Cipher mode response: informs the MS which information shall be include in theCiphering Mode Complete message.


• Ciphering Mode Complete:Uplink message sent on the SDCCH to indicate that the MS has changed the cipher mode.

◦ Mobile equipment identity (if it is asked in the Ciphering Mode Command message)


Channel Release messages:

• Channel Release:Downlink message sent on the SDCCH to indicate deactivation of the dedicated channelused.

◦ RR cause

◦ GPRS resumption


13

Handover messages:

• Assignment Command:Downlink message sent on the SDCCH to assign a traffic channel in case of an intracellhandover or during a call set up.


◦ Power command: informs of the power level to be used by the MS. 7

◦ Frequency list: list of the absolute radio frequency channel numbers used in a fre-quency hopping sequence. 8

◦ Channel mode

◦ MultiRate configuration


• Handover Command:Downlink message sent on the FACCH to inform of the channel assignment for a handover.

◦ Cell description


◦ Handover reference: temporary identifier of the MS. 9

◦ Power command and access type

◦ Synchronization indication: indicates which type of handover has to be performed.10

◦ Frequency list


• Assignment Complete:Uplink message sent on the FACCH to confirm that the MS has successfully changed tothe new traffic channel.

◦ RR cause


• Handover Complete:Uplink message sent on the FACCH to indicate that the MS has performed a successfulhandover.

◦ RR cause


7GSM 04.08 Technical Specification (p. 383) [3]8GSM 04.08 Technical Specification (p. 326) [3]9GSM Networks: Protocols, Terminology and Implementation (p. 261) [2]

10GSM 04.08 Technical Specification (p. 407) [3]

14

• Handover Access:Uplink message sent on the RACH. Just as the Channel Request message, it does notfollow the basic format. As explained in GSM 04.08 Technical Specification (p. 175) [3]this message only contains the handover reference.

• Physical Information:Downlink message sent on the FACCH in case of a non-synchronized handover. It is sentto the MS on the new channel to stop the sending of access burst from the MS. 11

◦ Timing advance value


System information messages:

• System Information Type 1:Downlink message sent on the BCCH to all MS within the cell giving information aboutthe current cell.

◦ Cell channel description

◦ RACH control parameters: provide parameters used to control the RACH usage. 12

• System Information Type 13:Downlink message sent on the BCCH to all MS within the cell giving information aboutthe GPRS cell options.

• System information Type 2:Downlink message sent on the BCCH to all MS within the cell. It informs about:

◦ Neighbour cell description - BCCH frequency list

◦ NCC permitted: provide a list of the allowed NCC 13 to be reported in the Measure-ment Report messages. 14

◦ RACH control parameters

• System Information Type 2ter:Downlink message sent optionally on the BCCH to all MS within the cell. The data fieldof System Information 2 is not large enough to allow distinction of the larger number ofchannels of DCS 1800, PCS 1900, and also GSM 900 with extended band. Hence, SystemInformation 2ter and 2quarter were defined to broadcast the frequencies of the neighbourcells.

◦ Neighbour cell description - extended BCCH frequency list

• System Information Type 2quarter:Downlink message sent optionally on the BCCH to all MS within the cell. It works asSystem Information Type 2ter.

11GSM 04.08 Technical Specification (p. 191) [3]12GSM 04.08 Technical Specification (p. 385) [3]133 digits that identifies the PLMN (GSM Networks: Protocols, Terminology and Implementation (p. 371) [2])14GSM 04.08 Technical Specification (p. 382) [3]

15

• System Information Type 3:Downlink message sent on the BCCH to all MS within the cell informing about:

◦ Cell Identity (CI)

◦ Location Area Identification (LAI)

- Mobile Country Code (MCC)

- Mobile Network Code (MNC)

- Location Area Code (LAC)

◦ Control channel description: information about a cell. 15

◦ Cell options (BCCH)

◦ Cell selection parameters: provides the parameters needed for performing cell se-lection algorithm. This algorithm is described in GSM Architecture, Protocols andServices (p. 89) [4].


• System Information Type 4:Downlink message sent on the BCCH. It only repeats the data already sent in Systeminformation 1, 2 and 3.





◦ Cell selection parameters


• System Information Type 5:Downlink message sent on the SACCH to all MS within the cell in an active connection.Its information is used as the first part of the BCCH frequency list of the neighbouringcells to measure.

◦ Neighbour cell description - BCCH frequency list


• System Information Type 5ter:Downlink message sent optionally on the SACCH to all MS within the cell in an activeconnection. This is the same case as System Information Type 2 and its information isthe second part of the BCCH frequency list of the neighbour cells.

◦ Neighbour cell description - Extended BCCH frequency list


• System Information Type 6:Downlink message sent on the SACCH to all MS within the cell in an active connection.This message gives all the information of the current cell.


16

◦ Cell Identity (CI)





◦ Cell Options (SACCH)

◦ NCC Permitted


Mobility Management messages (MM)

This sublayer use the channels that RR provides to exchange data about the mobility of a sub-scriber.

Registration messages:

• Location Updating Request:Uplink message sent on the SDCCH to request either update of its location file or IMSIattach.

◦ Ciphering Key Sequence Number (CKSN)

◦ Location Updating Type: Normal location updating, Periodic updating or IMSI at-tach. 16





◦ Mobile station classmark 1

◦ Mobile identity

It includes a layer 2 SABM U Frame. The network acknowledges this connection with adownlink Location Updating Request message plus a layer 2 UA Frame.

• Location Updating Accept:Downlink message to indicate that location updating or IMSI attach has been completed.







17

• IMSI Detach Indication:Uplink message to set a deactivation indication.


◦ Mobile identity

It includes a layer 2 SABM U Frame. The network acknowledges this connection with adownlink IMSI Detach Indication message plus a layer 2 UA Frame.

• MM Information:Downlink message sent on the SDCCH. This message can be sent during an RR connectionand provides the MS with information about the network. 17

◦ Network Name - Full Name

◦ Network Name - Short Name


Security messages:

• Authentication Request:Downlink message sent on the SDCCH to initiate authentication of the MS identity duringa connection establishment.


◦ Authentication parameter RAND - Universal Mobile Telecommunications System(UMTS) challenge or GSM challenge: parameter used in the authentication procedureexplained in GSM Architecture, Protocols and Services (pp. 173 - 175) [4].

◦ Authentication parameter AUTN - UMTS and Evolved Packet System (EPS) au-thentication: An explanation on UMTS authentication procedure can be found inSecurity Mechanisms in UMTS [6].


• Authentication Response:Uplink message sent on the SDCCH to deliver a calculated response to the network.

◦ Authentication response parameter SRES: this parameter is part of the authenticationprocedure explained in GSM Architecture, Protocols and Services (p. 173 - 175) [4].

◦ Authentication response parameter XRES (extension, UMTS authentication chal-lenge only): this parameter is part of the authentication procedure for UMTS ex-plained in Security Mechanisms in UMTS [6].


• Identity Request:Downlink message sent on the SDCCH to request a MS to submit the specified identity tothe network (IMSI, TMSI, IMEI or International Mobile station Equipment Identity andSoftware Version (IMEISV)).


18

◦ Identity type


• Identity Response:Uplink message sent on the SDCCH to provide the requested identity information.

◦ Mobile Identity


• TMSI Reallocation Command:Downlink message sent on the SDCCH to reallocate a TMSI in order to make trackingand interception of a subscriber more difficult.





◦ Mobile identity: TMSI


• TMSI Reallocation Complete:Uplink message sent on the SDCCH to confirm the receipt of a TMSI.It includes a layer 2 I Frame.

Connection Management messages:

• CM Service Request:Uplink message sent on the SDCCH at the beginning of every mobile originated connectionin order to provide its identity (TMSI or IMSI) and to specify the service request in moredetail.


◦ CM Service Type: MOC, emergency call, short message service, supplementary ser-vice activation, voice group call or voice broadcast call. 18


◦ Mobile identity

It includes a layer 2 SABM U Frame. The network acknowledges this connection with thea downlink CM Service Request message with a layer 2 UA Frame.

• CM Service Accept:Downlink message sent on the SDCCH to inform the MS that its request has been accepted.


19

Call Control messages (CM-CC)

Call Control is a sublayer of CM sublayer and these messages also use the channels that RRprovides to exchange data. However, CM-CC is used for call establishment, clearing and release.

Call establishment messages:

• Setup:On an originated call, uplink message sent on the SDCCH to initiate a Mobile OriginatedCall (MOC) establishment. This message contains the address information of the calledparty and the type of connection needed. In addition, activates the Call Waiting tone atthe MS.

◦ Bearer capability: describes a bearer service 19

◦ Called party Binary Coded Decimal (BCD) number

◦ Call control capabilities

◦ Supported codec list

On a Mobile Terminated Call (MTC), downlink message also sent on the SDCCH toinitiate a MTC establishment.

◦ Bearer capability

◦ Calling party BCD number


• Call Proceeding:On an originated call, downlink message sent on the SDCCH to indicate that the addressinformation in the Setup message has been received and no more establishment informationwill be accepted.

◦ Facility - GSM mobile application: transports supplementary service related infor-mation. 20


• Call Confirmed:On an MTC, uplink message sent on the SDCCH after receiving a Setup message to confirmthat the MS is able to establish the requested connection.

◦ Bearer capability

◦ Call control capability

◦ Supported Codec list


19GSM 04.08 Technical Specification (p. 427) [3]20GSM 04.08 Technical Specification (p. 457) [3]

20

• Connect:On an originated call, downlink message sent on the FACCH to indicate that the connectionwas successfully established.

◦ Progress indicator: describes an event which has occurred during the life of a call. 21

On a MTC, uplink message sent on the FACCH as soon as the called party accepts thecall.It includes a layer 2 I Frame.

• Connect Acknowledge:On an originated call, uplink message sent on the FACCH in order to acknowledge theConnect message and start of charging.On a MTC, downlink message also sent on the FACCH to indicate the start of the call.It includes a layer 2 I Frame.

• Alerting:On an originated call, downlink message sent on the FACCH to indicate that the calleduser alerting has been initiated.

◦ Progress indicator

On a MTC, uplink message sent on the FACCH to inform that the MS has started ringingafter the traffic channel assignment.It includes a layer 2 I Frame.

Call clearing messages:

• Disconnect:Uplink/downlink message sent on the FACCH by the MS/Network to terminate an existingCC connection.

◦ Cause


• Release:Downlink/uplink message sent on the FACCH to indicate that the Network/MS intendsto release the transaction identifier.

◦ Cause


• Release Complete:Uplink/downlink message sent on the FACCH to indicate that the Network/MS has re-leased the transaction identifier and the MS/Network shall do the same after sending thismessage. It is sent by the side that has previously sent the disconnect message.

◦ Cause21GSM 04.08 Technical Specification (p. 463) [3]

21


Short-Message Services messages (CM-SMS)

Short Message Services is another CM sublayer and is in charge of the management of SMSmessages between subscribers. The information for this sublayer is sent on the SACCH if thereis an active connection or on the SDCCH otherwise. It is necessary to take a look upon SMSservice before explaining the packets exchange needed for this kind of communication. Thefollowing information can be found in Mobile messaging technologies and services. SMS, EMSand MMS (pp. 41 - 85) [7] and GSM switching services and protocols (pp. 142 - 144) [8].

The SMS protocol stack consists of four layers: firstly, there is the application layer whichis implemented on the MS as software applications. Secondly, the transfer layer, related toShort Message Transport Protocol (SM-TP), consist on a sequence of octets with informationabout message length, originator, recipient... Thirdly, the relay layer, related to Short Mes-sage Control Protocol (SM-CP), permits the transport of a message between network elements.Lastly, the link layer, related to Short Message Relay Protocol (SM-RP), allows the transmissionof the message at the physical level.

Before further explanations on the sending of SMSs, some SMS parameters should be intro-duced. First, the Status Report informs the sender if a SMS has been successfully received ornot. Even though, in the captures this parameter is not requested. On the other hand, theReply Path (RP) indicates that the serving SM-SC is able to provide a reply from the receiver.This parameter is not asked either.

From the point of view of the transport layer, an exchange of a message consists on:

1. The short message is submitted to the SM-SC. The SM-SC has to verify that the senderis allowed to send messages.

2. If so, the SM-SC delivers this short message to the receiver. If the receiver is not available,the short message would be stored during the validity period.

3. If it is requested, a status report might be transferred to the sender after the delivery ofthe short message or its deletion.

A SMS will be divided into several message segments if its data exceeds 140 bytes22. Thesemessage segments would be finally joined again into a concatenated message in the receiverapplication layer. The packets shown in this section transport Protocol Data Units (PDUs)which are composed of several parameters such as the type of message, whether or not a StatusReport is required, the validity period and so on. The list of the CM-SMS sublayer messages isshown below.

• SMS Submit:The MS sends the short message to the SM-SC. Each message segment is transferred aspart of a TPDU containing the parameters below:

22Mobile messaging technologies and services. SMS, EMS and MMS (p. 51) [7]

22

◦ CP user data

◦ RP destination address

◦ RP user data

◦ Request or not for Reply Path

◦ Request or not for a Status Report

◦ TP destination address

◦ TP PID: Protocol Identifier

◦ TP DCS: Data Coding Scheme

◦ TP validity period

◦ TP user data

This packet will be labelled in Wireshark (see Chapter 3: Design and Development)as (SMS) CP-DATA (RP) RP-DATA (MS to Network).

• SMS Submit Report:The SM-SC acknowledges the MS of a SMS Submit. If this packet is not received, the MSwill conclude that the SMS Submission or the SMS Submission Report has been lost. Inthis case, the MS could try to submit the message again. If the lost packet was the SMSSubmit Report, the SM-SC would not send the message again to the receiver.

◦ CP user data

◦ RP message reference

This packet will be labelled in Wireshark (see Chapter 3: Design and Development)as (SMS) CP-DATA (RP) RP-ACK (Network to MS).

• SMS Deliver:The SM-SC delivers to the receiver MS the short message. If the MS is not available, theSM-SC will store the message temporarily - up to the validity time -. The SM-SC will tryto deliver the message until it receives a SMS Deliver Report from the receiver MS. Again,each message segment is transferred as part of a PDU containing the parameters below:

◦ CP user data

◦ RP originator address

◦ RP user data

◦ Request or not for Reply Path

◦ Request or not for a Status Report

◦ TP originating address

◦ TP PID: Protocol Identifier

◦ TP DCS: Data Coding Scheme

◦ TP service center time stamp

◦ TP user data

23

This packet will be labelled in Wireshark (see Chapter 3: Design and Development)as (SMS) CP-DATA (RP) RP-DATA (Network to MS).

• SMS Deliver Report:The receiver MS acknowledges the SM-SC of a SMS Deliver. Once the SM-SC has receivedthis report, it will stop trying to deliver the message.

◦ CP user data

◦ RP message refence

◦ RP user data

◦ TP parameter indicator: presence of protocol identifier, data coding scheme and userdata length.

This packet will be labelled in Wireshark (see Chapter 3: Design and Development)as (SMS) CP-DATA (RP) RP-ACK (MS to Network).

• SMS Status Report:The SM-SC informs the sender MS of the Status Report. As it has been said before, noneof the operator at our disposal asks for Status Report.

• SMS Command:The MS requests the SM-SC to execute a specific command which are detailed in Mobilemessaging technologies and services. SMS, EMS and MMS (p. 85) [7].

If we take a look upon GSM 04.11 Technical Specification [9] which regards to SMS, we can findinformation about other packets that will be found in the captures:

• CP Acknowledgement:After receiving any of the previous packets, an acknowledgement is send back. 23

This packet will be labelled in Wireshark (see Chapter 3: Design and Development)as (SMS) CP-ACK.

As explained before, a large SMS is divided into message segments which will be concatenatedlater.


24

Chapter 3

Design and development

3.1 General scenario

As we can see in Figure 2.1: GSM network on page 5, GSM communication could be di-vided into two parts: the user side, composed by the MS, and the network side, composedby the BSS, the NSS and the OSS. As it has been explained before, this project focusses onthe communication over the Air interface. That is to say, between the user and the network side.

In addition to the MS and the network, the MS will be connected to a PC in order to cap-ture GSM traffic.

3.2 Tools and platforms used

To perform this project, several tools and platforms have been necessary. The following sectionsprovide an overview of those which have been used.

3.2.1 Mobile Terminal: Samsung SIII

In order to work with the software xgoldmon, which is explained in the Section 3.2.3, it wasneeded a phone with Intel/Infineon XGold baseband processor. The Samsung Galaxy SIII GT-9300 incorporates this processor. The software is also supported by:

• Samsung Galaxy Nexus GT-I9250 1

• Samsung Galaxy SII GT-I9100

• Samsung Galaxy Note 2 GT-N7100

3.2.2 MicroSIMs

As Samsung SIII only works with MicroSIMs, a MicroSIM for each operator is needed to beable to perform calls and send and receive SMSs. We have available the following MicroSIMs:

• Movistar (x1)

1This phone has to be rooted in order to use xgoldmon

25

• Orange (x1)2

• Vodafone (x2)

3.2.3 xgoldmon

This tool is freely provided and developed by Tobias Engel [10] and allows to watch in re-altime, for instance in Wireshark, the messages output by the USB logging mode of phoneswith Intel/Infineon XGold baseband processor. In these messages we can find for example sig-naling for calls and SMS on the Air interface. This software works with Linux Operating System.

As a prerequisite to build xgoldmon, a recent version of libosmocore had to be installed. Inorder to run xgoldmon, first the logging or diag mode has to be enabled in the Samsung GalaxySIII. This is done with these two steps:

1. Entering *#9900# and setting Debug Level Enabled to HIGH. The phone reboots oncethis is done.

2. Entering *#7284# and setting USB to MODEM and tap SAVE and RESET. The phonereboots again once this is done.

Also, when connecting the phone via USB to the computer with an Ubuntu 12.04 environment,several new pseudo-tty devices are created. The one with the second lowest number should bethe logging port. As xgoldmon does not yet set any serial parameters on the device, on Linuxthe following command must be type in a terminal:

stty 115200 pass8 raw -noflsh </dev/ttyACMx

Finally, to run xgoldmon we have to type in a terminal:

./xgoldmon [-t <phone type>] [-l] [-v] <logfile or device>

Where:

• -t: s3, gnex, s2 or note (default: s3)

• -l: print baseband log messages

• -v: show debugging messages

• logfile or device: /dev/ttyACMx

I had a lot of trouble at this point. When I connected the phone via USB to the computer some-times the devices ttyAMCx did not appear or they disappear unexpectedly when the programwas running. At the time of writing this document the problem has not been resolved.

In the following section it is explained how to watch the radio messages.

2Does not allow calling

26

3.2.4 Wireshark

Wireshark is a network protocol analyser [11]. It lets us capture and interactively browse thetraffic running on a computer network. It has a rich and powerful feature set and is world’smost popular tool of its kind. It runs on most computing platforms including Windows, OS Xand Linux. It is freely available as open source, and is released under the GNU General PublicLicense version 2.

It is developed and maintained by a global team of protocol experts and the version used in thisproject is 1.9.3 (SVN Rev 48788 from /trunk)

xgoldmon uses libosmocore to send the radio messages in GSMTAP format to UDP port 4729 onthe local host. In order to monitor the packets with Wireshark the following command enablesus to listen to this port:

nc -u -l 4729

At this moment, we only have to start a capture on the loopback interface. In order to see onlyGSMTAP messages, it is recommended to use a filter:

udp.port==4729

On capturing the traffic I found another problem: not always all the packets were captured. So,one day you got a completed capture and the following day you missed plenty of messages.

3.2.5 Programming language: Python

Python is a widely used high-level programming language [12]. Its philosophy is to enable clearerand simpler codes than other languages. It is free to used because its OSI-approved open sourcelicense and runs on Windows, Linux and Mac OS X, and also has been ported to the Java and.NET virtual machines.

This language was chosen because of its simplicity and because it seemed appropriate for parsing,that is to say, for analysing a string or a set of strings.

Matplotlib library

In order to plot graphics of the results, the matplotlib library has been used [13]. It providesan object-oriented API for embedding plots into applications using general-purpose GUI toolkits.

Matplotlib is open source and has been designed to closely resemble MATLAB.

3.2.6 SPE Python IDE

Stani’s Python Editor (SPE) is a cross-platform integrated development environment (IDE) forthe Python programming language [14]. The IDE is developed and maintained by Stani Michiels.

SPE is free software and runs on GNU/Linux, Mac OS X and Windows.

27

Chapter 4

Protocols analysis

Once all the software is installed, it is possible to capture GSM traffic with the operators at ourdisposal - namely, Movistar, Orange and Vodafone -. With these captures, we will be able tocompare the actual protocols with the ones recommended in the GSM standard.

Due to the development and usage of new technologies as 3G and recently 4G, the standarddefined has several optional parameters added in order to support these technologies and beable to change from one to the other. Every procedure can be divided into connection establish-ment, communication and connection release. In this chapter we will explain first the completestandard procedures and then the differences applied by each operator.

4.1 Signaling before a procedure

Before performing any connection establishment, every MS must receive information about thecell in which they camp. For this purpose, the cell broadcasts information about the organizationof the radio network in the BCCH using System Information messages. Looking at the captures,we can conclude that the behaviour of all operators is to send a System Information messageevery 51-multiframe, that is to say, every 235 milliseconds. The sequence followed is normallythe one bellow:

• System Information Type 1 or System Information Type 13

• System Information Type 2 or System Information Type 2ter plus System InformationType 2quarter

• System Information Type 3

• System Information Type 4

Cells use the time between these messages to broadcast Paging Request messages and ImmediateAssignments.

4.2 Connection establishment

This procedure can be divided into Mobile Originated (MO) connection establishment and Mo-bile Terminated (MT) connection establishment.

28

Regarding to the first one, it begins with the MS sending a Channel Request and getting anImmediate Assignment as a response. Once the MS gets a dedicated channel, it sends the ser-vice request and provides its identity with a CM Service Requests which is acknowledged by theNetwork. Before accepting the request with a CM Service Accept, the Network challenges theMS with an Authentication Request message which the MS answers with an Authentication Re-sponse message. Once the service is accepted, Network and MS agree the cipher algorithm usedwith Ciphering Mode Command and Complete messages. Then, the Network begins an identityprocedure with the Identity Request and Response messages and, finally, a TMSI reallocationprocedure is performed with the TMSI Reallocation Command and Complete messages. Thecomplete procedure is presented in Figure 4.1.

Figure 4.1: GSM Standard MO connection establishment

Figure 4.2 shows the MO connection establishment implemented by operators. There are sev-eral differences, for instance, all the studied operators include the messages Classmark Changejust after the service has been accepted by the Network with a CM Service Request message plusan UA Frame. Movistar and Orange include the message GPRS Suspension Request after theCiphering Mode Command message while Vodafone include it after the first Identity Requestmessage. Another common characteristic is that non of them use the messages CM ServiceAccept, TMSI Reallocation Command and TMSI Reallocation Response.

The authentication procedure is not always performed. Only when the CKSN stored in theMS is different from the one stored on the Network. In the authentication procedure the Net-work challenges the MS sending a RAND parameter and expecting just an SRES which resultsof using the A3 algorithm or sending RAND and AUTN parameters and expecting an SRESand XRES.

Regarding to the messages Identity Request and Response, Movistar does not make use ofthem. On the other hand, orange uses them to ask the MS for its IMEISV and, finally, Voda-fone identifies the MS using twice these messages - first asking for the IMEI and then for theIMEISV. In Chapter 2: Background: GSM, it was explained that IMEI is a unique numberfrom the MT used to prevent the theft of terminal storing them in three lists in the EIR:

29

• White list: there is no problem with the terminal.

• Grey list: the terminal can perform calls but should be tracked.

• Black list: the terminal is stolen or lost and service should be blocked.

In addition to this parameter, there is also the IMEISV. It carries the same information as theIMEI - origin, model and serial number of the device - plus the SVN (Software Version Num-ber). There are different strategies to ask for the IMEI/IMEISV: Orange which only asks forIMEISV with the message Identity Request. Vodafone is checking twice the identity asking forboth parameters with the same message maybe to assure the reliability of the information. Andfinally, Movistar asks for this parameter in the Ciphering Mode Commad.

(a) Movistar(b) Orange

(c) Vodafone

Figure 4.2: MO connection establishment

On the other hand, a MT connection establishment starts with a Paging Request send by theNetwork. The MS reacts to this message asking for a dedicated channel with a Channel Requestand waiting for an Immediate assignment. Once the MS has a dedicated channel, it sends aPaging Response which is acknowledged by the Network. At this point, the Network begins anauthentication procedure sending an Authentication Request and waiting for an AuthenticationResponse. When the MS is authenticated, Network and MS agree on the cipher algorithm usedwith the messages Ciphering Mode Command and Complete. Then, just as in the MO case, theNetwork starts an identity procedure with the Identity Request and Response messages and,finally, a TMSI reallocation procedure is performed with the TMSI Reallocation Command andComplete messages. The complete procedure is presented in Figure 4.3.

Figure 4.4 shows the MT connection establishment implemented by operators. There are severaldifferences, again, all the studied operators include the message Classmark Change just afterthe paging has been acknowledged by the Network with a Paging Response message plus an UAFrame. Also, the Movistar and Orange include the message GPRS Suspension Request after theCiphering Mode Command message while Vodafone include it after the first Identity Requestmessage.

30

Figure 4.3: GSM Standard MT connection establishment

There are some messages that are not always used, such as the Authentication Request andResponse that are used in the same case as in the MO connection establishment and TMSI Re-allocation Request and Response messages which are used when a MS is identified by its IMSIinstead of its TMSI in the paging procedure. Lastly, the identity procedure is performed in thesame way as in the MO connection establishment.


(c) Vodafone

Figure 4.4: MT connection establishment

It is remarkable that we are not able to capture Channel Request messages in any of the proce-dures and operators. This might be because the message does not follow the basic format andthe sniffer cannot decode or detect it.

31

4.3 Communication

4.3.1 Attach

The attach procedure is slightly different from the others because the connection establishmentand the communication are not clearly apart. As it can be seen in Figure 4.5, first a MS askfor a dedicated channel with a Channel Request message and the Network assign it with an Im-mediate Assignment. After this assignment, the MS indicates that it wants to perform an IMSIattach with the message Location Updating Request which is acknowledged by the Network.Before accepting the location updating, the procedures for authentication, ciphering, identityand TMSI reallocation are performed. Finally, in order to release the connection, the Networksends a Channel Release message on Layer 3. The MS answers this last Layer 3 message with aLayer 2 RD U frame which will be acknowledged by a Layer 2 UA frame.

Figure 4.5: GSM Standard attach

Figure 4.6 shows the behaviour found in the captures for each operator. As in the connectionestablishment, the operators include a Classmark Change message to inform the network aboutthe capabilities of the MS. Also, the messages Authentication Request and Response are usedwhen the CKSN stored in the MS is different from the one stored in the Network.

Particularly, Movistar does not use the messages Identity Request and Response nor TMSIReallocation Request and Response. A significant change in front of the other operators is thatwhen the MS changes from WCDMA to GSM, Movistar performs the attach procedure includinga GPRS Suspension Request message whereas the other operators do not perform the attachprocedure at all.

On the other hand, Vodafone always identifies the MS asking for its IMEI and omits the Cipher-ing Mode Command and Complete and TMSI Reallocation Request and Response messages.Lastly, Orange omits the messages TMSI Reallocation Request and Response, Identity Requestand Response and Ciphering Mode Command and Complete.

32

(a) Movistar

(b) Orange(c) Vodafone

Figure 4.6: Attach

4.3.2 Detach

In the detach procedure the connection establishment and the communication are neither clearlyapart. GSM Standard suggest as an option the realization of this procedure when the MS ispowered off or the SIM is removed in order to relieve the paging load on the BSS caused byunnecessary paging requests. As it is just an option, there is not an standard procedure for thedetach procedure. Even though, all the studied operators perform exactly the same protocolshown in Figure 4.7.

Figure 4.7: Detach

Any MS that intends to perform a detach procedure asks first for a dedicated channel with aChannel Request message and this is assigned by the Network with an Immediate Assignmentmessage. Then, the MS informs of its intention with an IMSI Detach Indication message thatwill be acknowledged by the Network. Afterwards, the MS sends a Classmark Change messageand the Network initiates the connection release procedure sending a Channel Release message.Finally, the MS sends a Layer 2 RD U frame which will be acknowledged by a Layer 2 UA frame.

33

4.3.3 MOC and MO-SMS

As it had been said before, we only can perform calls with Movistar and Vodafone while wecan send and receive SMS with all the operators at our disposal. Although the protocol forthe connection establishment has been described before, it is included to show the completeprocedures. As a matter of fact, the main differences are in the connection establishment.

Figure 4.8: GSM Standard MOC

Regarding to MOC, Figure 4.8 shows the complete procedure. In the first place, the channelassignment procedure is done with the Channel Request and Immediate Assignment messages.These are followed by the CM Service Request messages with which the MS informs the Net-work of its identity and the service required. Then, the Network authenticates the MS with theAuthentication Request and Response message before accepting the service with a CM ServiceAccept message. Once the service is accepted the procedures for ciphering, identification andTMSI reallocation and performed one by one. At this point, the MS sends a Set Up messageinforming about the called MS address. This information will be acknowledged by the Networkwith a Call Proceeding message and, then, the Network will make the MS change its dedicatedchannel from the SDCCH to the FACCH using the messages Assignment Command and Com-

34

plete. Once the alerting on the called user has been initiated, the Network sends an Alertingmessage and a Connect message when the called user accepts the call. This last message isacknowledged by the calling MS with a Connect Acknowledge.

Finally, the side that wants to release the connection sends a Disconnect message. Next, theother part sends a Release message which is acknowledged by a Release Complete. Then, theNetwork initiates the connection release procedure sending a Channel Release message and theMS sends a Layer 2 RD U frame which will be acknowledged by a Layer 2 UA frame.

Looking at Figure 4.9, it can be seen that the differences are only in the connection establish-ment. Both operators include the messages Classmark Change and GPRS Suspension Requestand omit the messages CM Service Accept and TMSI Reallocation Command and Complete.Also, the authentication procedure is only used when the CKSN stored in the MS is differentfrom the one stored in the Network. Particularly, Movistar omits the identity procedure andVodafone uses twice the identity procedure.

(a) Movistar

(b) Vodafone

Figure 4.9: MOC

Regarding to MO-SMS, Figure 4.10 shows the complete procedure. As always in a MO proce-dure, it begins with an assignment of a dedicated channel with the messages Channel Request

35

and Immediate Assignment. The MS informs about its identity and the type of service requestedwith the CM Service Request which is acknowledged by the Network. Before accepting the ser-vice with a CM Service Accept message, an authentication procedure will be performed. Afteraccepting the service, the procedures for ciphering, identification and TMSI Reallocation aredone one after the other. At this point, the MS will send a SMS Submit message. The Networkwill acknowledge it with a CP Acknowledgement message and then will send to the MS a SMSSubmit Report that the MS will also acknowledge with a CP Acknowledgement message. Fi-nally, the Network initiates the connection release procedure sending a Channel Release messageand the MS sends a Layer 2 RD U frame which will be acknowledged by a Layer 2 UA frame.

Figure 4.10: GSM Standard MO-SMS

Again, the differences observed in the captures are mainly in the connection establishment. Allthe operators include the messages Classmark Change and GPRS Suspension Request and omitthe messages CM Service Accept and TMSI Reallocation Command and Complete and the au-thentication procedure is only used when the CKSN stored in the MS is different from the onestored in the Network. Particularly, Movistar also omits the identity procedure and Vodafoneuses twice the identity procedure. Orange does not present more particular differences.

It seems interesting to know the behaviour of the network when someone sends a large mes-sage - more than 174 bytes - that has to be divided as explained in Chapter 2: Background:GSM. In this case, the MS performs the procedure to send an SMS and, before the connectionrelease, asks again for a CM Service to send the rest of the SMS with a CM Service Requestplus an Layer 2 I Frame. This is the only case where the networks answers with a CM ServiceAccept plus a Layer 2 I Frame so the connection is not release until the MS has sent the complete

36

message.


(c) Vodafone

Figure 4.11: MO-SMS

4.3.4 MTC and MT-SMS

As in the previous case, we only can perform calls with Movistar and Vodafone while we cansend and receive SMS with all the operators. Once again, in both cases the changes applied aremainly in the connection establishment.

Figure 4.12 shows the recommended protocol for a MTC. First, the Network sends to theMS a Paging Request. The MS reacts asking for a dedicated channel with the Channel Requestand the Network assigns it with an Immediate Assignment message. Once the channel is as-signed, the MS sends a Paging Response message which is acknowledged by the Network. Next,the procedures for authentication, ciphering, identification and TMSI reallocation are performedone after another. At this point, the Network sends a Set Up message to initiate the MTC andthe MS answers with a Call Confirmed to inform that is able to establish the connection. Thenthe Network will make the MS change its dedicated channel from the SDCCH to the FACCHusing the messages Assignment Command and Complete. Once the channel has been changedand the alerting has started on the MS, it sends an Alerting message to the Network. Whenthe MS takes the call, it will send a Connect message that the Network will acknowledge witha Connect Acknowledge message.

Finally, just as in the MOC procedure, the side that wants to release the connection sends a

37

Figure 4.12: GSM Standard MTC

Disconnect message. Next, the other part sends a Release message which is acknowledged bya Release Complete. Then, the Network initiates the connection release procedure sending aChannel Release message and the MS sends a Layer 2 RD U frame which will be acknowledgedby a Layer 2 UA frame.

Figure 4.13 shows the variations observed in the captures. To begin with, both operatorsinclude the messages Classmark Change and GPRS Suspension Request. Again, the authenti-cation procedure is only performed when the CKSN stored in the MS is different from the onestored in the Network and the TMSI Reallocation when the MS is identified by its IMSI insteadof its TMSI in the paging procedure. The last difference is that Movistar omits the identificationprocedure while Vodafone performs it twice.

Regarding to MT-SMS, Figure 4.14 shows the complete procedure. As a MT communica-tion, the MS receives a Paging Request message and reacts asking for a dedicated channel witha Channel Request message and waiting for an Immediate Assignment. After the assignment ofthe channel, the MS sends a Paging Response which is acknowledged by the Network. Then, theprocedures for authentication, ciphering, identification and TMSI reallocation are performed one

38

by one. At this point, the Network sends a SMS Deliver and waits for the MS to acknowledgeit with a CP Acknowledgement message and a SMS Deliver Report. This Report will also beacknowledged by the Network with a CP Acknowledgement message. Once the SMS has beenreceived, the MS will start the connection release procedure sending a Channel Release andwaiting for a Layer 2 RD U frame which will be acknowledged by a Layer 2 UA frame.

(a) Movistar

(b) Vodafone

Figure 4.13: MTC

The differences observed in the captures are shown in Figure 4.15. In this figure we see againthat all the operators include the message Classmark Change after the paging response has beenacknowledged by the Network and the message GPRS Suspension Request after Ciphering ModeCommand for Movistar and Orange or after the first Identity Request for Vodafone. Also, theauthentication procedure is only used when the CKSN stored in the MS is different from the onestored in the Network and the TMSI Reallocation when the MS is identified by its IMSI insteadof its TMSI in the paging procedure. The last difference in the connection establishment is thatthe identity procedure is not used by Movistar and used twice by Vodafone. Regarding to theCM-SMS messages, the acknowledgement of the SMS Deliver Report is not sent by any of theoperators.

39

Figure 4.14: GSM Standard MT-SMS

There are some especial cases that seem interesting to focus on. For example, which is thebehaviour when a MS is switched on and it already has SMS to be delivered. The procedureis as follows: once the attach procedure is done, as many MT-SMS procedures as SMS the MShas to receive are performed. Regarding to the case of receiving a large SMS, it is received asseveral independent SMS. That is to say, contrary to the large MO-SMS case, it is received asseveral complete MT-SMS procedures but reassembled in the last.

4.3.5 MT-SMS in a call

The behaviour of a MT-SMS in a call should be the same as described in Section 4.3.4 butsent over the SACCH instead of over the SDCCH. However, when checking this procedure withthe operators Movistar and Vodafone - since we are not able to perform calls with Orange -, wehave found out that both operators follow the same protocol:

1. First, a new Layer 2 connection is set with a Layer 2 SABM U Frame.

2. A Layer 2 UA Frame should acknowledge the previous message even though it is notcaptured.

3. Then, the SMS data is received with a SMS Deliver message.

4. The MS acknowledges the previous message with a Layer 2 RR S Frame.

5. Finally, the network sends a CP Acknowledgement message.

40


(c) Vodafone

Figure 4.15: MT-SMS

The MT-SMS in a call procedure is also shown in Figure 4.16.

Figure 4.16: MT-SMS in a call

4.3.6 Nonsynchronized intra-BSC handover or intra-MSC handover

The recommended implementation of a nonsynchronized handover starts with the Network send-ing a Handover Command message. Then, the MS sends an undefined number of HandoverAccess messages with the temporary identifier of the MS while the Network sends Physical In-

41

formation messages.1 When the MS receives a Physical Information message, it stops sendingHandover Access messages and sends a Layer 2 SABM U Frame which will be acknowledgedby a Layer 2 UA Frame. Finally, the MS confirms the successful handover sending a HandoverComplete message. Figure 4.17 presents this procedure.

Figure 4.17: Nonsynchronized intra-BSC handover or intra-MSC handover

The only difference observed in the captures is that we are not able to capture the messagesHandover Access. Probably due to the same reason for we cannot capture any Channel Requestmessage.

4.3.7 Synchronized intra-BTS handover

Regarding to synchronized intra-BTS handover, the recommended protocol is shown in Figure4.18. The Network initiates this procedure sending either an Assignment Command or a Han-dover Command. Then, the MS sends up to 4 Handover Access messages2 and establish theconnection sending a Layer 2 SABM U Frame and waiting for a Layer 2 UA Frame. Once theconnection has been established, the MS informs that the handover has been successful with anAssignment Complete or a Handover Complete message.

Figure 4.18: GSM Standard synchronized intra-BTS handover

As in the previous case, we are not able to capture the uplink message Handover Access. More-over, both operators choose the messages Assignment Command and Complete between the twooptions given in the standard as it can be seen in Figure 4.19.

1The maximum number of Physical Information messages is defined (GSM 04.08 Technical Specification (p.54) [3])

2GSM Networks: Protocols, Terminology and Implementation (p. 258) [2]

42

Figure 4.19: Synchronized intra-BTS handover

4.3.8 Signaling during a communication

Figure 4.20 shows the recommended procedure for signaling during a communication. Basically,MS and BTS send their measurement results every SACCH frame, that is to say, every 480ms.Consequently, the MS sends a Measurement Report and the Network answers with a SystemInformation Type 5, 5ter or 6.

Figure 4.20: GSM Standard signaling during a communication

Observing the captures, we have found some differences in the behaviour. To begin with, a MSwith all the operators receives first the System Information Type 5, 5ter or 6 and then sendsa Measurement Report message. Moreover, the MS receives four Layer 2 UI Frames beforereceiving another System Information message. There is no apparent explanation for receivingthese final Layer 2 UI Frames and we cannot decode the information carried in them to deduceit. This behaviour can be observed in Figure 4.21.

Figure 4.21: Signaling during a communication

4.4 Connection release

The recommended implementation of a connection release procedure is shown in Figure 4.22.This procedure is started by the side that wants to release the connection sending a Channel

43

Release message. The other side reacts sending a Layer 2 RD U Frame that will be acknowledgedby the first part with a Layer 2 UA Frame. There are no differences observed in the finalimplementation by the operators.

Figure 4.22: Connection release

4.5 Key Parameter Indicators (KPIs)

Once the procedures have been described, some KPI are needed in order to evaluate the be-haviour of the networks. GSM, GPRS and EDGE performance (p. 159) [15] explains that theseparameters are taken by two kind of tests: Network Management System (NMS) and drivetests. The first represents the overall network whereas the latter should only be used in moni-toring the overall network performance when MNS statistics are not available. In our project weare not able to monitor the complete network, we only have access to the information sent andreceived at the MS. Anyway, the conclusions should be enough to get an idea of the performance.

Paying attention to these kind of parameters, operators should be able to know which are theirsystem weaknesses and improve it. With the tools at our disposal, we will define some achievableKPIs and divide them into general delays, particular delays and measurement parameters.

4.5.1 General delays

First, we will focus on general procedures delays. These will give us an overview of the qualityof the communication.

• Establishment time:Time between the reception of the address information by the network and the alerting inthe calling part. As we only get information from the MS, this time is calculated betweensending a Set Up message which contains the called party number and receiving an Alertingmessage which indicates that the called user alerting has been initiated. Consequently, thisKPI has only meaning in a MOC.

• Call set up time:Time between sending of complete address information and receipt of a call setup notifi-cation. That is to say, the time between sending a Set Up message containing the calledparty number and receiving a Call Proceeding message which informs that the addressinformation has been received. Again, this KPI has only meaning in a MOC.This time should be smaller than 5 seconds.3

3Mobile Cellular Quality of Service (p. 12) [16]

44

• Set Up delay:Time between the assignment of a SDCCH and the set up of the call. That is to say,between the Immediate Assignment message and the Set Up message.

• Alerting delay:Time between the assignment of a SDCCH and the alert on the called terminal. That isto say, between the Immediate Assignment message and the Alerting message.

• Handover delay:Time between receiving a Handover Command message and sending a Handover Completemessage. As several handovers can occur in a call, the output will be a vector.

• SMS mobile originated access delay:Defined as the time between sending an SMS to a MSC and receiving the acknowledgefrom the MSC. We will calculate it as the time between sending an SMS Submit messageand receiving an SMS Submit Report message.This time has meaning for a MO-SMS and should be smaller than 2 seconds.4

• Sending or receiving an SMS time:On an originated SMS it can be defined as the time between the assignment of a SDCCH,Immediate Assignment message, and sending an CP Acknowledgement message. Referringto a terminated SMS, it can be defined as the time between the assignment of a SDCCHand sending an SMS Deliver Report message.

• Receiving an SMS in a call time:If the mobile receives an SMS while in a call, this time is define between a SABM U pollingFrame and an CP Acknowledgement message.

• Starting of sending or receiving an SMS delay:It can be defined as the time between the assignment of a SDCCH, Immediate Assignmentmessage, and sending or receiving an SMS Submit or SMS Deliver message.

• Total time communication:Defined as the time between an Immediate Assignment message and a Channel Releasemessage.

4.5.2 Particular times or delays

Once we have all general delays, we will look for inner procedures delays so we will be able toknow which inner procedure accounts for most of the delay.

• SDCCH assignment delay:As we cannot capture RACH messages, we are not able to calculate this delay. It wouldbe the time between sending a Channel Request message and receiving an ImmediateAssignment message. What is shown instead is the SDCCH assignment time.

• Handover Completed times:Here are shown the times when a handover procedure has been completed. This can beinteresting knowing the results of the measurement parameters.

4Mobile Cellular Quality of Service (p. 16) [16]

45

• Paging Response delay:Time between sending a Paging Response message including a SABM U Frame and re-ceiving also a Paging Response message including an UA Frame instead.

• CM Service Request delay:Time between sending a CM Service Request message including a SABM U Frame andreceiving also a CM Service Request message but including an UA Frame.

• GPRS Suspension delay:Time between sending a Classmark Change message and a GPRS Suspension Requestmessage.

• Ciphering Mode delay:Time between receiving a Ciphering Mode Command message and sending a CipheringMode Complete message.

• TMSI Reallocation delay:Time between receiving a TMSI Reallocation Command message and sending a TMSIReallocation Complete message.

• Authentication delay:Time between receiving an Authentication Request message and sending an AuthenticationResponse message.

• Identity delay:Time between receiving an Identity Request message and sending an Identity Responsemessage. As Vodafone identifies the MS using twice these messages, the output of thisKPI will be a vector.

• Location Updating delay:Time between sending a Location Updating Request message and receiving a LocationUpdating Accept message.

• Detach Indication delay:Time between sending an IMSI Detach Indication message including a SABM U Frameand receiving also a IMSI Detach Indication message including an UA Frame instead.

• FACCH assignment delay:On a MOC, time between receiving a Call Proceeding message and receiving an AssignmentCommand message. On the other hand, on a MTC, it is the time between sending a CallConfirmed message and receiving an Assignment Command message.

• Assignment delay:Time between receiving an Assignment Command message and sending an AssignmentComplete message. As several assignment procedures can occur in a call, the output willbe a vector.

• Connect delay:On a MOC, time between receiving a Connect message and sending a Connect Acknowledgemessage. On the other hand, on a MTC, it is the time between sending a Connect messageand receiving a Connect Acknowledge message.

46

• First SMS delay:Time between sending or receiving a SMS Submit or a SMS Deliver message and receivingor sending a CP Acknowledgement message.

• Second SMS delay:Time between receiving or sending a CP Acknowledgement message and receiving or send-ing SMS Submit Report or SMS Deliver Report message.

• Third SMS delay:Time between receiving or sending a SMS Submit Report or SMS Deliver Report messageand sending or receiving a CP Acknowledgement message.

4.5.3 Measurement parameters

As it has been explain in Chapter 2: Background, some measurement information can befound in Measurement Report messages. Using this information we will be able to display thefollowing graphics:

• Receiving level of the serving cell (dBm)

• Mean BER of the serving cell (%)

• Receiving level of the neighbour cells (dBm)

The horizontal axis will be the time, that is why the assignment and the handover times are alsoincluded in the output. Therefore, it will be possible to observe the behaviour of the systemduring a handover for instance.

47

Chapter 5

Algorithm and results

Up to now, we are able to capture the Air interface traffic sent and received in the MS anddisplay it in Wireshark. An example of the captures obtained is presented in Figure 5.1.

Figure 5.1: Example of a capture displayed in Wireshark

48

With this information, we are able to manually get the KPIs defined in the previous chapter.Even though, our intention is to create a program to automatically compute these parameters.The following sections explain the usage method of this program, its implementation as well asthe results obtained.

5.1 Methodology

A python script has been developed to analyse the performance of GSM networks. The steps tofollow in order to obtain the outputs of this script are explained bellow:

1. Capture GSM traffic with Wireshark as detailed in Chapter 3: Design and develop-ment.

2. Export the capture to a plain text file called capture.txt going to File / Export PacketDissections / As ”Plain Text” file... and setting the option Packet details: All expanded.

3. Finally run the Python script from terminal or from any Python IDE.

As an output the program will return the KPIs calculated and two graphic windows - one withthe serving cell graphics and another with the neighbour cell graphic -. These KPIs will bedisplayed in the terminal and also saved in a text file generated by the script.

The main idea is that once we have a capture exported into plain text, the script will parsethe file obtaining the times and parameters that will later be processed to display the desiredKPIs.

5.2 Implementation

In this section there is an explanation of the script. Furthermore, there is also an explanation ofsome GSM theory in order to understand the parameters stored. The entire code can be foundin the Appendix A: Source Code.

First of all, the script opens the file capture.txt as f, reads the capture and save it in a variablecalled lines.

#Read the capture and save it in lines

with open ( ’ capture . txt ’ , ’ r ’ ) as f :l i n e s = f . r e a d l i n e s ( )

Then, it reads each line checking if it contains useful information. If so, it stores this informationin variables. Several functions have been defined in order to simplify the code. Here follows asimple example using the function readTime(line):

#Look for Alerting message time in a call

i f ’ (CC) Alert ing ’ in l i n e :t imeAlert = readTime ( l i n e )

49

Once this loop is over, the script proceeds to process the data to get the KPIs and the graphicsas an output. The first KPIs calculated are the general delays, followed by the particular delays.Finally, the script processes the data from the Measurement report messages and draws thegraphics using the matplotlib library.

To get the receiving level of a cell we have to look for the parameter RXLEV for the serv-ing cell or RXLEV-CELL for the neighbour cells. These parameters are coded as the binaryrepresentation of a value from 0 to 63 and maps from < -110 dBm to > -48 dBm in steps of 1dBm. Since we are getting an interval, the script will take the mean value.

This parameter gives an idea of the quality of the coverage. In Table 5.1, we can see therelation of the coverage with the signal strength of the cells.

Signal strength (dBm) Coverage

>= -100 Coverage

-110 < Signal strength <= -100 Bad coverage

< -110 Absence of coverage

Table 5.1: Coverage related to signal strength

Regarding to the mean BER of the serving cell, we have to look for the parameter RXQUAL.It is also the binary representation of a value from 0 to 7 mapping from < 0.2% to > 12.8%,every step doubling the previous value. As in the previous case, we take the mean value. Thefollowing table can be found in GSM, GPRS and EDGE performance (p. 161) [15].

RXQUAL BER (%) Assumed BER value (%)

1 < 0.2 0.142 0.2 - 0.4 0.283 0.4 - 0.8 0.574 0.8 - 1.6 1.135 1.6 - 3.2 2.266 3.2 - 6.4 4.537 6.4 - 12.8 9.058 > 12.8 18.1

Table 5.2: RXQUAL values and corresponding BER

As for the neighbour cells, each one is identified by its ARFCN. In Table 5.3 are shown the GSMbands and the ARFCN assigned to each of them1. A tricky point was knowing which ARFCNhad each neighbour cell. In order to know that, we had to look at the BCCH-FREQ-NCELLparameter that gives the index of a list of the ARFCN of the neighbour cells. This list had tobe created joining the ones provided in the messages System Information Type 5 and 5ter.

1GSM 45.005 - Version 10.0.0 (p. 16) [17]

50

Band Designation ARFCN fUL fDL

GSM 400 GSM 450 259-293 450,6+0,2(n-259) fUL(n)+10GSM 480 306-340 479+0,2(n-306) fUL(n)+10

GSM 700 GSM 750 438-511 747,2+0,2(n-438) fUL(n)+30

GSM 850 GSM 850 128-251 824,2+0,2(n-128) fUL(n)+45

GSM 900 P-GSM 1-124 890+0,2n fUL(n)+45E-GSM 0-124 890+0,2n fUL(n)+45

975-1023 890+0,2(n-1024) fUL(n)+45GSM-R 0-124 890+0,2n fUL(n)+45

955-1023 890+0,2(n-1024) fUL(n)+45

GSM 1800 DCS 1800 512-885 1710,2+0,2(n-512) fUL(n)+95

GSM 1900 PCS 1900 512-810 1850,2+0,2(n-512) fUL(n)+80

Table 5.3: ARFCN Table for common GSM systems

Nowadays, in Spain the bands used for GSM are GSM 900 and GSM 1800. In addition, it isused the UMTS2100 band for 3G systems and 4G LTE system is being introduced in the bandsof 800, 1800 and 2600 MHz.

5.3 Test and results

The intention of this section is to prove that the script developed works in a proper way andthat, over some conditions, it can provide statistical information from the performance of theoperators. For this purpose, some results and comparisons between the information obtainedwith different operators is presented. Later some of the outputs from the script are analysed inmore detail. It is important to clarify that the results showed throughout this section are takenin an static emplacement and, therefore, do not provide complete or reliable conclusions aboutthe performance from the operators.

5.3.1 Study of the results

In order to obtain some conclusions, we have taken the KPIs from each capture and have cal-culated the mean value of all KPI for each operator. There are from 20 to 40 captures for eachoperator and procedure. These final values can be find in the tables provided throughout thissection.

It could be interesting to compare our results with the ones provided by the operators2, butthe only one that we could compare is the Establishment time. Other parameters provided byoperators are related to percentages but, as we are not able to provide enough captures, ourpercentages wouldn’t be reliable. Moreover, the R value [21] is also provide by operators, butwe don’t have all the parameters to compute this value.

2Parametros relacionados con las llamadas from Telefonica Movistar Espana [18], Informe Trimestral Calidadde Servicio Telefonico Movil Orange (Periodo del 01-04-2013 al 30-06-2013) from France Telecom Espana [19],Informacion de calidad de servicio movil de Vodafone Espana, S.A.U. from Vodafone Espana [20] and Publicacionniveles calidad de servicio from Ministerio de Industria, Energıa y Turismo [1]

51

So, regarding to Establishment time, in Table 5.4 there is a comparative between the val-ues provide by the operators and the ones measured with the script. The results provided bythe operators are the mean value of the last five quarters throughout the country (until secondquarter of 2013) while our measurements are the mean value of the measures taken in the cam-pus during the third quarter of 2013. Here follows a list of the BTS offering GSM service closeto the campus.

• Movistar:

◦ Sor Eulalia Anzizu Street, 11. Assigned bands:

- 935.10 - 948.90 MHz

- 1805.10 - 1825.10 MHz

◦ Diagonal Avenue, 647. Assigned bands:

- 935.10 - 948.90 MHz

- 1805.10 - 1825.10 MHz


- 935.10 - 948.90 MHz

- 1805.10 - 1825.10 MHz

• Orange:

◦ Esplugues Avenue, 92. Assigned bands:

- 925.10 - 935.10 MHz

- 1859.90 - 1879.90 MHz

◦ Sor Eulalia Anzizu Street, 11. Assigned bands:

- 925.10 - 935.10 MHz

- 1859.90 - 1879.90 MHz


- 925.10 - 935.10 MHz

- 1859.90 - 1879.90 MHz

◦ Diagonal Avenue / Doctor Maranon Avenue. Assigned bands:

- 1859.90 - 1879.90 MHz

• Vodafone:

◦ Esplugues Avenue, 92-96. Assigned bands:

- 1825.10 - 1845.10 MHz


- 948.90 - 959.90 MHz

- 1825.10 - 1845.10 MHz

52

Figure 5.2: Map of the BTS surrounding the campus

The information regarding the location of the BTS classified by their operator is also graphicallyshown in Figure 5.2.3

In addition, we must have into account that the script is not able to calculate the establishmenttime in the way that the operators define it. It is defined from the reception of the address infor-mation by the network and the alerting in the calling part. Unfortunately, all we can calculateis from sending the address information and receiving the notification that the called party hasstarted the alerting in the MS. Even so, it should be possible to compare them.

As shown in Table 5.4, whereas Movistar mean establishment time differs in a little less than0.5 seconds, Vodafone mean establishment time varies by a almost than a 1.5 seconds and has ahigher standard deviation compared to Movistar. To study a little more deeply this parameterwe have taken captures from different hours of a day in order to check if it varies or stays con-

3Infoantenas [22]

53

stant. It should be remarked that the captures are not taken from a residential environment. Sofocussing on Movistar, the establishment time is lower for the first and last hours of the day andin the meantime is bigger. On the other hand, the establishment time for Vodafone is biggeruntil midday and then it decreases.

Establishment time Movistar Vodafone

Provided by operators (s) 5.736 5.288Mean value measured (s) 6.211 6.708

Standard deviation measured (s) 1.380 1.486

Mean value between 9 AM and 10 AM (s) 6.017 6.924Mean value between 12 PM and 13 PM (s) 6.631 6.862Mean value between 15 PM and 16 PM (s) 6.209 6.592Mean value between 18 PM and 19 PM (s) 5.986 6.454

Table 5.4: Establishment time comparative

Now that we have evaluated the only parameter that we are able to compare with the onesprovided by the operators, we are going to analyse the measured data between operators for allprocedures.

Connection establishment Movistar Orange Vodafone

Originated connection

CM Service Request delay (s) 0.1900 0.1913 0.1898GPRS Suspension delay (s) 0.2354 0.2354 0.2354Ciphering Mode delay (s) 0.2721 0.2694 0.2636Authentication delay (s) 0.4707 0.4708 0.3598Identity delay (IMEI) (s) - - 0.2813

Identity delay (IMEISV) (s) - 0.5161 0.5169

Terminated connection

Paging Response (s) 0.1897 0.1898 0.1899GPRS Suspension delay (s) 0.2353 0.2908 0.2497Ciphering Mode delay (s) 0.2633 0.3170 0.2928Authentication delay (s) 0.4697 0.4706 0.2820

TMSI Reallocation delay (s) 0.0460 0.0493 -Identity delay (IMEI) (s) - - 0.2825

Identity delay (IMEISV) (s) - 0.0578 0.0503

Table 5.5: Connection establishment KPIs comparative

To begin with, Table 5.5 shows all inner procedures regarding to connection establishment.Afterwards, these inner procedures will be evaluated again for each communication procedurein particular due to minor changes in the protocols that affect the results. In this comparative,KPIs from all operators are relatively similar - they vary less than a decimal - except for theAuthentication delay from Vodafone presumably due to the fact that the this operator only

54

sends the authentication parameter RAND and expects the SRES as response and the other twooperators send both RAND and AUTN parameters and expect SRES and XRES as response soit should take more time for them to compute the answers. It is important to remember thatwhile Vodafone uses twice an identity procedure to ask for both IMEI and IMEISV, Orangeonly asks for IMEISV and Movistar does not use this inner procedure.

Referring to the attach procedure, Table 5.6 presents all KPIs related with this procedure.Since it is a very simple and short procedure, there are no substantial variances in the results.As it can be seen in Figure 4.6: Attach on page 33, Movistar involves more inner procedures,therefore, it is the operator which takes more time to perform an attach. On the contrary,Orange is the operator that includes less inner procedures into the attach, so it is the operatorwith the smallest Total time connection. Even though, this parameter is similar for all of theoperators.

Attach Movistar Orange Vodafone

General KPIs

Total time connection (s) 1.1944 0.9747 1.0690

Particular KPIs

GPRS Suspension delay (s) 0.2353 - -Ciphering Mode delay (s) 0.0937 - -Authentication delay (s) 0.2813 0.2814 0.2803Identity delay (IMEI) (s) - - 0.0459Location Update delay (s) 0.6097 0.3794 0.5680

Table 5.6: Attach KPIs comparative

Next, Table 5.7 shows all KPIs concerning detach procedure. Again, since it is a very simpleand short procedure and all of the studied operators perform the same exchange of messages,differences are negligible - less than a decimal for Total time connection and less than two mil-liseconds for Detach indication delay.

Detach Movistar Orange Vodafone

General KPIs


Particular KPIs

Detach Indication delay (s) 0.1905 0.1903 0.1893

Table 5.7: Detach KPIs comparative

The Table 5.8 compares the KPIs related to MOC procedure. At first sight, some of the innerprocedures - such as CM Service Request delay, GPRS Suspension delay, Ciphering delay, As-signment delay and Connect delay - have roughly speaking the same delay. Differences appear,for instance, in the Authentication delay which is lower for Vodafone. This deviation, however,is lower than in the general connection establishment comparative because this time there is

55

an Identity Response between the Authentication Request and Response messages as it can beseen in Figure 4.9: MOC on page 35. On the contrary, there is no simple explanation for thegreat difference in the FACCH assignment delay. Regarding to general KPIs, delays are greaterfor Vodafone except for Handover delay. This deviation in Set up delay and Alerting delay isreasonable considering that Vodafone uses twice the Identity procedure and Movistar does not.The difference in the Call set up time can be explained in part for the Identity Response mes-sage send by the Vodafone MS. Finally, in the Establishment time, in addition to the IdentityResponse message from Vodafone, it may be involved the FACCH delay too.

MOC Movistar Vodafone

General KPIs

Establishment time (s) 6.2108 6.7082Call set up time (s) 0.2056 0.4253

Set up delay (s) 1.3418 1.5954Alerting delay (s) 7.3305 7.9050

Handover delay (s) 0.4036 0.3844

Particular KPIs

CM Service Request delay (s) 0.1899 0.1900GPRS Suspension delay (s) 0.2355 0.2355Ciphering Mode delay (s) 0.2752 0.2697Authentication delay (s) 0.4708 0.4382Identity delay (IMEI) (s) - 0.2812

Identity delay (IMEISV) (s) - 0.5168FACCH assignment delay (s) 0.4686 2.5650

Assignment delay (s) 0.2305 0.2268Connect delay (s) 0.0263 0.0375

Table 5.8: MOC KPIs comparative

In Table 5.9 there are shown KPIs related to MO-SMS. Most of the inner procedures - CMService Request delay, GPRS Suspension delay, Ciphering Mode delay, First and Third SMSdelay - have a discrepancy of less than 20 milliseconds. As regards to particular KPIs, thereis again a difference in the Authentication delay due to the same reason explained previously.The other considerable difference appears in the Second SMS delay which is greater for Orange,around 0.85 seconds more, although there are no changes in the messages exchanged involvingthis delay. Thus, most of general delays - SMS MO Access delay, Sending an SMS time and Totaltime communication - are greater for Orange. Finally, since Vodafone implements its protocolwith more inner procedures than Movistar, Movistar performs the lowest delays.

56

MO-SMS Movistar Orange Vodafone

General KPIs

SMS MO Access delay (s) 0.4257 1.3094 0.4493Sending an SMS time (s) 2.0513 3.3496 2.7928

Starting of sending an SMS delay (s) 1.5806 2.0991 2.2985Total time connection (s) 2.2773 3.5703 3.0055

Particular KPIs

CM Service Request delay (s) 0.1901 0.1913 0.1896GPRS Suspension delay (s) 0.2354 0.2354 0.2353Ciphering Mode delay (s) 0.2691 0.2694 0.2576Authentication delay (s) 0.4707 0.4708 0.2814Identity delay (IMEI) (s) - - 0.2815

Identity delay (IMEISV) (s) - 0.5161 0.5171First SMS delay (s) 0.1891 0.1900 0.1892

Second SMS delay (s) 0.2366 1.1193 0.2601Third SMS delay (s) 0.0451 0.0435 0.0567

Table 5.9: MO-SMS KPIs comparative

Regarding to MTC procedure, and remembering Figure 4.13: MTC on page 39, it can be seenin Table 5.104 that there is not much difference between Paging Request delay, GPRS ServiceRequest delay, Ciphering Mode delay nor Handover delay. We have already discussed aboutAuthentication delay: in addition to the difference on the parameters asked, Vodafone MS sendsa GPRS Suspension Request between the Authentication Request and Response messages sothe discrepancy in this value seems reasonable. In this case, the FACCH assignment delay isconsiderable - a little more than two decimals - but negligible compared to the same delay inMOC procedure. Looking at general KPIs, it is difficult to compare Set up delay and Alertingdelay because MTC protocol is implemented for each operator in a different way, for example,Movistar does not use Identity procedures. These changes, however, are consistent with thehigher delays from Vodafone. Lastly, it should be remarked that we do not have VodafoneAssignment delay information because the message Assignment Complete is never captured al-though we know it is send due to information frames.

Continuing with MT-SMS, in Table 5.115 it can be seen that Paging Response delay, GPRSSuspension delay, Ciphering Mode delay, First SMS delay have roughly the same delay. Thedifference between the authentication delay from Movistar and Orange is negligible. On theother hand, we know that Movistar does not perform identity procedures and Orange only asksfor the IMEISV. The discrepancy between Orange and Vodafone in the Identity delay (IMEISV)is again negligible. The main difference remains in the Second SMS delay which is greater forMovistar, around 0.5 seconds, although there is no change in the protocols implemented. Evenwith this variance, since Movistar MT-SMS involves less inner procedures, general KPIs such as

4Casually, none of the Vodafone MTC captures have had to use the TMSI reallocation procedure so there isno information of this delay.

5Casually, none of the Vodafone MT-SMS captures have had to use the authentication procedure and none ofthe MT-SMS captures from Movistar and Vodafone have had to use the TMSI reallocation procedure so there isno information of these delays.

57

Receiving an SMS time and Starting of receiving an SMS delay are lower for Movistar but, inthe end, Total time communication is similar for the three operators.

MTC Movistar Vodafone

General KPIs

Set up delay (s) 1.0248 1.6102Alerting delay (s) 2.4757 3.5068

Handover delay (s) 0.3938 0.2428

Particular KPIs

Paging Response delay (s) 0.1902 0.1901GPRS Suspension delay (s) 0.2352 0.2529Ciphering Mode delay (s) 0.2654 0.3044Authentication delay (s) 0.4685 0.2820

TMSI Reallocation delay (s) 0.0460 -Identity delay (IMEI) (s) - 0.2686

Identity delay (IMEISV) (s) - 0.0552FACCH assignment delay (s) 1.4454 1.2426

Assignment delay (s) 0.2572 -Connect delay (s) 0.2901 0.2425

Table 5.10: MTC KPIs comparative

MT-SMS Movistar Orange Vodafone

General KPIs

Receiving an SMS time (s) 1.8560 2.2750 2.3240Starting of receiving an SMS delay (s) 1.8124 2.1442 2.2811


Particular KPIs

Paging Response delay (s) 0.1892 0.1898 0.1897GPRS Suspension delay (s) 0.2354 0.2908 0.2466Ciphering Mode delay (s) 0.2581 0.3170 0.2813Authentication delay (s) 0.4709 0.4706 -

TMSI Reallocation delay (s) - 0.0493 -Identity delay (IMEI) (s) - - 0.2964

Identity delay (IMEISV) (s) - 0.0578 0.0454First SMS delay (s) 0.0436 0.0436 0.0429

Second SMS delay (s) 0.8709 0.3174 0.3528

Table 5.11: MT-SMS KPIs comparative

Finally, about MT-SMS in a call procedure, there is a variance of around 0.5 seconds in thedelays between operators although there are no changes in the protocol used. The capturesshow that the difference in the delay is mainly between the messages SMS Deliver and CP Ac-

58

knowledgement yet there is no big variance in the delay between the SABM U Frame and theSMS Deliver.

MT-SMS in a call Movistar Vodafone

General KPIs

Receiving an SMS in a call time (s) 4.9439 5.4127

Particular KPIs

First SMS delay (s) 1.9679 2.5535

Table 5.12: MT-SMS in a call KPIs comparative

Furthermore, information from measurement parameters can be used to calculate mean valuesof the serving cell for each operator and its standard deviation. These results are shown in Ta-ble 5.13. It can be observed that mean BER values are consistent with the mean receiving levels.

It is important to remark that these values are obtain from an static scenario, that is to say,all captures have been taken from the same emplacement. Therefore, maybe Vodafone has lesscoverage in this particular place and that is why the measurement parameters are higher andhigher delays might be expected. Finally, if we compare these values with the Table 5.1 onpage 50, we can conclude that all operators offer enough coverage on average where the captureshave been taken.

Serving cell Movistar Orange Vodafone

Receiving level (dBm) -92.9 -91.1 -95.9Standard deviation measured (dBm) 3.90 5.49 6.47

Mean BER (%) 0.88 0.50 2.37Standard deviation measured (%) 2.25 1.80 5.09

Table 5.13: Serving cell KPIs

With the measurement parameters and knowing when handovers procedures are executed, wecould track the behaviour of the serving and the neighbour cells. But, as we only capture mea-surement report messages before the assignment procedure - that is to say, before changing toFACCH channel -, we cannot observe this behaviour.

The following sections present and explain a particular capture for each operator.

59

5.3.2 Capture 1: Movistar Attach

This section presents an attach capture from Movistar in the case of a MS changing fromWCDMA to GSM. As it has been explained in Chapter 4: Protocols analysis, when a MSchanges from WCDMA to GSM, it includes a GPRS Suspension Request message. The completesignaling communication is shown in Figure 5.3 and follows the protocol defined in the previouschapter. Every information frame must be acknowledged either with another information frameor with a supervisory frame, consequently, the MS waits for a supervisory frame RR message toacknowledge the GPRS Suspension Request message before sending the Ciphering Mode Com-plete message.

Figure 5.3: Movistar attach

Next, Figure 5.4 details all KPIs for this capture. All of them present reasonable values accord-ing to the previous section. Ciphering Mode delay is greater than the average value because ofthe GPRS Suspension Request message and the RR S frame send between the Ciphering ModeCommand and Complete messages. Location Update delay is greater than the average valuesfor other operators due to the fact that there are more inner procedures involved in Movistar,for example Ciphering procedure. On the other side, measurement parameters indicate thatthere is good coverage - considering the receiving level always greater than -94.5 dBm and thatthe BER is the minimum assumed.

60

KPIs:

General delays:

- Total time connection: 1.32045s

Particular times or delays:

- SDCCH assign at 7.183374000s

- GPRS Suspension delay: 0.235444s

- Ciphering Mode delay: 0.281552s

- Location Updating delay: 0.709261s

Measurement parameters:

- Times:

[’8.010152000’, ’8.466966000’](s)

- Neighbour cells frequency list:

[’524’, ’526’, ’527’, ’528’, ’529’, ’530’, ’532’, ’533’, ’539’, ’544’,

’552’, ’554’, ’556’, ’566’, ’572’, ’576’, ’578’, ’580’, ’586’, ’588’]

- Receiving level of the serving cell:

[-94.5, -90.5](dBm)

- Mean BER of the serving cell:

[0.14, 0.14](%)

Figure 5.4: output.txt (Movistar attach)

These parameters can also be evaluated in the graphic in Figure 5.5. Since Measurement Reportmessages are sent every 470 ms and total time connection is 1.32 s, there are only two availablesamples.

61

Figure 5.5: Receiving level and Mean BER of the serving cell (Movistar attach)

62

5.3.3 Capture 2: Orange MT-SMS

It has been studied the average performance so far, but it also seems interesting to study whathappens when there is not good coverage. First the actual exchange of messages is presentedin Figure 5.6. In this figure, we can observe how the MS keeps sending each message until itreceives a supervisory frame RR message as an acknowledgement.

Figure 5.6: Orange MT-SMS

The amount of retransmissions notes that the serving cell does not have good coverage. In fact,that is confirmed in Figure 5.7 where the receiving level is always between -110 and -100 dBm.Moreover, the receiving level and the mean BER from the serving cell are consistent, that is tosay, the lower the receiving level, the higher the mean BER is. Otherwise, we could think thereare interferences afecting the communication.

63

Figure 5.7: Receiving level and Mean BER of the serving cell (Orange MT-SMS)

Additionally, Figure 5.8 shows information about neighbour cells. Even though there are neigh-bour cells with better characteristics than the serving cell - the one with ARFCN equal to 993,for instance -, a handover is not performed. As handover algorithms are specific for everyoperator and they do not have to publish them, we cannot explain accurately why a handoverprocedure is not perform. Probably, it is related with the short time of the connection: normally,to perform a handover it has to be checked that throughout enough time the new cell has bettercharacteristics than the serving cell. In addition, RXLEV is not the only parameter involvedin handover algorithms. As explained before, an example could be a MS which have enoughRXLEV level but, due to interferences, a bad RXQUAL level. Consequently this MS wouldhave coverage in terms of dBms but its BER would be too high for a proper communication.

64

Figure 5.8: Receiving level of the neighbour cells (Orange MT-SMS)

Finally, all KPIs explained in the previous chapter for this capture are shown in Figure 5.9,including the measurement parameters which have been previously evaluated in its graphicalform. Due to the behaviour of the cell, delays are much greater than usual. It is clear thatparticular delays involving messages which have been retransmitted - such as GPRS Suspensiondelay, Ciphering Mode delay and Identity delay - are greater than the average value for Orange,up to more than a second for Ciphering Mode delay for instance. Comparing general delays, thedifferences with the average values for Orange are around 1.5 seconds.

65

KPIs:

General delays:

- Sending or receiving an SMS time: 3.854731s

- Starting of sending or receiving an SMS delay: 3.811101s

- Total time connection: 4.27495s



- Paging Response delay: 0.189239s



- Identity delays: [0.51689]s

- First SMS delay: 0.04363s

- Second SMS delay: 0.235366s


- Times:

[’18.040864000’, ’18.511483000’, ’18.982233000’, ’19.452967000’,

’19.923719000’, ’20.394471000’, ’20.865227000’, ’21.373116000’](s)


[’818’, ’819’, ’823’, ’828’, ’829’, ’830’, ’831’, ’832’, ’833’, ’837’,

’840’, ’842’, ’844’, ’845’, ’850’, ’852’, ’855’, ’976’, ’977’, ’978’,

’979’, ’980’, ’983’, ’984’, ’985’, ’986’, ’987’, ’989’, ’990’, ’992’,

’993’]


[-108.5, -109.5, -105.5, -107.5, -105.5, -106.5, -100.5, -105.5](dBm)


[9.05, 8.1, 9.05, 9.05, 4.53, 9.05, 0.14, 4.53](%)

- Neighbours receiving level:

{’976’: [-109, -109, -109, -109, -109, -109, 0, -109],

’850’: [-105, -106, -105, -106, -106, -105, -105, -106],

’993’: [-96, -96, -96, -95, -96, -96, -96, -95],

’986’: [-109, -109, -109, -109, -109, -109, 0, -109],

’978’: [-109, -109, -101, -109, -101, -109, 0, -109],

’819’: [-107, -107, -106, -106, -107, -106, -107, -106]}(dBm)

Figure 5.9: output.txt (Orange MT-SMS)

66

5.3.4 Capture 3: Vodafone MT-SMS in a MOC

Lastly, this section presents a Vodafone MT-SMS in a MOC capture. Once again, the exchangeof messages is presented in Figure 5.10 where it can be seen as all information frames are ac-knowledged either with another information frame or a supervisory frame RR message.

Figure 5.10: Vodafone MT-SMS in a MOC

Taking a look upon the output.txt on Figure 5.11, it can be check that the delays are not farfrom the average ones provided before except for the FACCH Assignment delay which is arounda second greater with no apparent reason. There is no Assignment delay because the messageAssignment Completed is not captured. Regarding to measurement parameters, at first the celldoes not have good signal strength yet, as it recovers at the second measurement and none of

67

the neighbour cells have better characteristics, a handover is not necessary. The same behaviourapplies to the mean BER that is the minimum assumed from the second measurement.

KPIs:

General delays:

- Establishment time: 5.709272s

- Originated call set up time: 0.424977s

(Acceptable Call set up time < 5 s)

- Set Up delay: 1.440312s

- Alerting delay: 7.149584s

- Receiving an SMS in a call time: 5.279928s



- CM Service Request delay: 0.193761s



- Identity delays: [0.28518, 0.51665]s

- FACCH Assignment delay: 3.527151s

- Connect delay: 0.022932s

- First SMS delay: 2.398455s


- Times:

[’3.240283000’, ’3.726610000’, ’4.666465000’, ’5.123323000’](s)


[’692’, ’696’, ’699’, ’700’, ’702’, ’703’, ’706’, ’708’, ’710’, ’120’,

’118’, ’117’, ’116’, ’115’, ’114’, ’113’, ’112’, ’111’, ’110’, ’108’,

’2’, ’1’]


[-108.5, -89.5, -92.5, -92.5](dBm)


[4.53, 0.14, 0.14, 0.14](%)

- Neighbours receiving level:

{’692’: [0, 0, 0, -105], ’116’: [-109, -109, -97, -96],

’703’: [0, 0, 0, -103], ’120’: [-109, -102, 0, 0],

’2’: [-95, -95, -109, -109], ’111’: [0, 0, -106, 0],

’110’: [-105, -105, -105, -104], ’118’: [-104, -102, -109, -109]}(dBm)

Figure 5.11: output.txt (Vodafone MT-SMS in a MOC)

68

Measurement parameters previously discussed can be also seen in a graphic form in Figures 5.12for the serving cell and 5.13 for the neighbour cells.

Figure 5.12: Receiving level and Mean BER of the serving cell (Vodafone MT-SMS in a MOC)

69

Figure 5.13: Receiving level of the neighbour cells (Vodafone MT-SMS in a MOC)

70

Chapter 6

Conclusions

At this point, we will revise our objectives, the work done and the difficulties faced during thisproject. Later on, some suggestions on possible future work will be provided.

Regarding to the first objective of this project, understanding GSM traffic, we have been ableto describe the usual behaviour for each procedure and operator. As mentioned in Chapter 3:Design and development, the software xgoldmon has not worked as expected - the programdid not label right all channels and frequencies, sometimes it did not work or stopped workingunexpectedly with any apparent reason and so on. Yet, even so, throughout this memory it canbe seen that we have been able to capture and analyse GSM traffic in different situations andextract useful information.

In this respect, against our initial guess, there are plenty of variations from the standard andbetween operators in the some of the procedures namely attach, MOC, MTC, MO-SMS andMT-SMS. Mostly, these differences are focused on the connection establishment. In contrast,other procedures - detach, MT-SMS in a call, nonsynchronized intra-BSC handover or intra-MSChandover, synchronized intra-BTS handover, signaling during a communication and connectionrelease - may include differences with the standard but are equal for all the studied operators.

After the study of the procedures, a program has been successfully developed in Python. Thisscript returns several KPIs that have been defined based on the implementation of the proce-dures observed previously. With this information, we have been able to provide some parametersof GSM network procedures. As a result of the development of this tool, GSM users with anappropriated ME could execute the program and know KPIs values measured at their phoneswhich was another of our objectives.

Our idea was to demonstrate that our results could be compared with the ones published byoperators but, since most of them are percentages and we cannot make enough calls or coverenough range to get reliable percentages, we can only compare the establishment time. So, com-paring the measured establishment times with the ones provided by the operators, we concludethat they are very similar having into account that their computation is not exactly the samebecause we cannot perform measures from the network and ours are measured in a limited areaand time. Consequently, we could deduce that the information obtained is consistent and thus,the script outputs correct results.

71

Although we cannot compare any further published parameters, we can provide a set of pa-rameters not published such as delays and measurement parameters and compare them betweenthe operators at our disposal. These comparisons and their analysis are presented on Chapter5: Algorithm and results so the last of our objectives, evidence that the evaluation of GSMnetworks performance is possible using the script developed, is also accomplished.

6.1 Future work

We have been able to reach our objectives, however, there are still options to improve or extendour work.

At first sight, our results have been obtained with an sniffer that was not working as expected.Therefore, an improbable aspect of the project is proving the script with another protocol anal-yser. This could give us even more and more accurate information.

In addition, it is necessary to take into account that 3G systems are widely used and 4G systemsare being introduced. Therefore, we could extend the idea of this project to 3G and 4G systems.The trouble would be finding an open source sniffer able to decode these systems because theycould be not completely decoded as they are more recent.

(a) Screenshot from Netmonitor(b) Screenshot from G-MoN

Figure 6.1: Mobile applications

Although the protocol analyser used was an open source solution, there are also proprietarysolutions. Some examples of these proprietary solutions are, for instance, the GSM Air InterfaceProtocol Analyser from Smith Myers Communications Ltd [23], the AP6000 3GPP next gener-ation air protocol analyzer platform from ABIT Corporation [24] which can capture signaling

72

traffic from 2G and 3G systems and the the Agilent Signaling Analyzer [25] which works alsofor 3G and 4G systems and obtains the signaling throughout all the network, from the MS tothe Serving GPRS Support Node (SGSN) or the MSC.

Nevertheless, the usage of these solutions is not appropriate for our laboratory environmentneither affordable for us and it is difficult is to find an open source or affordable solution forany of the communication systems. With xgoldmon we were able to capture Radio ResourceControl (RRC) messages but could not decode them right. At the beginning of the project,when I was not able to run xgoldmon, I considered the idea of using another protocol analyseryet I was not able to find one. In this respect, an option could be trying with AirProbe [26], anAir interface analysis tool for GSM. This option would require the usage of a Universal SoftwareRadio Peripheral (USRP).

There are also some free or affordable mobile applications such as NetMonitor [27] or G-MoN[28] which give some parameters such as Serving the Cell ID, the receiving level, the LAC and soon. Figure 6.1 shows some of the information provided by NetMonitor and G-MoN. However,these kind of applications do not provide the complete information of the Air interface trafficneeded in order to run the script.

We have developed a PC integrated tool for laboratory environments. With the adaptationof this tool as a mobile application, we would be close to the concept of the user as a mobilesensor as it would provide several quality parameters instead of the few provided by the abovementioned applications.

Moreover, another possible extension of this project could be actually comparing the opera-tors performance. In order to to that we should increase the time period and the locations inwhich captures are taken. Thus would make our results more general and complete. Also, thecomparisons with the information published by operators would be more reliable.

73

Appendix A

Source Code

import matp lo t l i b . pyplot as p l timport numpy as np

v a l i d = False#True: Measurement values are valid

data = False#True: There is measurement report information

SMS = False#True: There is some SMS packet in the capture

c a l l = False#True: There is a SetUp message in the capture

o r i g = False#True: There is a Call Proceeding message in the capture (Originated Call)

term = False#True: There is a Call Confirmed message in the capture (Terminated Call)

l a s t = ’ ’#5: system information type 5 5ter: system information type 5ter

Neigh1 = FalseNeigh2 = False#True: List of neighbour cells stored

hand = 0#Counter: to match handover command/complete

a s s i g n = 0#Counter: to match assignm command/complete

iden = 0#counter to mach identity request/response

timeSDCCH = [ ]#time of the assignment of a SDCCH

timeSetUp= 0t imeCal l = 0t imeAlert = 0#times used to calculate Call Delays

time1SMS = 0time2SMS = 0time3SMS = [ ]SMSCall = 0#times used to calculate SMS Delays

timeMeas = 0#time of a measurement report

time1Hand = [ ]time2Hand = [ ]

74

#times for Handover

time1Ciph = 0time2Ciph = 0#times for Ciphering Command/Completed

time1Auth = 0time2Auth = 0#times for Authentication Request/Response

time1Con = 0time2Con = 0#times for Authentication Request/Response

t ime1Iden = [ ]t ime2Iden = [ ]#times for Identity Request/Response

t ime1Assign = [ ]t ime2Assign = [ ]#times for Identity Request/Response

time1Loc = 0time2Loc = 0#times for Location Updating Request/Accept

time1PagR = 0time2PagR = 0#times for Paging Response SABM , UA

time1SerReq = 0time2SerReq = 0#times for CM Service Request SABM , UA

timeClassChan = 0timeGPRS = 0#times for Classmark Change and GPRS Suspension Request

time1TMSI = 0time2TMSI = 0#times for TMSI Reallocation Command/Complete

time1Detach = 0time2Detach = 0#times for IMSI Detach Indication

SDCCH = 0#time of SDCCH assignment

delaySMS1 = 0delaySMS2 = 0delaySMS3 = 0t imeRelease = 0#time for Channel Release

Freq = [ ]BCCHFreq = [ ]#List of neighbour frequencies

rxne ig = [ ]#List of the receiving level of the neighbours (for each meaurement report)

#(len(rxneig) = number of neighbours)

r x l e v s = [ ]#List of all rxneig[]

r x l ev = [ ]#List of the receiving levels of the serving cell

rxqual = [ ]#List of the mean BER of the serving cell

BCCH = [ ]#List of the frequencies of the neighbours (for each measurement report)

BCCHs = [ ]#List of all BCCH[]

75

t imes = [ ]#List of the times of each valid measurement report

def readTime ( l i n e ) :f i r s t = Falsesecond = Falset = ’ ’for c in l i n e :

i f f i r s t == True and second == True and c == ’ ’ :return t

e l i f f i r s t == True and second == True and c != ’ ’ :t = t + c

e l i f c == ’ ’ and f i r s t == True :second = Truet = ’ ’

e l i f c != ’ ’ :f i r s t = True

def readRxlev ( l i n e ) :x = 0t = ’ ’for c in l i n e :

i f x > 31 and c != ’ ’ and ( c == ’0 ’ or c == ’1 ’ or c == ’2 ’ or \c== ’3 ’ or c==’4’ or c==’5’ or c==’6’ or c==’7’ or c==’8’ or c==’9’ or \c == ’− ’) :

t = t + ce l i f x > 31 and c == ’ ’ and t != ’ ’ :

return tx += 1

def readQual ( l i n e ) :x = 0t = ’ ’for c in l i n e :

i f x > 46 :t = t + c

x += 1return t

def readNumNeigh ( l i n e ) :x = 0for c in l i n e :

i f x > 42 :return c

x += 1

def readRxlevNeigh ( l i n e ) :x = 0long = Falset = ’ ’for c in l i n e :

i f x > 44 :

76

return te l i f x == 44 and c != ’0 ’ and c != ’1 ’ and c != ’2 ’ and c != ’3 ’ and \

c != ’4 ’ and c != ’5 ’ and c != ’6 ’ and c != ’7 ’ and c != ’8 ’ and c != ’9 ’ :return t

e l i f x > 42 :t = t + c

e l i f x ==35 and t == ’LE ’ :t = ’ ’long = True

e l i f x > 34 and long == False :return t

e l i f x == 34 and c != ’0 ’ and c != ’1 ’ and c != ’2 ’ and c != ’3 ’ and \c != ’4 ’ and c != ’5 ’ and c != ’6 ’ and c != ’7 ’ and c != ’8 ’ and c != ’9 ’ and t != ’L ’ :

return te l i f x > 32 and long == False :

t = t + cx += 1

def readBcchNeigh ( l i n e ) :x = 0long = Falset = ’ ’for c in l i n e :

i f x > 49 :return t

e l i f x == 49 and c != ’0 ’ and c != ’1 ’ and c != ’2 ’ and c != ’3 ’ and \c != ’4 ’ and c != ’5 ’ and c != ’6 ’ and c != ’7 ’ and c != ’8 ’ and c != ’9 ’ :

return te l i f x > 47 :

t = t + ce l i f x ==39 and t == ’RE’ :

t = ’ ’long = True

e l i f x > 38 and long == False :return t

e l i f x == 38 and c != ’0 ’ and c != ’1 ’ and c != ’2 ’ and c != ’3 ’ and \c != ’4 ’ and c != ’5 ’ and c != ’6 ’ and c != ’7 ’ and c != ’8 ’ and c != ’9 ’ and t != ’R’ :

return te l i f x > 36 and long == False :

t = t + cx += 1

def findSDCCH(timesSDCCH , t imeRelease , time1SerReq , time1PagR ) :i f l en (timeSDCCH) == 1 :

return timeSDCCH [ 0 ]else :

x = 0while x < l en (timeSDCCH) :

i f t imeRelease != 0 :i f f loat (timeSDCCH [ x ] ) > f loat ( t imeRelease ) :

return timeSDCCH [ x−1]i f time1SerReq != 0 :

i f f loat (timeSDCCH [ x ] ) > f loat ( time1SerReq ) :return timeSDCCH [ x−1]

i f time1PagR != 0 :

77

i f f loat (timeSDCCH [ x ] ) > f loat ( time1PagR ) :return timeSDCCH [ x−1]

i f x == len (timeSDCCH)−1:return timeSDCCH [ x ]

x += 1

def f indFreq ( l i n e , Freq ) :t = ’ ’for c in l i n e :

i f c == ’1 ’ or c == ’2 ’ or c == ’3 ’ or c == ’4 ’ or c == ’5 ’ or \c == ’6 ’ or c == ’7 ’ or c == ’8 ’ or c == ’9 ’ or c == ’ 0 ’ :

t = t + ce l i f ( c == ’ ’ and t != ’ ’ ) or c == ’\n ’ :

Freq . append ( t )t = ’ ’

return True

#Read the capture and save it in lines

with open ( ’ capture . txt ’ , ’ r ’ ) as f :l i n e s = f . r e a d l i n e s ( )

#Iteration through lines looking for all the parameters

for l i n e in l i n e s :#Look for SMS messages times

i f ’ (SMS) CP−DATA (RP) RP−DATA’ in l i n e :SMS = Truetime1SMS = readTime ( l i n e )

i f ’ (SMS) CP−DATA (RP) RP−ACK’ in l i n e :SMS = Truetime2SMS = readTime ( l i n e )

i f ’ (SMS) CP−ACK’ in l i n e :SMS = Truetime3SMS . append ( readTime ( l i n e ) )

i f ’ U P, func=SABM’ in l i n e :SMSCall = readTime ( l i n e )

#Look SDCCH assign delay times

i f ’ (RR) Immediate Assignment ’ in l i n e :time = readTime ( l i n e )

i f ’ This message a s s i g n s a ded icated mode resource ’ in l i n e :timeSDCCH . append ( time )

#Look for Setup message in a call times

i f ’ (CC) Setup ’ in l i n e :c a l l = TruetimeSetUp = readTime ( l i n e )

#Look for Call Proceeding message time in an Originated Call

i f ’ (CC) Cal l Proceeding ’ in l i n e :o r i g = Truet imeCal l = readTime ( l i n e )

#Look for Call Confirmed message time in a Terminated Call

i f ’ (CC) Cal l Confirmed ’ in l i n e :term = Truet imeCal l = readTime ( l i n e )

#Look for Alerting message time in a call

i f ’ (CC) Alert ing ’ in l i n e :t imeAlert = readTime ( l i n e )

#Look for a Handover messages times

78

i f ’ (RR) Handover Command’ in l i n e :i f hand == −2:

time1Hand . append (0)hand = 0

hand += 1time1Hand . append ( readTime ( l i n e ) )

i f ’ (RR) Handover Complete ’ in l i n e :i f hand == 2 :

time2Hand . append (0)hand = 0

hand −= 1time2Hand . append ( readTime ( l i n e ) )Neigh1 = FalseNeigh2 = Falsel a s t = ’ ’

#Look for a Assignment Command/Complete messages times

i f ’ (RR) Assignment Command’ in l i n e :i f a s s i g n == −2:

t ime1Assign . append (0)a s s i g n = 0

a s s i g n += 1time1Assign . append ( readTime ( l i n e ) )

i f ’ (RR) Assignment Complete ’ in l i n e :i f t ime1Assign == [ ] :

t ime1Assign . append (0)i f a s s i g n == 2 :

t ime2Assign . append (0)a s s i g n = 0

a s s i g n −= 1time2Assign . append ( readTime ( l i n e ) )

#Look for a Ciphering messages times

i f ’ (RR) Cipher ing Mode Command’ in l i n e :time1Ciph = readTime ( l i n e )

i f ’ (RR) Cipher ing Mode Complete ’ in l i n e :time2Ciph = readTime ( l i n e )

#Look for Authentication messages times

i f ’ (MM) Authent icat ion Request ’ in l i n e :time1Auth = readTime ( l i n e )

i f ’ (MM) Authent icat ion Response ’ in l i n e :time2Auth = readTime ( l i n e )

#Look for TMSI Reallocation messages times

i f ’ (MM) TMSI Rea l l o c a t i on Command’ in l i n e :time1TMSI = readTime ( l i n e )

i f ’ (MM) TMSI Rea l l o c a t i on Complete ’ in l i n e :time2TMSI = readTime ( l i n e )

#Look for IMSI Detach Indication messages times

i f ’ func=SABM(DTAP) (MM) IMSI Detach Ind i ca t i on ’ in l i n e :time1Detach = readTime ( l i n e )

i f ’ func=UA(DTAP) (MM) IMSI Detach Ind i ca t i on ’ in l i n e :time2Detach = readTime ( l i n e )

#Look for Identity messages times

i f ’ (MM) I d e n t i t y Request ’ in l i n e :i f iden == −2:

t ime1Iden . append (0)iden = 0

iden += 1time1Iden . append ( readTime ( l i n e ) )

79

i f ’ (MM) I d e n t i t y Response ’ in l i n e :i f t ime1Iden == [ ] or iden == 0 :

t ime1Iden . append (0)i f iden == 2 :

t ime2Iden . append (0)iden = 0

iden −= 1time2Iden . append ( readTime ( l i n e ) )

#Look for Location Updating messages times

i f ’ (MM) Locat ion Updating Request ’ in l i n e :time1Loc = readTime ( l i n e )

i f ’ (MM) Locat ion Updating Accept ’ in l i n e :time2Loc = readTime ( l i n e )

#Look for Connect / Connect acknowledge messages times

i f ’ (CC) Connect ’ in l i n e and time1Con == 0 :time1Con = readTime ( l i n e )

i f ’ (CC) Connect Acknowledge ’ in l i n e :time2Con = readTime ( l i n e )

#Look for Paging Response SABM/UA messages times

i f ’ func=SABM(DTAP) (RR) Paging Response ’ in l i n e :time1PagR = readTime ( l i n e )

i f ’ func=UA(DTAP) (RR) Paging Response ’ in l i n e :time2PagR = readTime ( l i n e )

#Look for Service Request SABM/UA messages times

i f ’ func=SABM(DTAP) (MM) CM S e r v i c e Request ’ in l i n e :time1SerReq = readTime ( l i n e )

i f ’ func=UA(DTAP) (MM) CM S e r v i c e Request ’ in l i n e :time2SerReq = readTime ( l i n e )

#Look for Classmark Change message time

i f ’ (RR) Classmark Change ’ in l i n e :timeClassChan = readTime ( l i n e )

#Look for GPRS Suspension Request message time

i f ’ (RR) GPRS Suspension Request ’ in l i n e :timeGPRS = readTime ( l i n e )

#Look for Channel Release message time

i f ’ (RR) Channel Release ’ in l i n e :t imeRelease = readTime ( l i n e )

#Look for System Information Type 5

i f ’ (RR) System Informat ion Type 5 ’ in l i n e :l a s t = ’5 ’

i f ’ (RR) System Informat ion Type 5 ter ’ in l i n e :l a s t = ’5 ter ’

#Look for List of ARFCNs

i f ’ L i s t o f ARFCNs’ in l i n e :i f l a s t == ’5 ’ and Neigh1 == False :

Neigh1 = f indFreq ( l i n e , Freq )i f l a s t == ’5 ter ’ and Neigh2 == False :

Neigh2 = f indFreq ( l i n e , Freq )#Look for a Measurement Report message time

i f ’ (RR) Measurement Report ’ in l i n e :timeMeas = readTime ( l i n e )

#Check if the measures are valid

i f ’MEAS−VALID: The measurement r e s u l t s are va l id ’ in l i n e :v a l i d = Truet imes . append ( timeMeas )

i f ’MEAS−VALID: The measurement r e s u l t s are not va l id ’ in l i n e :v a l i d = False

80

#Look for Receiving Level on the serving cell and append it to rxlev[]

i f ’RXLEV−SUB−SERVING−CELL’ in l i n e and v a l i d == True :r x l ev . append ( readRxlev ( l i n e ) )

#Look for Bit Error Rate on the serving cell and append it to rxqual[]

i f ’RXQUAL−FULL−SERVING−CELL’ in l i n e and v a l i d == True :RXQUAL = readQual ( l i n e )rxqual . append ( str (RXQUAL[ : −5 ] ) )

#Check from how many neighbour cells we have information(num)

i f ’NO−NCELL−M’ in l i n e and v a l i d == True :num = readNumNeigh ( l i n e )i f num == ”N” :

num = 0r x l e v s . append ( [ 0 ] )

ne ig = 0ne ig1 = 0

#Look for Receiving Level of each neighbour and append it to rxneig[]

#Once we have all the information append rxneig[] to rxlevs[]

i f ’RXLEV−NCELL’ in l i n e and v a l i d == True :l e v e l = readRxlevNeigh ( l i n e )i f ne ig == 0 :

del rxne ig [ : ]rxne ig . append ( int ( l e v e l )−110)i f ne ig==int (num)−1:

r x l e v s . append ( rxne ig [ : ] )ne ig = 0

ne ig+= 1#Look for BCCH carrier of each neighbour and append it to BCCH[]

#Once we have all the information append BCCH[] to BCCHs[]

i f ’BCCH−FREQ−NCELL’ in l i n e and v a l i d == True :bcch = readBcchNeigh ( l i n e )i f ne ig1 == 0 :

del BCCH [ : ]BCCH. append ( int ( bcch ) )i f ne ig1==int (num)−1:

BCCHs. append (BCCH[ : ] )ne ig1 = −1

ne ig1 += 1

#Prepare output.txt

with open ( ’ output . txt ’ , ’w’ ) as f :f . wr i t e (” KPIs :\n\n\nGeneral de lays :\n\n”)

#GENERAL DELAYS:

#CALLS:

SDCCH = findSDCCH(timeSDCCH , t imeRelease , time1SerReq , time1PagR )

#Establishment time

i f timeSetUp != 0 and t imeAlert != 0 :Es tab l i s h = f loat ( t imeAlert ) − f loat ( timeSetUp )with open ( ’ output . txt ’ , ’ a ’ ) as f :

print (” Establ i shment time : ”+ str ( Es tab l i sh )+”s ”)f . wr i t e (”\ tEstabl i shment time : ”+str ( Es tab l i sh )+”s \n\n”)

81

#Call set up time

i f ( c a l l == True and o r i g == True) or ( c a l l == True and term == True) :SetupTime = f loat ( t imeCal l ) − f loat ( timeSetUp )with open ( ’ output . txt ’ , ’ a ’ ) as f :

i f o r i g == True :print (” Or ig inated c a l l s e t up time : ” + str ( SetupTime )+”s \n\

( Acceptable Access Delay < 5 s ) ”)f . wr i t e (”\ tOr ig inated c a l l s e t up time : ” + str ( SetupTime )+”s \n\

\ t ( Acceptable Ca l l s e t up time < 5 s ) \n\n”)else :

print (” Terminated c a l l s e t up time : ” + str ( SetupTime )+”s \n\( Acceptable Access Delay < 5 s ) ”)

f . wr i t e (”\ tTerminated c a l l s e t up time : ” + str ( SetupTime )+”s \n\\ t ( Acceptable Access Delay < 5 s ) \n\n”)e l i f ( c a l l == False and ( o r i g == True or term == True) ) or ( c a l l == True and \( o r i g == False and term == False ) ) :

print ( ’ The capture i s not from a complete c a l l ’ )with open ( ’ output . txt ’ , ’ a ’ ) as f :

f . wr i t e ( ’\ t C a l l s e t up time : The capture i s not from a complete \c a l l \n\n ’ )

#Set Up delay

i f SDCCH != 0 and timeSetUp != 0 :Assign2SetUp = f loat ( timeSetUp ) − f loat (SDCCH)with open ( ’ output . txt ’ , ’ a ’ ) as f :

print (” Set Up delay ”+str ( Assign2SetUp )+”s ”)f . wr i t e (”\ tSet Up delay : ”+str ( Assign2SetUp )+”s \n\n”)

#Alerting delay

i f SDCCH != 0 and t imeAlert != 0 :Ass ign2Aler t = f loat ( t imeAlert ) − f loat (SDCCH)with open ( ’ output . txt ’ , ’ a ’ ) as f :

print (” A l e r t i ng de lay : ”+ str ( Ass ign2Alert )+”s ”)f . wr i t e (”\ t A l e r t i n g de lay : ”+str ( Ass ign2Aler t )+”s \n\n”)

# Handover delay

i f time2Hand != [ ] and time1Hand != [ ] :HandDelay = [ ]x = 0while x < l en ( time1Hand ) :

i f time1Hand [ x ] != 0 and time2Hand [ x ] != 0 :HandDelay . append ( round ( f loat ( time2Hand [ x ] )−f loat ( time1Hand [ x ] ) , 5) )

else :HandDelay . append ( ’ Incomplete ’ )

x += 1with open ( ’ output . txt ’ , ’ a ’ ) as f :

print (” Handover de lay : ” + str ( HandDelay )+”s ”)f . wr i t e (”\ tHandover de lay : ” + str ( HandDelay )+”s \n\n”)

#SMS

#SMS Mobile originated Access delay

i f SMS == True and time2SMS != 0 and time1SMS != 0 :

82

with open ( ’ output . txt ’ , ’ a ’ ) as f :SetupTime = f loat ( time2SMS ) − f loat ( time1SMS )print (”SMS mobile o r i g i n a t e d Access Delay : ” + str ( SetupTime )+”s \n”+\

”( Acceptable Access Delay < 2 s ) ”)f . wr i t e (”\tSMS mobile o r i g i n a t e d Access Delay : ” + str ( SetupTime )+\

” s \n\ t ( Acceptable Access Delay < 2 s ) \n\n”)

#Sending or receiving an SMS time:

i f SMS == True and c a l l == False and o r i g == False and term == False :i f l en ( time3SMS ) == 1 :

TimeSMS = f loat ( time3SMS [ 0 ] ) − f loat (SDCCH)else :#elif len(time3SMS) == 2:

TimeSMS = f loat ( time3SMS [ 1 ] ) − f loat (SDCCH)with open ( ’ output . txt ’ , ’ a ’ ) as f :

print (” Sending or r e c e i v i n g an SMS time : ”+str (TimeSMS)+”s ”)f . wr i t e (”\ tSending or r e c e i v i n g an SMS time : ”+str (TimeSMS)+”s \n\n”)

#Receiving an SMS in a call time:

e l i f SMS == True and ( ( c a l l == True and o r i g == True) or ( c a l l == True and \term == True) ) :

i f l en ( time3SMS ) == 1 :TimeSMS = f loat ( time3SMS [ 0 ] ) − f loat ( SMSCall )

e l i f l en ( time3SMS ) == 2 :TimeSMS = f loat ( time3SMS [ 1 ] ) − f loat ( SMSCall )

with open ( ’ output . txt ’ , ’ a ’ ) as f :print (” Rece iv ing an SMS in a c a l l time : ”+str (TimeSMS)+”s ”)f . wr i t e (”\ tRece iv ing an SMS in a c a l l time : ”+str (TimeSMS)+”s \n\n”)

#Starting of sending or receiving an SMS delay

i f SDCCH != 0 and time1SMS != 0 and c a l l == False :Assign2SMS = f loat ( time1SMS ) − f loat (SDCCH)with open ( ’ output . txt ’ , ’ a ’ ) as f :

print (” S ta r t i ng o f sending or r e c e i v i n g an SMS delay : ”+\str ( Assign2SMS )+”s ”)

f . wr i t e (”\ t S t a r t i n g o f sending or r e c e i v i n g an SMS delay : ”\+ str ( Assign2SMS )+”s \n\n”)

#Total time Connection:

i f SDCCH != 0 and t imeRelease != 0 :Total = f loat ( t imeRelease ) − f loat (SDCCH)with open ( ’ output . txt ’ , ’ a ’ ) as f :

print (” Total time connect ion : ”+str ( Total )+”s ”)f . wr i t e (”\ tTota l time connect ion : ”+str ( Total )+”s \n\n”)

with open ( ’ output . txt ’ , ’ a ’ ) as f :f . wr i t e (” P a r t i c u l a r t imes or de lays :\n\n”)

#SDCCH assignment time:

i f SDCCH != 0 :with open ( ’ output . txt ’ , ’ a ’ ) as f :

print (”SDCCH a s s i g n at ”+str (SDCCH)+”s ”)f . wr i t e (”\tSDCCH a s s i g n at ”+str (SDCCH)+”s \n\n”)

83

e l i f timeSDCCH != [ ] :with open ( ’ output . txt ’ , ’ a ’ ) as f :

print (”SDCCHs a s s i g n at ”+str (timeSDCCH)+”s ”)f . wr i t e (”\tSDCCHs a s s i g n at ”+str (timeSDCCH)+”s \n\n”)

#Handover completed times:

i f time2Hand != [ ] :with open ( ’ output . txt ’ , ’ a ’ ) as f :

print (” Handover completed at ”+str ( time2Hand )+”s ”)f . wr i t e (”\ tHandover completed at ”+str ( time2Hand )+”s \n\n”)

#Paging Response delay:

i f time1PagR != 0 and time2PagR != 0 :PagRDelay = f loat ( time2PagR ) − f loat ( time1PagR )with open ( ’ output . txt ’ , ’ a ’ ) as f :

print (” Paging Response de lay : ”+str ( PagRDelay )+”s ”)f . wr i t e (”\ tPaging Response de lay : ”+str ( PagRDelay )+”s \n\n”)

#CM Service Request delay:

i f time1SerReq != 0 and time2SerReq != 0 :SerReqDelay = f loat ( time2SerReq ) − f loat ( time1SerReq )with open ( ’ output . txt ’ , ’ a ’ ) as f :

print (”CM S e r v i c e Request de lay : ”+str ( SerReqDelay )+”s ”)f . wr i t e (”\tCM S e r v i c e Request de lay : ”+str ( SerReqDelay )+”s \n\n”)

#Classmark Change -GPRS Suspension request delay:

i f timeClassChan != 0 and timeGPRS != 0 :GPRSDelay = f loat ( timeGPRS) − f loat ( timeClassChan )with open ( ’ output . txt ’ , ’ a ’ ) as f :

print (”GPRS Suspension de lay :”+ str (GPRSDelay)+”s ”)f . wr i t e (”\tGPRS Suspension de lay : ”+str (GPRSDelay)+”s \n\n”)

#Ciphering Mode delay:

i f time1Ciph != 0 and time2Ciph != 0 :CiphDelay = f loat ( time2Ciph ) − f loat ( time1Ciph )with open ( ’ output . txt ’ , ’ a ’ ) as f :

print (” Cipher ing Mode de lay :”+ str ( CiphDelay )+”s ”)f . wr i t e (”\ tCipher ing Mode de lay : ”+str ( CiphDelay )+”s \n\n”)

#TMSI Reallocation delay:

i f time1TMSI != 0 and time2TMSI != 0 :TMSIDelay = f loat ( time2TMSI ) − f loat ( time1TMSI )with open ( ’ output . txt ’ , ’ a ’ ) as f :

print (”TMSI Rea l l o ca t i on de lay :”+ str ( TMSIDelay )+”s ”)f . wr i t e (”\tTMSI Rea l l o ca t i on de lay : ”+str (TMSIDelay )+”s \n\n”)

#Authentication delay:

i f time1Auth != 0 and time2Auth != 0 :AuthDelay = f loat ( time2Auth ) − f loat ( time1Auth )with open ( ’ output . txt ’ , ’ a ’ ) as f :

84

print (” Authent icat ion de lay :”+ str ( AuthDelay )+”s ”)f . wr i t e (”\ tAuthent i ca t ion de lay : ”+str ( AuthDelay )+”s \n\n”)

#Identity delay:

i f t ime1Iden != [ ] and t ime2Iden != [ ] :IdenDelay = [ ]x = 0while x < l en ( t ime1Iden ) and x < l en ( t ime2Iden ) :

i f t ime1Iden [ x ] != 0 and t ime2Iden [ x ] != 0 :IdenDelay . append ( round ( f loat ( t ime2Iden [ x ] )−f loat ( t ime1Iden [ x ] ) , 5) )

else :IdenDelay . append ( ’ Incomplete ’ )


print (” I d e n t i t y de lays : ”+str ( IdenDelay )+”s ”)f . wr i t e (”\ t I d e n t i t y de lays : ”+str ( IdenDelay )+”s \n\n”)

#Location Updating delay:

i f time1Loc != 0 and time2Loc != 0 :LocDelay = f loat ( time2Loc ) − f loat ( time1Loc )with open ( ’ output . txt ’ , ’ a ’ ) as f :

print (” Locat ion Updating de lay : ”+str ( LocDelay )+”s ”)f . wr i t e (”\ tLocat ion Updating de lay : ”+str ( LocDelay )+”s \n\n”)

#Detach Indication delay:

i f time1Detach != 0 and time2Detach != 0 :DetachDelay = f loat ( time2Detach ) − f loat ( time1Detach )with open ( ’ output . txt ’ , ’ a ’ ) as f :

print (” Detach I n d i c a t i o n de lay : ”+str ( DetachDelay )+”s ”)f . wr i t e (”\ tDetach I n d i c a t i o n de lay : ”+str ( DetachDelay )+”s \n\n”)

#FACCH assignment delay

i f t ime1Assign != [ ] and t ime1Assign [ 0 ] != 0 and t imeCal l != 0 :FACCHDelay = f loat ( t ime1Assign [ 0 ] ) − f loat ( t imeCal l )with open ( ’ output . txt ’ , ’ a ’ ) as f :

print (”FACCH Assignment de lay : ”+str (FACCHDelay)+”s ”)f . wr i t e (”\tFACCH Assignment de lay : ”+str (FACCHDelay)+”s \n\n”)

#Assignment delay

i f t ime2Assign != [ ] and t ime1Assign != [ ] :AssignDelay = [ ]x = 0while x < l en ( t ime1Assign ) and x < l en ( t ime2Assign ) :

i f t ime1Assign [ x ] != 0 and t ime2Assign [ x ] != 0 :AssignDelay . append ( round ( f loat ( t ime2Assign [ x ] )−\f loat ( t ime1Assign [ x ] ) , 5) )

else :AssignDelay . append ( ’ Incomplete ’ )


print (” Assignment de lay : ” + str ( AssignDelay )+”s ”)f . wr i t e (”\ tAssignment de lay : ” + str ( AssignDelay )+”s \n\n”)

85

#Connect delay

i f time1Con != 0 and time2Con != 0 and time1Con < time2Con :ConDelay = f loat ( time2Con ) − f loat ( time1Con )with open ( ’ output . txt ’ , ’ a ’ ) as f :

print (” Connect de lay : ”+str ( ConDelay )+”s ”)f . wr i t e (”\ tConnect de lay : ”+str ( ConDelay )+”s \n\n”)

#SMS delays

#First SMS delay

i f time1SMS != 0 and time3SMS != [ ] :i f f loat ( time3SMS [ 0 ] ) < f loat ( time2SMS ) and time2SMS != 0 :

delaySMS1 = f loat ( time3SMS [ 0 ] ) − f loat ( time1SMS )e l i f f loat ( time3SMS [ 0 ] ) > f loat ( time1SMS ) :

delaySMS1 = f loat ( time3SMS [ 0 ] ) − f loat ( time1SMS )i f delaySMS1 != 0 :

with open ( ’ output . txt ’ , ’ a ’ ) as f :print (” F i r s t SMS delay : ”+str ( delaySMS1 )+”s ”)f . wr i t e (”\ t F i r s t SMS delay : ”+str ( delaySMS1 )+”s \n\n”)

#Second SMS delay

i f time2SMS != 0 and time3SMS != [ ] :i f l en ( time3SMS )==1:

i f f loat ( time3SMS [ 0 ] ) < f loat ( time2SMS ) :delaySMS2 = f loat ( time2SMS ) − f loat ( time3SMS [ 0 ] )

e l i f l en ( time3SMS )==2:i f f loat ( time3SMS [ 0 ] ) < f loat ( time2SMS ) :

delaySMS2 = f loat ( time2SMS ) − f loat ( time3SMS [ 0 ] )i f delaySMS2 != 0 :

with open ( ’ output . txt ’ , ’ a ’ ) as f :print (” Second SMS delay : ”\

+str ( delaySMS2 )+”s ”)f . wr i t e (”\ tSecond SMS delay : ”+str ( delaySMS2 )+”s \n\n”)

#Third SMS delay

i f time2SMS != 0 and time3SMS != [ ] :i f l en ( time3SMS )==1:

i f f loat ( time3SMS [ 0 ] ) > f loat ( time2SMS ) :delaySMS3 = f loat ( time3SMS [ 0 ] ) − f loat ( time2SMS )

e l i f l en ( time3SMS )==2:i f f loat ( time3SMS [ 1 ] ) > f loat ( time2SMS ) :

delaySMS3 = f loat ( time3SMS [ 1 ] ) − f loat ( time2SMS )i f delaySMS3 != 0 :

with open ( ’ output . txt ’ , ’ a ’ ) as f :print (” Third SMS delay : ”+str ( delaySMS3 )+”s ”)f . wr i t e (”\ tThird SMS delay : ”+str ( delaySMS3 )+”s \n\n”)

with open ( ’ output . txt ’ , ’ a ’ ) as f :f . wr i t e (” Measurement parameters :\n\n”)

86

# Rxlev is a list of the mean Receiving level

i f r x l ev != [ ] :Rxlev = [ ]r e c = ””for item in r x l ev :

i f item == None :Rxlev . append (0)r ec = ””

else :for c in item :

r ec = rec + ci f r e c == ”Unknown ” :

Rxlev . append (0)r ec = ””

else :Rxlev . append ( int ( r e c ) +0.5)r ec = ””

# Plot of Rxlev with matplotlib

p l t . f i g u r e (1 )p l t . subp lot (211)p l t . p l o t ( times , Rxlev , ”o−”)p l t . y l a b e l (” Rece iv ing l e v e l (dBm) ”)p l t . x l a b e l (”Time ( s ) ”)p l t . t i t l e (” Rece iv ing Leve l o f the s e r v in g c e l l ”)p l t . g r i d (True)data = True

# Rxqual is a list of the mean BER

i f rxqual != [ ] :Rxqual = [ ]qual = ””for item in rxqual :

x = 0l = len ( item )−5while x < 4 :

qual = qual + item [ l+x ]x = x + 1

i f qual == ” 8 . 1 0 ” :qual = ”18.1”

Rxqual . append ( f loat ( qual ) )qual = ””

# Plot of Rxqual with matplotlib

p l t . subp lot (212)p l t . p l o t ( times , Rxqual , ”o−”)p l t . y l a b e l (”BER (%) ”)p l t . x l a b e l (”Time ( s ) ”)p l t . t i t l e (”Mean BER of the s e r v in g c e l l ”)p l t . g r i d (True)data = True

# Neighbour is a dictionary -> "BCCH": [Receiving Levels]

i f rxne ig != [ ] and Freq != [ ] and Neigh1 == True and Neigh2 == True :Neighbours = {}a = 0x = 0

87

z = 0max1 = 0#Number of items in Neighbours.values()

max2 = 1#Max number of items in Neighbours.values(). Used to check if we have to

#append 0 to a frequency from which we don’t have information

f i r s t = TruenoData = 0#Number of packets in a row without neighbours information

c l e a r = False#True: we have append zeros to the positions without information and can

#reset noData = 0 and clear = False

for bcch in BCCHs:x = len ( bcch )aux = [ ]for item in bcch :

aux . append ( Freq [ item −1])x = x − 1i f x == 0 :

BCCHFreq . append ( aux )for item in r x l e v s :

i f item == [ 0 ] :BCCHFreq . i n s e r t ( z , [ ] )

z += 1#We append [] for each packet without information

for item in BCCHFreq :y = 0i f x == 1 :

f i r s t = Falsefor f r e q in Neighbours :

i f max1 < l en ( Neighbours [ f r e q ] ) :max1 = len ( Neighbours [ f r e q ] )

i f item ==[] :noData += 1

for i in item :i f str ( i ) not in Neighbours . keys ( ) :

i f f i r s t == True :Neighbours [ str ( i ) ] = [ ]

else :Neighbours [ str ( i ) ] = [ 0 ]∗max1

i f noData != 0 :while a < noData :

Neighbours [ str ( i ) ] . append (0)a +=1

a = 0c l e a r = True

Neighbours [ str ( i ) ] . append ( r x l e v s [ x ] [ y ] )y += 1

for f r e q in Neighbours :i f max2 < l en ( Neighbours [ f r e q ] ) :

max2 = len ( Neighbours [ f r e q ] )for f r e q in Neighbours :

i f l en ( Neighbours [ f r e q ] )< max2 :Neighbours [ f r e q ] . append (0 )

i f c l e a r == True :noData = 0c l e a r = False

88

x += 1#If we don’t have information of the last measurement packets

i f noData != 0 :for f r e q in Neighbours :

while a < noData :Neighbours [ f r e q ] . append (0 )a +=1

a = 0for f r e q in Neighbours :

i f l en ( Neighbours [ f r e q ] )< max2 :Neighbours [ f r e q ] . append (0 )

#Plot Neighbours (bar chart)

p l t . f i g u r e (2 )c o l o r s = [ ’ Blue ’ , ’ Green ’ , ’Red ’ , ’Aqua ’ , ’ Purple ’ , ’ Yellow ’ , ’Maroon ’ , \’ Olive ’ , ’ Teal ’ , ’ Lime ’ , ’ Black ’ ]x = [ ]for item in t imes :

x . append ( str ( round ( f loat ( item ) , 3) ) )x1 = np . arange ( l en ( x ) )w = 0 .1 #bar width

c = 0i = 0 #color index

for item in Neighbours :p l t . bar ( x1 + [ c∗w]∗ l en ( x ) , Neighbours [ item ] , w, c o l o r = c o l o r s [ i ] , \a l i g n = ’ center ’ )c += 1i += 1

p l t . x t i c k s ( x1+(w∗ l en ( Neighbours ) ) /2 , x )p l t . y l a b e l (” Rece iv ing l e v e l (dBm) ”)p l t . x l a b e l (”Time ( s ) ”)p l t . l egend ( Neighbours . keys ( ) , l o c = 0)p l t . t i t l e (” Neighbours Rece iv ing Leve l s ”)p l t . g r i d (True)data = True

i f data == True :with open ( ’ output . txt ’ , ’ a ’ ) as f :

f . wr i t e ( ’\ tTimes :\n ’ )f . wr i t e ( ’\ t ’+ str ( t imes ) + ’( s ) \n\n ’ )f . wr i t e ( ’\ tNeighbour c e l l s f requency l i s t :\n ’ )f . wr i t e ( ’\ t ’+ str ( Freq ) +’\n\n ’ )f . wr i t e ( ’\ tRece iv ing l e v e l o f the s e rv in g c e l l :\n ’ )f . wr i t e (”\ t”+str ( Rxlev ) +”(dBm) \n\n”)f . wr i t e ( ’\ tMean BER of the s e rv in g c e l l :\n ’ )f . wr i t e (”\ t”+str ( Rxqual )+”(%)\n\n”)i f rxne ig != [ ] and Freq != [ ] and Neigh1 == True and Neigh2 == True :

f . wr i t e ( ’\ tNeighbours r e c e i v i n g l e v e l :\n ’ )f . wr i t e (”\ t”+str ( Neighbours ) +”(dBm) \n\n”)

print (” Rece iv ing l e v e l o f the s e r v in g c e l l : ”)print Rxlev ,print ”(dBm) ”print (”Mean BER of the s e r v i ng c e l l : ”)print Rxqual ,print ”(%)”i f rxne ig != [ ] and Freq != [ ] and Neigh1 == True and Neigh2 == True :

print (” Rece iv ing l e v e l o f the neighbour c e l l s : ” )

89

print Neighbours ,print ”(dBm) ”

p l t . show ( )else :

with open ( ’ output . txt ’ , ’ a ’ ) as f :f . wr i t e ( ’\ tThere i s no data from measurement repor t s ’ )

print (” There i s no data from measurement r e p o r t s ”)

90

Bibliography

[1] Ministerio de Industria, Energıa y Turismo, “Publicacion niveles calidad de ser-vicio,” http://www.minetur.gob.es/telecomunicaciones/es-ES/Servicios/CalidadServicio/1PublicacionNivelesCalidad/Paginas/calidades.aspx, October 2013.

[2] G. Heine, GSM Networks: Protocols, Terminology and Implementation. Artech House,1999.

[3] GSM 04.08 - Version 5.3.0, ETSI, July 1996.

[4] J. Eberspacher, H.-J. Vogel, C. Bettstetter, and C. Hartmann, GSM Architecture, Protocolsand Services, 3rd ed. Wiley, 2009.

[5] M. Barnes, GPRS Overview, http://www.afn.org/∼afn48922/downs/wireless/mbgprs.pdf,Nortel Networks, November 1998.

[6] S. Putz, R. Schmitz, and T. Martin, Security Mechanisms in UMTS, 2001.

[7] G. L. Bodic, Mobile messaging technologies and services. SMS, EMS and MMS. JohnWiley and Sons, LTD, 2003.

[8] J. Eberspacher and H.-J. Vogel, GSM Switching services and protocols, 2nd ed. Wiley,2001.

[9] GSM 04.11 - Version 5.1.0, ETSI, March 1996.

[10] T. Engel, “xgoldmon - GitHub,” https://github.com/2b-as/xgoldmon, March 2013.

[11] Wireshark Foundation, “Wireshark - Go deep,” http://www.wireshark.org/, March 2013.

[12] Python Software Foundation, “Python Programming Language,” http://www.python.org/,June 2013.

[13] Matplotlib development team, “Matplotlib: python plotting,” http://matplotlib.org/, June2013.

[14] S. Michiels, “SPE IDE - Stani’s Python Editor,” http://pythonide.blogspot.com.es/, June2013.

[15] T. Halonen, J. Romero, and J. Melero, GSM, GPRS and EDGE performance. Evolutiontowards 3G/UMTS, 2nd ed. Wiley, 2003.

[16] W. Tauqir, “Mobile cellular quality of service,” PTA (Pakistan Telecommunication Author-ity), Tech. Rep., April 2010.

91

[17] GSM 45.005 - Version 10.0.0, ETSI, April 2011.

[18] Telefonica Moviles Espana, “Parametros relacionados con las llamadas,” http://info.telefonica.es/es/calidad/html/tme/parametros llamadas.shtml, September 2013.

[19] France Telecom Espana, “Informe trimestral calidad de servicio telefonico movil orange(periodo del 01-04-2013 al 30-06-2013),” http://acercadeorange.orange.es/UpImages/files/2186/inf calidad movil ftet 32871ae89d6ed9b92c045738f.pdf, September 2013.

[20] Vodafone Espana, “Informacion de calidad de servicio movil de Vodafone Espana, S.A.U.”http://www.vodafone.es/static/fichero/pro ucm mgmt 018891.pdf?frame=1, September2013.

[21] ITU, “R Value Calculation,” http://www.itu.int/ITU-T/studygroups/com12/emodelv1/calcul.php, October 2013.

[22] Secretaria de estado de telecomunicaciones y para la sociedad de la informacion, “Infoan-tenas,” http://geoportal.mityc.es/VCTEL/vcne.do, September 2013.

[23] Smith Myers Communications Ltd, “GSM Air Interface Protocol Analyser,” http://www.smithmyers.com/documents/csm88xxg.pdf, October 2013.

[24] ABIT Corporation, “Air Protocol Analyzer AP-6000,” http://www.abit.co.jp/english/product/pdf/AP6000presen.pdf, October 2013.

[25] Agilent Technologies, “Agilent Signaling Analyzer. Technical Overview,” http://cp.literature.agilent.com/litweb/pdf/5989-0347EN.pdf, October 2013.

[26] “Airprobe,” https://svn.berlin.ccc.de/projects/airprobe/, October 2013.

[27] Google Play, “Netmonitor,” https://play.google.com/store/apps/details?id=com.parizene.netmonitor&hl=es, November 2013.

[28] C. Knuetter, “G-MoN,” https://www.wardriving-forum.de/wiki/G-MoN, November 2013.

[29] G. Gu and G. Peng, The Survey of GSM Wireless Communication System, InternationalConference on Computer and Information Application, 2010.

[30] Layer 3 GSM signaling protocols messages, ISEL (Instituto Superior de Engenharia deLisboa).

[31] M. Glendrange, K. Hove, and E. Hvideberg, “Decoding GSM,” Master’s thesis, NorwegianUniversity of Science and Technology, 2010.

[32] G. K. Patnaik, “GSM Short Message Service,” March 2013.

92

Development of a tool for GSM networks performance...

Documents

Transcript of Development of a tool for GSM networks performance...