Development of a tool for GSM networks performance ...

Final Degree Thesis
Development of a tool for GSM networks performance analysis and evaluation
Telecommunications Engineering
ii
Acknowledgements
First, I would like to thank Josep Paradells Aspas, the director of this thesis, and the Wireless Networks Group for giving me the opportunity to carry out my project. I also would like to thank my workplace colleagues for making of these months such a good experience with their company. 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 la nostra societat i aquest segueix augmentant. Per tant, es important disposar d’una xarxa capac de proporcionar prou capacitat i una qualitat de servei mnima. Existeixen lleis per tal de regular les condicions mnimes de la qualitat de servei oferta pero, normalment, els informes per acreditar aquests mnims els fan les mateixes operadores. Com a consequencia, els resultats poden no ser del tot fiables sobretot quan trobem usuaris que no perceben la qualitat de servei que els operadors diuen oferir.
Aquest projecte estudia els protocols implementats per diverses operadores i intenta proporcionar un sistema d’avaluacio interactiu on l’usuari final es capac de realitzar mesures de la xarxa. Per aconseguir aquest objectiu s’ha desenvolupat una aplicacio en llenguatge Python i entorn Linux. Aquesta aplicacio s’executa des d’un ordinador despres que s’hagi capturat trafic de senyalitzacio GSM. Com a resultat obtenim Indicadors Clau de Rendiment de la xarxa estudiada. Finalment, estenent l’us de l’aplicacio en el temps i sobre prou territori, seria possible proveir 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 tambe en docencia.
iv
Resumen
Las comunicaciones moviles han experimentado un fuerte crecimiento en los ultimos anos en nuestra sociedad y este sigue aumentando. Por lo tanto, es importante disponer de una red capaz de proporcionar suficiente capacidad y una calidad de servicio mnima. Aunque existen leyes para regular las condiciones mnimas de la calidad de servicio ofertada, los informes para acreditar estos mnimos suelen estar hechos por los propios operadores. En consecuencia, los resultados pueden no ser del todo fiables sobretodo cuando nos encontramos con usuarios que no perciben la calidad de servicio que los operadores dicen ofrecer.
Este proyecto estudia los protocolos implementados por distintos operadores e intenta proporcionar un sistema de evaluacion interactivo donde el usuario es capaz de realizar medidas de la red. 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 trafico de senalizacion GSM. Como resultado se obtienen Indicadores Clave de Rendimiento de la red estudiada. Finalmente, extendiendo el uso de la aplicacion en el tiempo y sobre suficiente terri- torio, sera posible proporcionar parametros de calidad tambien publicados por los operadores y evaluar su funcionamiento.
Tanto el estudio de los protocolos como la aplicacion desarrollada estan pensados para ser utilizados tambien en docencia.
v
Abstract
Mobile communications have had an strong growth in our society in the recent years and it keeps increasing. Therefore, it is important to dispose of a network able to provide enough capacity and a minimal quality performance. There are laws to regulate the minimal conditions of the offered quality of service but, normally, the reports to prove these minimal conditions are made by the operators themselves. Thus, might make these measures not much reliable especially when 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 provide an interactive evaluation system where the customer is able to perform the measures over the network. To achieve this goal, an application will be implemented in Python language under a Linux environment designed to work within a computer, after GSM signaling traffic has been captured. As a result the application will return some Key Performance Indicators of the studied network. Finally, extending the usage of this application throughout enough range and period time, it would be possible to provide quality parameters also published by operators and to evaluate their performance.
Both the study of the protocols and the application developed are intended to be used also in teaching.
vi
vii
Contents
1.3 Structure of the report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Background: GSM 4
2.1 General architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Mobile Station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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.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.2 MicroSIMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.3 xgoldmon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.4 Wireshark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4 Protocols analysis 28
4.2 Connection establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
viii
4.3.4 MTC and MT-SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.3.5 MT-SMS in a call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.3.6 Nonsynchronized intra-BSC handover or intra-MSC handover . . . . . . . 41 4.3.7 Synchronized intra-BTS handover . . . . . . . . . . . . . . . . . . . . . . 42 4.3.8 Signaling during a communication . . . . . . . . . . . . . . . . . . . . . . 43
4.4 Connection release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.5 Key Parameter Indicators (KPIs) . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.5.1 General delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.5.2 Particular times or delays . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.5.3 Measurement parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5 Algorithm and results 48 5.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.3 Test and results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.3.1 Study of the results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 5.3.2 Capture 1: Movistar Attach . . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.3.3 Capture 2: Orange MT-SMS . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.3.4 Capture 3: Vodafone MT-SMS in a MOC . . . . . . . . . . . . . . . . . . 67
6 Conclusions 71 6.1 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
A Source Code 74
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.9 MOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.11 MO-SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.13 MTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.15 MT-SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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.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) . . . . . . . . . . . . . . . . . . . . . 68 5.12 Receiving level and Mean BER of the serving cell (Vodafone MT-SMS in a MOC) 69 5.13 Receiving level of the neighbour cells (Vodafone MT-SMS in a MOC) . . . . . . 70
6.1 Mobile applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
List of Tables
5.1 Coverage related to signal strength . . . . . . . . . . . . . . . . . . . . . . . . . . 50 5.2 RXQUAL values and corresponding BER . . . . . . . . . . . . . . . . . . . . . . 50 5.3 ARFCN Table for common GSM systems . . . . . . . . . . . . . . . . . . . . . . 51 5.4 Establishment time comparative . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5.5 Connection establishment KPIs comparative . . . . . . . . . . . . . . . . . . . . . 54 5.6 Attach KPIs comparative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.7 Detach KPIs comparative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.8 MOC KPIs comparative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.9 MO-SMS KPIs comparative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.10 MTC KPIs comparative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.11 MT-SMS KPIs comparative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.12 MT-SMS in a call KPIs comparative . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.13 Serving cell KPIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
xii
Acronyms
ABM Asynchronous Balanced Mode AGCH Access Granted Channel AuC Authentication Center AUTN Authentication Token BCCH Broadcast Control Channel BCCH-FREQ-NCELL BCCH frequency of a neighbour cell BCD Binary Coded Decimal BSC Base Station Controller BSIC Base Station Identity Code BSS Base Station Subsystem BTS Base Transceiver Station CBCH Cell Broadcast Channel CCCH Common Control Channels CEPT Conference Europeenne des Administrations des Postes et des
Telecommunications CKSN Ciphering Key Sequence Number CM Connection Management CM-CC Call Control (CM Sublayer) CM-SMS Short Message Service (CM Sublayer) CP Control Protocol DTAP Direct Transfer Application Part EIR Equipment Identity Register EPS Evolved Packet System ETSI European Telecommunications Standard Institute FACCH Fast Associated Control Channel FCCH Frequency Control Channel FDMA Frequency Division Multiplex Access GMSC Gateway Mobile Services Switching Center GPRS General Packet Radio Service GSM Global System for Mobile Communications HDLC High level Data Link Control HLR Home Location Register HSN Hopping Sequence Numbers IMEI International Mobile Equipment Identity IMEISV International Mobile station Equipment Identity and Software
Version IMSI International Mobile Subscriber Identity KPI Key Parameter Indicator LA Location Area LAC Location Area Code LAI Location Area Identification LAPD Link Access Procedure for D Channel LAPDm Link Access Procedure for Dm Channel LTE Long Term Evolution M2M Machine to Machine
xiii
MAIO Mobile Allocation Index Offset MCC Mobile Country Code ME Mobile Equipment MM Mobility Management MNC Mobile Network Code MO Mobile Originated MOC Mobile Originated Call MO-SMS Mobile Originated Short Message Services MS Mobile Station MSC Mobile Switching Center MT Mobile Terminated MTC Mobile Terminated Call MT-SMS Mobile Terminated Short Message Services NCH Notification Channel NMS Network Management System N(R) Received Sequence Number N(S) Send Sequence Number NSS Network and Switching Subsystem OMC Operation Maintenance Center OSS Operation and Support Subsystem PCH Paging Channel PDU Protocol Data Units PLMN Public Land Mobile Network PSTN Public Switched Telephone Network QoS Quality of Service SABM Set Asynchronous Balanced Mode SACCH Slow Associated Control Channel SGSN Serving GPRS Support Node RAC Routing Area Code RACH Random Access Channel RAI Route Area Identification RAND Random number RFN Reduced Frame Number RP Reply Path RPDU Relay transfer Protocol Data Units RR Radio Resource management RRC Radio Resource Control RXLEV Received signal level of the serving cell RXLEV-CELL received signal level of a neighbour cell RXQUAL Received Signal Quality SACCH Slow Associated Control Channel SCH Synchronization Channel SDCCH Stand-alone Dedicated Control Channel SETSI Secretara de Estado de Telecomunicaciones y para la Sociedad de
la Informacion SIM Subscriber Identity Module SM-SC Short Message Service Center
xiv
SME Short Message Entity SMS Short Message Services SMS-GMSC SMS Gateway Mobile Switching Center SM-CP Short Message Control Protocol SM-RP Short Message Relay Protocol SM-TP Short Message Transport Protocol SRES Signed Response SVN Software Version Number TA Timing Advance TBF Temporary Block Flow TCH Traffic Channel TDMA Time Division Multiplex Access TLLI Temporal Logical Link Identifier TMSI Temporary Mobile Subscriber Identity TP Transfer Protocol UMTS Universal Mobile Telecommunications System USRP Universal Software Radio Peripheral XRES Expected User Response VLR Visited Location Register WCDMA Wideband Code Division Multiple Access
xv
xvi
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 assortment of 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 be very useful for low consumption applications such as Machine to Machine (M2M) which involves technologies that allow wired and wireless systems to communicate with other devices of the same type.
There is an standard for GSM but, as an standard, it only contains the recommended implementation of GSM and defines several optional parameters and procedures. Therefore, every operator performs GSM with multiple variations. With this situation, it seems useful to have a kind of a guide of the actual protocols implemented by the operators in case someone has to work 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 minimal quality performance must be provided. To prove that this service is provided, operators must publish 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) conditions of the communication services and the information related to the QoS offered by operators can be found at the Secretara 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 that the operators claim to provide. In this respect, the present project tries to provide an interactive measurement method where the customer can perform these measures.
1Publicacion niveles calidad de servicio from Ministerio de Industria, Energa 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 with the 3G - and now also 4G - technology coexistence implemented by several operators. As a result, an study of all procedures for each operator should be carried out. This will permit to analyse 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 evaluate the service perceived at their phones, in other words, to prove the QoS actually perceived by GSM customers.
The last objective is to evidence that using this tool it should be possible to perform several measures from different operators and obtain a comparison between the service offered by these operators. Performing enough captures covering the network range would also be possible to evaluate the performance of GSM networks depending on the operator. This tool could also help students to get an idea of the average service offered.
It should be remarked that comparing operators performance is not an objective but demonstrate that 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 presents a general view of the project with a brief explanation of the GSM mobile communications and its current situation. Also, this chapter explains the motivation, the objectives and the structure of 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 channels used 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 project and also a brief overview of the hardware and software used.
Based in the captures from GSM signaling traffic taken with the software presented on the previous chapter, Chapter 4: Protocol analysis exposes and studies the protocols used by the operators. The recommended implementations defined on the GSM standard are explained and then these are compared with the ones observed in the captures in order to know the variations introduced by the operators. Later on, this chapter defines a set of KPIs that could be used to evaluate the behaviour of the network.
The usage method of the program developed is explained in Chapter 5: Algorithm and results. It is also explained how the algorithm is implemented. In addition, this chapter includes some 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: Source Code.
3
Chapter 2
Background: GSM
Before the implementation of the GSM system, the mobile networks implemented in different countries were normally incompatible. That is why the Conference Europeenne des Admin- istrations des Postes et des Telecommunications (CEPT) created the Groupe Special Mobile committe in 1982 in order to develope a standard for digital mobile communications. The GSM group 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 other words, a completely digital system. It uses a cellular structure whose basic idea is to partition the available frequency range and to assign only parts of the complete frequency spectrum to any Base Transceiver Station (BTS). Consequently, it is possible to reduce the range of a base station in order to reuse the limited frequencies as often as possible. On the other hand, this reuse 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 order to deliver an incoming call.
• To assure the points above, the system requires a more extended signaling than fixed networks.
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 the present project focuses on the communication between the MS and the BTS, here is a brief explanation of the GSM network architecture:
4
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) number while, 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 permits access to a particular network. Physically, it is a chip which the user inserts in the ME and contains algorithms used for authentication and subscriber information. It communicates directly 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 the same amount of data as regular SIM cards, the only difference is their size each time closer to the chip size.
2.1.2 Base Station Subsystem
The BSS provides the air interface connectivity between the MS and the Network and Switching Subsystem (NSS) and is responsible for the transmission and reception. This subsystem is also associated with channel management, transmission functions and radio link control.
The BSS consists of both BTS and Base Station Controller (BSC). A BTS contains transmitter and receiver equipment as well as few components for signal and protocol processing. For instance, power control, ciphering and error protection coding. Several BTS are controlled by one BSC.
5
On the other hand, the essential control and protocol intelligence resides in the BSC. Its functions include protocol functions for radio channel allocation, channel set up and management of handovers.
2.1.3 Network and Switching Subsystem
The NSS controls several BSSs and its main function is to manage the communication between mobile users and other users performing call processing and subscriber related functions. It consists of several systems described bellow:
• The Mobile Switching Center (MSC) routes all calls and provides management functions such 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 text messages.
• The Gateway Mobile Services Switching Center (GMSC) interconnects the GSM network and the PSTN. It can access the HLR for routing assistance.
• The SMS Gateway Mobile Switching Center (SMS-GMSC) does the same function as the GMSC but for short message services. It stores temporarily incoming SMS and, if the receiver is not available, queues them for retry.
• The HLR database has a record for all subscribers registered with a network operator. It stores permanent data about subscribers, for instance, each user’s telephone number, service subscriptions, location, permissions and authentication data. This register is located within the MSC.
• The VLR stores only part of the subscriber data in the HLR and only while this subscriber roams in the VLR area. Its aim is not to overload the HLR and is also located within the MSC.
• The Authentication Center (AuC) is a register which stores and/or generates confidential data 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 to steal GSM mobile telephones. In order to discourage these thefts, the EIR database can bar 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 the Operation Maintenance Center (OMC) which allows to monitor GSM systems. This subsystem is connected to components of the BSS and the NSS and also controls the traffic load of the BSS.
6
2.2 GSM logical channels
Later on, we will discuss about physical and logical channels. Physical channels are defined in frequency and time domains, on the other hand, logical channels are mapped on physical channels and give a function to these physical channels. Logical channels can be divided into Traffic 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 two modes 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 different subscribers.
2.2.2 Signaling channels
In order to control and manage a cellular network, a lot of signaling is needed. Depending on its 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 a cell. This group includes three channels:
• Broadcast Control Channel (BCCH): this channel broadcasts the organization of the radio network. That is to say, radio channel configuration, synchronization information and registration identifiers.
7
• Frequency Correction Channel (FCCH): this channel broadcasts information about correction 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 as the 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 slotted Aloha to ask for a dedicated channel.
• Access Grant Channel (AGCH): this is a downlink channel used to assign an Stand alone Dedicated 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 in particular.
• Notification Channel (NCH): this is a downlink channel used to inform MS about incoming group and broadcast calls.
• Cell Broadcast Channel (CBCH): this channel broadcasts the messages of the SMS Cell Broadcast, 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 used for signaling between the MS and the BSS when there is no active TCH. This channel is requested on the RACH and assigned on the AGCH.
• Slow Associated Control Channel (SACCH): is always assigned and used with a TCH or an SDCCH. This channel carries information for the correct radio operation. When there is no signaling data to transmit, the MS sends a Measurement Report message.
• Fast Associated Control Channel (FACCH): this channel is also assigned in connection with 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 fundamental role in the quality of service offered.
GSM stack is a layered architecture as it can be seen in the Figure 2.3. Signaling at the Air interface is mainly controlled by Layer 3, Network Layer. Layers 1 and 2, Physical and Data Link Layer, provide the mechanisms for the protected transmission of signaling messages sent on Layer 3.
8
2.3.1 Layer 1: Physical Layer
Layer 1 is the physical connection between the MS and the BTS and includes all techniques and mechanisms to perform this connection. In addition, it can also include signal processing functions. This layer combines frequency and time multiplexing - Frequency Division Multiplex Access (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 divides each 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 signaling 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 interface similar to High level Data Link Control (HDLC). Moreover, its functions include organizing Layer 3 information into frames, sequence control to assure the frames order and detecting errors on 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 flow and error control information on the SDCCH and the FACCH. These frames are acknowledged by the receiver explicitly with a supervisory frame or implicitly with another information frame. To perform this flow control, these frames include the parameters Received Sequence 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 its N(R) value and then increments N(R).
• Supervisory Frames (S): are used for flow and error control when there is no data to be send. These frames serve to control the connection - initialize, disconnect and reset - as well as the retransmission of information frames during data transfer.
Receiver Ready (RR): Acknowledges that an I frame has been received sending the N(R) value.
9
Receiver Not Ready (RNR): informs that no more I frames can be accepted. The transmitter will have to wait for an RR frame.
Reject frame (REJ): indicates a transmission error and which is the first I frame to be resend.
• Unnumbered Frames (U): are unacknowledged frames used to exchange session management and control information between connected devices.
Set Asynchronous Balanced Mode frame (SABM): serves to initiate a Layer 2 connection.
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 RD frame. It acknowledges that a Layer 2 connection is initiated or taken out of service.
Unnumbered Information frame (UI): is used to broadcast common control messages and 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 as well as control functions for additional services. Messages in Layer 3 are divided into different sublayers, 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 exchange of messages in the Air Interface, it is necessary to include the following list that details all the information carried by the messages. There are more messages defined in the standard that the ones include in this list, that is because only the messages that have been captured are included. Several concepts will be referenced as it would be too dense and extensive to explain them 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 Air interface.
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. Two of the MSs are identified by their Temporary Mobile Subscriber Identity (TMSI) and the third by its TMSI or IMSI. It includes:
10
Page mode
Channels needed
Mobiles identity
• Paging Request Type 3: Downlink message sent on the PCH to four MSs to trigger channel access. All the mobiles are identified by their TMSI). It also includes:
Page mode
Channels needed
Mobiles identity
• Paging Response: Uplink message sent on the SDCCH in response for the paging request message establishing the main signaling link. It includes:
Ciphering Key Sequence Number (CKSN): a brief explanation of CKSN can be found in GSM Networks: Protocols, Terminology and Implementation (p. 332) [2].
Mobile Station Classmark 2: information element that provides the network with information concerning aspects of both high and low priority of the MS equipment. 1
Mobiles identity
It includes a layer 2 SABM U Frame. The network acknowledges this connection with a downlink 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 after the BTS has received a Channel Request.
Page mode
Channel description
Request reference: The purpose of this parameter is explained in the Channel request message.
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 applicable for 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 follow the 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 for connection request, for instance, answer to paging or emergency call. It also contains a random sequence - called request reference - used to distinguish a single user from the others 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 the technical 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 with information 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. When a MS with its IMSI attached for GPRS services enters the dedicated mode and the MS limitations make it unable to handle both dedicated mode and either packet idle mode or packet transfer mode simultaneously, the MS shall perform the GPRS suspension procedure.
Temporal Logical Link Identifier (TLLI): a logical link is uniquely addressed with a TLLI. 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 Land Mobile Network (PLMN).
- Location Area Code (LAC): four digits assigned by the operator that identify a Location 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 dedicated channel and up to 6 neighbour cells (uplink measurements). These reports serve as inputs for handover and power control algorithms. In an active connection, it is sent every 480 ms 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 and on a subset of slots.
RXQUAL: Received Signal Quality measured as bit error ratio (%) before error correction by averaging. This parameter is also measured on all slots and on a subset of slots.
NO-NCELL-M: Number of neighbour cells from which we have information.
RXLEV-CELL: Measurement of the received signal level from each neighbour cell during 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 going to be encrypted. It also informs about the algorithm used.
Cipher mode setting: indicates if the information must be ciphered and with which algorithm.
Cipher mode response: informs the MS which information shall be include in the Ciphering 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 channel used.
RR cause
GPRS resumption
13
Handover messages:
• Assignment Command: Downlink message sent on the SDCCH to assign a traffic channel in case of an intracell handover or during a call set up.
Channel description
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 frequency 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
Channel description
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 to the new traffic channel.
RR cause
• Handover Complete: Uplink message sent on the FACCH to indicate that the MS has performed a successful handover.
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 not follow 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 sent to 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 about the 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 about the 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 field of System Information 2 is not large enough to allow distinction of the larger number of channels of DCS 1800, PCS 1900, and also GSM 900 with extended band. Hence, System Information 2ter and 2quarter were defined to broadcast the frequencies of the neighbour cells.
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 as System 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)
Cell options (BCCH)
Cell selection parameters: provides the parameters needed for performing cell selection algorithm. This algorithm is described in GSM Architecture, Protocols and Services (p. 89) [4].
• System Information Type 4: Downlink message sent on the BCCH. It only repeats the data already sent in System information 1, 2 and 3.
Location Area Identification (LAI)
- Mobile Country Code (MCC)
- Mobile Network Code (MNC)
- Location Area Code (LAC)
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 neighbouring cells 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 active connection. This is the same case as System Information Type 2 and its information is the 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
Mobility Management messages (MM)
This sublayer use the channels that RR provides to exchange data about the mobility of a subscriber.
Registration messages:
• Location Updating Request: Uplink message sent on the SDCCH to request either update of its location file or IMSI attach.
Ciphering Key Sequence Number (CKSN)
Location Updating Type: Normal location updating, Periodic updating or IMSI attach. 16
Mobile station classmark 1
Mobile identity
It includes a layer 2 SABM U Frame. The network acknowledges this connection with a downlink 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 a downlink 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 connection and 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 during a connection establishment.
Authentication parameter RAND - Universal Mobile Telecommunications System (UMTS) challenge or GSM challenge: parameter used in the authentication procedure explained in GSM Architecture, Protocols and Services (pp. 173 - 175) [4].
Authentication parameter AUTN - UMTS and Evolved Packet System (EPS) authentication: An explanation on UMTS authentication procedure can be found in Security 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 authentication procedure explained in GSM Architecture, Protocols and Services (p. 173 - 175) [4].
Authentication response parameter XRES (extension, UMTS authentication challenge only): this parameter is part of the authentication procedure for UMTS explained in Security Mechanisms in UMTS [6].
• Identity Request: Downlink message sent on the SDCCH to request a MS to submit the specified identity to the network (IMSI, TMSI, IMEI or International Mobile station Equipment Identity and Software Version (IMEISV)).
18
• 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 tracking and interception of a subscriber more difficult.
• 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 connection in order to provide its identity (TMSI or IMSI) and to specify the service request in more detail.
CM Service Type: MOC, emergency call, short message service, supplementary service 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 the a 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 RR provides 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 Originated Call (MOC) establishment. This message contains the address information of the called party and the type of connection needed. In addition, activates the Call Waiting tone at the 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 to initiate a MTC establishment.
Bearer capability
• Call Proceeding: On an originated call, downlink message sent on the SDCCH to indicate that the address information in the Setup message has been received and no more establishment information will be accepted.
Facility - GSM mobile application: transports supplementary service related information. 20
• Call Confirmed: On an MTC, uplink message sent on the SDCCH after receiving a Setup message to confirm that the MS is able to establish the requested connection.
Bearer capability
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 connection was 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 the call. It includes a layer 2 I Frame.
• Connect Acknowledge: On an originated call, uplink message sent on the FACCH in order to acknowledge the Connect 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 called user alerting has been initiated.
Progress indicator
On a MTC, uplink message sent on the FACCH to inform that the MS has started ringing after 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 existing CC connection.
Cause
• Release: Downlink/uplink message sent on the FACCH to indicate that the Network/MS intends to release the transaction identifier.
Cause
• Release Complete: Uplink/downlink message sent on the FACCH to indicate that the Network/MS has released the transaction identifier and the MS/Network shall do the same after sending this message. It is sent by the side that has previously sent the disconnect message.
Cause 21GSM 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 SMS messages between subscribers. The information for this sublayer is sent on the SACCH if there is an active connection or on the SDCCH otherwise. It is necessary to take a look upon SMS service before explaining the packets exchange needed for this kind of communication. The following information can be found in Mobile messaging technologies and services. SMS, EMS and 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 which is implemented on the MS as software applications. Secondly, the transfer layer, related to Short Message Transport Protocol (SM-TP), consist on a sequence of octets with information about 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 transmission of the message at the physical level.
Before further explanations on the sending of SMSs, some SMS parameters should be introduced. First, the Status Report informs the sender if a SMS has been successfully received or not. Even though, in the captures this parameter is not requested. On the other hand, the Reply 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 sender is 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 of the short message or its deletion.
A SMS will be divided into several message segments if its data exceeds 140 bytes22. These message segments would be finally joined again into a concatenated message in the receiver application 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 Status Report is required, the validity period and so on. The list of the CM-SMS sublayer messages is shown below.
• SMS Submit: The MS sends the short message to the SM-SC. Each message segment is transferred as part of a TPDU containing the parameters below:
22Mobile messaging technologies and services. SMS, EMS and MMS (p. 51) [7]
22
Request or not for a Status Report
TP destination address
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 MS will conclude that the SMS Submission or the SMS Submission Report has been lost. In this case, the MS could try to submit the message again. If the lost packet was the SMS Submit 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, the SM-SC will store the message temporarily - up to the validity time -. The SM-SC will try to 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 a Status Report
TP originating address
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 received this 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 user data 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, none of 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 Mobile messaging 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 find information 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 concatenated later.
24
Design and development
3.1 General scenario
As we can see in Figure 2.1: GSM network on page 5, GSM communication could be divided into two parts: the user side, composed by the MS, and the network side, composed by the BSS, the NSS and the OSS. As it has been explained before, this project focusses on the 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 capture GSM traffic.
3.2 Tools and platforms used
To perform this project, several tools and platforms have been necessary. The following sections provide 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 was needed 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
3.2.2 MicroSIMs
As Samsung SIII only works with MicroSIMs, a MicroSIM for each operator is needed to be able 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 phones with Intel/Infineon XGold baseband processor. In these messages we can find for example signaling 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. In order to run xgoldmon, first the logging or diag mode has to be enabled in the Samsung Galaxy SIII. This is done with these two steps:
1. Entering *#9900# and setting Debug Level Enabled to HIGH. The phone reboots once this is done.
2. Entering *#7284# and setting USB to MODEM and tap SAVE and RESET. The phone reboots 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 be the logging port. As xgoldmon does not yet set any serial parameters on the device, on Linux the 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:
• -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 sometimes the devices ttyAMCx did not appear or they disappear unexpectedly when the program was 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
3.2.4 Wireshark
Wireshark is a network protocol analyser [11]. It lets us capture and interactively browse the traffic running on a computer network. It has a rich and powerful feature set and is world’s most popular tool of its kind. It runs on most computing platforms including Windows, OS X and Linux. It is freely available as open source, and is released under the GNU General Public License version 2.
It is developed and maintained by a global team of protocol experts and the version used in this project is 1.9.3 (SVN Rev 48788 from /trunk)
xgoldmon uses libosmocore to send the radio messages in GSMTAP format to UDP port 4729 on the local host. In order to monitor the packets with Wireshark the following command enables us 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 only GSMTAP 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 clearer and simpler codes than other languages. It is free to used because its OSI-approved open source license 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 provides an 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) for the 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 our disposal - namely, Movistar, Orange and Vodafone -. With these captures, we will be able to compare 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 standard defined has several optional parameters added in order to support these technologies and be able to change from one to the other. Every procedure can be divided into connection establishment, communication and connection release. In this chapter we will explain first the complete standard 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 the cell in which they camp. For this purpose, the cell broadcasts information about the organization of 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 message every 51-multiframe, that is to say, every 235 milliseconds. The sequence followed is normally the one bellow:
• System Information Type 1 or System Information Type 13
• System Information Type 2 or System Information Type 2ter plus System Information Type 2quarter
• System Information Type 3
• System Information Type 4
Cells use the time between these messages to broadcast Paging Request messages and Immediate Assignments.
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 an Immediate Assignment as a response. Once the MS gets a dedicated channel, it sends the service request and provides its identity with a CM Service Requests which is acknowledged by the Network. Before accepting the request with a CM Service Accept, the Network challenges the MS 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 used with Ciphering Mode Command and Complete messages. Then, the Network begins an identity procedure with the Identity Request and Response messages and, finally, a TMSI reallocation procedure is performed with the TMSI Reallocation Command and Complete messages. The complete 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 several differences, for instance, all the studied operators include the messages Classmark Change just after the service has been accepted by the Network with a CM Service Request message plus an UA Frame. Movistar and Orange include the message GPRS Suspension Request after the Ciphering Mode Command message while Vodafone include it after the first Identity Request message. Another common characteristic is that non of them use the messages CM Service Accept, TMSI Reallocation Command and TMSI Reallocation Response.
The authentication procedure is not always performed. Only when the CKSN stored in the MS 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 results of using the A3 algorithm or sending RAND and AUTN parameters and expecting an SRES and XRES.
Regarding to the messages Identity Request and Response, Movistar does not make use of them. 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 the IMEISV. In Chapter 2: Background: GSM, it was explained that IMEI is a unique number from 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 the IMEI - 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 for IMEISV with the message Identity Request. Vodafone is checking twice the identity asking for both parameters with the same message maybe to assure the reliability of the information. And finally, Movistar asks for this parameter in the Ciphering Mode Commad.
(a) Movistar (b) Orange
Figure 4.2: MO connection establishment
On the other hand, a MT connection establishment starts with a Paging Request send by the Network. The MS reacts to this message asking for a dedicated channel with a Channel Request and waiting for an Immediate assignment. Once the MS has a dedicated channel, it sends a Paging Response which is acknowledged by the Network. At this point, the Network begins an authentication procedure sending an Authentication Request and waiting for an Authentication Response. When the MS is authenticated, Network and MS agree on the cipher algorithm used with the messages Ciphering Mode Command and Complete. Then, just as in the MO case, the Network starts an identity procedure with the Identity Request and Response messages and, finally, a TMSI reallocation procedure is performed with the TMSI Reallocation Command and Complete messages. The complete procedure is presented in Figure 4.3.
Figure 4.4 shows the MT connection establishment implemented by operators. There are several differences, again, all the studied operators include the message Classmark Change just after the paging has been acknowledged by the Network with a Paging Response message plus an UA Frame. Also, the Movistar and Orange include the message GPRS Suspension Request after the Ciphering Mode Command message while Vodafone include it after the first Identity Request message.
30
Figure 4.3: GSM Standard MT connection establishment
There are some messages that are not always used, such as the Authentication Request and Response 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 IMSI instead of its TMSI in the paging procedure. Lastly, the identity procedure is performed in the same way as in the MO connection establishment.
(a) Movistar (b) Orange
Figure 4.4: MT connection establishment
It is remarkable that we are not able to capture Channel Request messages in any of the procedures and operators. This might be because the message does not follow the basic format and the 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 establishment and the communication are not clearly apart. As it can be seen in Figure 4.5, first a MS ask for 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 IMSI attach with the message Location Updating Request which is acknowledged by the Network. Before accepting the location updating, the procedures for authentication, ciphering, identity and TMSI reallocation are performed. Finally, in order to release the connection, the Network sends a Channel Release message on Layer 3. The MS answers this last Layer 3 message with a Layer 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 connection establishment, the operators include a Classmark Change message to inform the network about the capabilities of the MS. Also, the messages Authentication Request and Response are used when 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 TMSI Reallocation Request and Response. A significant change in front of the other operators is that when the MS changes from WCDMA to GSM, Movistar performs the attach procedure including a GPRS Suspension Request message whereas the other operators do not perform the attach procedure 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 Request and Response and Ciphering Mode Command and Complete.
32
4.3.2 Detach
In the detach procedure the connection establishment and the communication are neither clearly apart. GSM Standard suggest as an option the realization of this procedure when the MS is powered off or the SIM is removed in order to relieve the paging load on the BSS caused by unnecessary paging requests. As it is just an option, there is not an standard procedure for the detach procedure. Even though, all the studied operators perform exactly the same protocol shown in Figure 4.7.
Figure 4.7: Detach
Any MS that intends to perform a detach procedure asks first for a dedicated channel with a Channel Request message and this is assigned by the Network with an Immediate Assignment message. Then, the MS informs of its intention with an IMSI Detach Indication message that will be acknowledged by the Network. Afterwards, the MS sends a Classmark Change message and 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 we can send and receive SMS with all the operators at our disposal. Although the protocol for the connection establishment has been described before, it is included to show the complete procedures. 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 channel assignment 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 the Authentication Request and Response message before accepting the service with a CM Service Accept message. Once the service is accepted the procedures for ciphering, identification and TMSI reallocation and performed one by one. At this point, the MS sends a Set Up message informing about the called MS address. This information will be acknowledged by the Network with a Call Proceeding message and, then, the Network will make the MS change its dedicated channel 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 Alerting message and a Connect message when the called user accepts the call. This last message is acknowledged by the calling MS with a Connect Acknowledge.
Finally, the side that wants to release the connection sends a Disconnect message. Next, the other part sends a Release message which is acknowledged by a Release Complete. Then, the Network initiates the connection release procedure sending a Channel Release message and the MS 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 establishment. Both operators include the messages Classmark Change and GPRS Suspension Request and 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 different from the one stored in the Network. Particularly, Movistar omits the identity procedure and Vodafone 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 procedure, 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 requested with the CM Service Request which is acknowledged by the Network. Before accepting the service with a CM Service Accept message, an authentication procedure will be performed. After accepting the service, the procedures for ciphering, identification and TMSI Reallocation are done one after the other. At this point, the MS will send a SMS Submit message. The Network will acknowledge it with a CP Acknowledgement message and then will send to the MS a SMS Submit 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 message and 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. All the operators include the messages Classmark Change and GPRS Suspension Request and omit the messages CM Service Accept and TMSI Reallocation Command and Complete and the authentication procedure is only used when the CKSN stored in the MS is different from the one stored in the Network. Particularly, Movistar also omits the identity procedure and Vodafone uses 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 message - 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 connection release, asks again for a CM Service to send the rest of the SMS with a CM Service Request plus an Layer 2 I Frame. This is the only case where the networks answers with a CM Service Accept plus a Layer 2 I Frame so the connection is not release until the MS has sent the complete
36
message.
4.3.4 MTC and MT-SMS
As in the previous case, we only can perform calls with Movistar and Vodafone while we can send and receive SMS with all the operators. Once again, in both cases the changes applied are mainly in the connection establishment.
Figure 4.12 shows the recommended protocol for a MTC. First, the Network sends to the MS a Paging Request. The MS reacts asking for a dedicated channel with the Channel Request and the Network assigns it with an Immediate Assignment message. Once the channel is assigned, the MS sends a Paging Response message which is acknowledged by the Network. Next, the procedures for authentication, ciphering, identification and TMSI reallocation are performed one after another. At this point, the Network sends a Set Up message to initiate the MTC and the MS answers with a Call Confirmed to inform that is able to establish the connection. Then the Network will make the MS change its dedicated channel from the SDCCH to the FACCH using the messages Assignment Command and Complete. Once the channel has been changed and the alerting has started on the MS, it sends an Alerting message to the Network. When the MS takes the call, it will send a Connect message that the Network will acknowledge with a 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 by a Release Complete. Then, the Network initiates the connection release procedure sending a Channel Release message and the MS sends a Layer 2 RD U frame which will be acknowledged by a Layer 2 UA frame.
Figure 4.13 shows the variations observed in the captures. To begin with, both operators include the messages Classmark Change and GPRS Suspension Request. Again, the authentication procedure is only performed when the CKSN stored in the MS is different from the one stored in the Network and the TMSI Reallocation when the MS is identified by its IMSI instead of its TMSI in the paging procedure. The last difference is that Movistar omits the identification procedure while Vodafone performs it twice.
Regarding to MT-SMS, Figure 4.14 shows the complete procedure. As a MT communication, the MS receives a Paging Request message and reacts asking for a dedicated channel with a Channel Request message and waiting for an Immediate Assignment. After the assignment of the channel, the MS sends a Paging Response which is acknowledged by the Network. Then, the procedures 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 acknowledge it with a CP Acknowledgement message and a SMS Deliver Report. This Report will also be acknowledged by the Network with a CP Acknowledgement message. Once the SMS has been received, the MS will start the connection release procedure sending a Channel Release and waiting 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 again that all the operators include the message Classmark Change after the paging response has been acknowledged by the Network and the message GPRS Suspension Request after Ciphering Mode Command for Movistar and Orange or after the first Identity Request for Vodafone. Also, the authentication procedure is only used when the CKSN stored in the MS is different from the one stored in the Network and the TMSI Reallocation when the MS is identified by its IMSI instead of its TMSI in the paging procedure. The last difference in the connection establishment is that the identity procedure is not used by Movistar and used twice by Vodafone. Regarding to the CM-SMS messages, the acknowledgement of the SMS Deliver Report is not sent by any of the operators.
39
Figure 4.14: GSM Standard MT-SMS
There are some especial cases that seem interesting to focus on. For example, which is the behaviour when a MS is switched on and it already has SMS to be delivered. The procedure is as follows: once the attach procedure is done, as many MT-SMS procedures as SMS the MS has to receive are performed. Regarding to the case of receiving a large SMS, it is received as several independent SMS. That is to say, contrary to the large MO-SMS case, it is received as several 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 but sent over the SACCH instead of over the SDCCH. However, when checking this procedure with the operators Movistar and Vodafone - since we are not able to perform calls with Orange -, we have 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 not captured.
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
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 sending a Handover Command message. Then, the MS sends an undefined number of Handover Access 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 sending Handover Access messages and sends a Layer 2 SABM U Frame which will be acknowledged by a Layer 2 UA Frame. Finally, the MS confirms the successful handover sending a Handover Complete 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 messages Handover Access. Probably due to the same reason for we cannot capture any Channel Request message.
4.3.7 Synchronized intra-BTS handover
Regarding to synchronized intra-BTS handover, the recommended protocol is shown in Figure 4.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 the connection sending a Layer 2 SABM U Frame and waiting for a Layer 2 UA Frame. Once the connection has been established, the MS informs that the handover has been successful with an Assignment 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 two options 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 System Information 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 MS with all the operators receives first the System Information Type 5, 5ter or 6 and then sends a Measurement Report message. Moreover, the MS receives four Layer 2 UI Frames before receiving another System Information message. There is no apparent explanation for receiving these final Layer 2 UI Frames and we cannot decode the information carried in them to deduce it. 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 acknowledged by the first part with a Layer 2 UA Frame. There are no differences observed in the final implementation by the operators.
Figure 4.22: Connection release
4.5 Key Parameter Indicators (KPIs)
Once the procedures

Development of a tool for GSM networks performance ...

Documents

Transcript of Development of a tool for GSM networks performance ...