Wirless-Mobile-Communication-System-Development

2 | W i r e l e s s M o b i l e C o m m u n i c a t i o n S y s t e m D e v e l o p m e n t

Copyrights

© 2015 Author. All rights reserved.

Cover Page (Bottom Part) Source and credit: 3GPP site

The author acknowledges all the respective trademarks being referred/used, if any, in this book.


Disclaimer:

All the opinions, except the granted copyrighted materials being used, expressed in this book are myown, from personal experience and does not represent either from the past or present employer.


Acknowledgements

I thank my dear friends and colleagues for giving their time and valuable comments.

I would also like to thank the 3GPP for giving me the permission to reproduce few snapshotsfrom the 3GPP technical specifications.

-Author


Table of ContentsACKNOWLEDGEMENTS ......................................................................................................................................................... 4

INTRODUCTION ...................................................................................................................................................................... 8

WHAT BOOK THIS IS ABOUT 8HOW TO USE THIS BOOK 9WHO SHOULD USE THIS BOOK? 9WHY I WROTE THIS BOOK 9WHAT IS MISSING IN THIS BOOK AND ASSUMPTION 9ORGANIZATION OF THIS BOOK 10

ABOUT WIRELESS MOBILE COMMUNICATION ............................................................................................................... 11

1.1 MOBILE COMMUNICATION STANDARD SPECIFICATION 121.1.1 A brief on Network Element/Entity, Network Architecture ....................................................................................... 12

1.1.1.1 Mobile Communication Network Architecture .............................................................................................................................131.1.1.2 Mobile Communication Network System Engineering..................................................................................................................17

1.1.2 What is 3GPP (3rd Generation Partnership Program)............................................................................................... 171.1.2.1 3GPP Working Groups ...............................................................................................................................................................17

1.1.3 3GPP Technical Specification and Technical Report .................................................................................................. 181.1.4 Stages of a 3GPP Technical Specification ................................................................................................................... 201.1.5 3GPP Technical Specification Numbering nomenclature.......................................................................................... 21

1.1.5.1 Series Number ............................................................................................................................................................................211.1.5.2 Version Number of a 3GPP Technical Specification ...............................................................................................................23

1.1.6 Vocabulary of 3GPP specifications .............................................................................................................................. 241.1.7 Examples in a 3GPP Technical Specification .............................................................................................................. 241.1.8 Change Control Process in 3GPP................................................................................................................................. 241.1.9 Standardization of Technical Specifications by 3GPP................................................................................................ 241.1.10 3GPP Technical Specifications series for Access Network........................................................................................ 24

1.2 AREAS OF MOBILE COMMUNICATION NETWORK SOFTWARE R&D 251.2.1 Example Network Element: BSC................................................................................................................................... 251.2.2 Protocol Interface/Stack................................................................................................................................................ 261.2.3 Modules /protocol layers of a network element ......................................................................................................... 261.2.4 Protocol Conversion ...................................................................................................................................................... 271.2.5 Protocol Grouping/Categorization ............................................................................................................................ 27

1.2.5.1 User Plan or data plane and Control or Signal Plan ...............................................................................................................271.2.5.2 Access Stratum/Non Access Stratum .......................................................................................................................................28

1.3 HOW TO IDENTIFY AND UNDERSTAND A 3GPP TECHNICAL SPECIFICATION 291.3.1 3GPP Releases and its Features ................................................................................................................................... 311.3.2 Scope of 3GPP Technical Specification........................................................................................................................ 321.3.3 3GPP TS and its Related/Reference Specifications ..................................................................................................... 331.3.4 3GPP Releases and it Specifications mappings .......................................................................................................... 331.3.5 Download 3GPP technical specifications .................................................................................................................... 33

1.4 DIFFERENCES AMONG THE MOBILE COMMUNICATION TECHNOLOGIES 33

EXPLORE MOBILE COMMUNICATION SYSTEMS ............................................................................................................. 37


2.1 MOBILE COMMUNICATION NETWORK INTERFACES 372.1.1 Circuit Switch Domain interfaces................................................................................................................................. 372.1.2 GSM/GPRS/GERAN Domain interfaces ....................................................................................................................... 372.1.3 Packet Switch Core Domain interfaces ....................................................................................................................... 372.1.4 UTRAN and E-UTRAN Domain interfaces .................................................................................................................. 37

2.2 HOW TO ENCODE AND DECODE A MOBILE TELECOM MESSAGE 372.2.1 CSN/ASN Encoding/Decoding method used in GPRS/UMTS/LTE ............................................................................ 382.2.2 Encoding/decoding method used in GSM/GPRS/EDGE ............................................................................................. 402.2.3 Direct/Indirect Encoding Method ................................................................................................................................. 422.2.4 Segmented Messages over the Air interface ............................................................................................................... 42

2.3 ALARM IN A MOBILE TELECOM NETWORK 432.3.1 What is an alarm? ......................................................................................................................................................... 432.3.2 Alarms definition in 3GPP TS ....................................................................................................................................... 43

2.4 PERFORMANCE MEASUREMENT AND OPTIMIZATION OF A MOBILE COMMUNICATION NETWORK 442.4.1 What is a counter .......................................................................................................................................................... 442.4.2 What is a KPI?................................................................................................................................................................ 45

OPERATIONS AND MAINTENANCE ................................................................................................................................... 48

3.1 FIELD TROUBLESHOOTING OF MOBILE COMMUNICATION NETWORK ISSUES 483.1.1 Drive Test, Data Collection and its Analysis ............................................................................................................... 493.1.2 Log/Traces collections .................................................................................................................................................. 503.1.3 Conforming Testing Issues............................................................................................................................................ 51

3.1.3.1 IOT (interoperability testing) Issues ..............................................................................................................................................513.1.3.2 Protocol Stack testing and validation............................................................................................................................................51

MOBILE COMMUNICATION SYSTEM DEVELOPMENT .................................................................................................... 53

4.1 DEVELOPMENT PLATFORM FOR A MOBILE COMMUNICATION NETWORK 534.1.1 Selecting Hardware Platforms: Legacy Unix/Linux versus PC ................................................................................... 53

4.1.1.1 Development using Embedded System - Board Support Package (BSP) .............................................................................534.1.1.2 Development using Multicore Hardware Platform based Embedded System ..............................................................................544.1.1.3 What is a core?............................................................................................................................................................................564.1.1.4 Why use Multicore Processor? ..................................................................................................................................................564.1.1.5 Types of Multicore Systems/Platforms ....................................................................................................................................574.1.1.6 Multicore software computing..................................................................................................................................................574.1.1.7 Some challenges in multicore computing ...............................................................................................................................584.1.1.8 Developing Telecom System/network entity using multicore platform ..............................................................................584.1.1.9 Examples of multicore processor..............................................................................................................................................594.1.1.10 Runtime choices of multicore processor ...............................................................................................................................604.1.1.11 Software programing model for Multicore processor .........................................................................................................604.1.1.12 Closed/ proprietary vs Open Platform: Carrier Grade Linux (CGL) .....................................................................................61

4.1.2 Selecting Software Platforms and features ................................................................................................................. 624.1.2.1 Available Data/logical Structures to choose ...........................................................................................................................624.1.2.2 Selecting an Operating System Services/Facilities .................................................................................................................644.1.2.3 Portability of systems .................................................................................................................................................................654.1.2.4 Software Simulators/Emulators for a mobile communication network ...............................................................................65

4.1.3 Mobile communication network software debugging ............................................................................................... 664.1.3.1 Incorrect Usages of Software Library system calls/APIs.........................................................................................................674.1.3.2 Incorrect Usages of System Resources ....................................................................................................................................674.1.3.3 Bad Software Programming Practices .....................................................................................................................................674.1.3.4 How to avoid software pitfalls ..................................................................................................................................................69


4.1.3.5 Static Code Analysis of Software ..............................................................................................................................................70

4.1.4 Software Architecture and Software Organization .................................................................................................... 704.1.5 System/Software Requirements Analysis .................................................................................................................... 714.1.6 Software Quality: Reliability, Scalability, Availability ................................................................................................ 71

4.1.6.1 Reliability .....................................................................................................................................................................................714.1.6.2 Scalability .....................................................................................................................................................................................724.1.6.3 Availability ...................................................................................................................................................................................72

4.1.7 Protocol and Protocol Stack development .................................................................................................................. 724.1.7.1 Protocol Layer development using Service Primitives ...........................................................................................................724.1.7.2 Protocol Layer development using State Machine .................................................................................................................744.1.7.3 Protocol Layer development using message passing ............................................................................................................74

4.1.8 Software Profiling, tools and performance Improvement.......................................................................................... 744.2 SUMMARY 75

TEST YOURSELF ..................................................................................................................................................................... 76

5.1 TEST YOUR KNOWLEDGE 76

THE LAST NOTE: WHERE DO YOU WANT TO GO NEXT… .............................................................................................. 79

APPENDIX .............................................................................................................................................................................. 80

7.1 USEFUL LINKS 80

ABOUT THE AUTHOR .......................................................................................................................................................... 81


Introduction

If you are wondering, and sometimes, scouring the web on how a wireless mobilecommunication network is designed, developed, tested, deployed, then you are atthe right place! This is an introductory book encompassing the various practicalaspects of wireless mobile communication network software systems, itsprotocols/stack, development, deployment, operations and maintenance, and theplatforms to choose from the available ones.

The materials on this book are being targeted as the starting point for a rookieComputer Science graduate engineer who just passed out of the college campus or alesser experienced person looking for an opportunity to work in the mobiletelecommunications space.

What book this is about

This book is about the mobile communication network system software design,development, testing, optimization, operation and its field maintenance. It contains abrief, straightforward, practical introduction on the various aspects of mobilecommunication network software development, deployment and its operation andmaintenance. It starts with the identification of a particular network element, theconcerned standard specifications, its various aspects, as well as the developmentplatforms, such as legacy UNIX, PC, Carrier Grade Linux (CGL), to be chosen andfollowed by its deployment. Also you will find is the troubleshooting of an issuearising out of post deployment and operational of a network element. This book alsointroduces the latest computing platform available around us, “multicore processor”,which is the current buzzword in different areas of technologies, be it the desktop,mobile handset and so on. A brief about the mobile telecommunications systemdevelopment using an embedded system platform is also covered.

The world of wireless mobile communication network system is a complex but aninteresting one. The nitty-gritty of mobile communication network systemdevelopment and its related areas, described in this book, could be learned andgained over a period of time only. For you, the author has made them available inthis book in a concise way. The aim is to shorten the learning curve, so that one canbecome productive independently from day one. Attempt has been made to drawanalogies from various angles that you might be already familiar/expert so that thecontents being provided here are becomes easy for you to understand and finds aplace in your memory.

This book comes to you that reflects the author’s 12 years of experience with a fulllife cycle of software R&D, deployment, testing, operation and maintenance in thearea of mobile communication, Radio Access Network (RAN) and Core Network (CN),domain deployed across the available platforms, including satellite based mobilecommunication system.


How to use this book

Various practical aspects of wireless mobile communication system developmentbeing presented here are in brief in nature. For a proper understanding of theunderlying protocol along with the materials being presented here, the concerned3GPP technical specification(s)/reference/web site must be referred while goingthrough a section of this book. The author has also made available the relevanthyperlink in the concerned section so that the reader can visit the same for thecomplete and supplementary information without reproducing it in this book.Especially the familiarity of the 3GPP website is very important as you will be requiredto visit the same quite often. The reader is advised to go through this book in asystematic manner and section wise only, including the visiting of the providedhyperlinks/specification pages, so that the concerned section is grasped completelybefore moving to the next one.

Who should use this book?

Wireless Mobile Communication System Development: An Introduction to PracticalApproach for Systems Understanding, Implementation and Deployment, is primarily forstudents who had just graduated either in Computer Science or Electronics &Communication discipline and is looking for exciting and rewarding career in thewireless mobile communication domain. It’s also appropriate for students currentlystudying in the above-mentioned discipline and is looking for project workassignments, as a part of the academic curriculum, in the wireless mobilecommunication domain. An experienced person from other software domain can alsogo through this book for a career change into the wireless mobile communicationdomain.

Why I Wrote this book

Like any other complex system, a mobile communication network is built based oncertain standard specifications related to a particular wireless mobile communicationtechnology. A mobile communication network also consists of different competencyand expertise areas on different network elements. A student learns about thetheories and programming concepts during his/her graduation days but does not getan exposure to the real world working of the mobile technology domains. Also, themobile communication standard specifications are large in numbers, and can be abewildering to a new learner. Keeping this fact in top of mind and to fill up the gap,I wrote the current book so that students can learns the practical, real world mobiletelecommunications subjects areas and equip himself during the college days itself ,before he starts his career in the relevant domains.

What is missing in this book and Assumption

This book does not contain an in-depth and breadth, a comprehensive tutorial andinformation on various individual components of mobile wireless mobile


communication technologies such as GSM, EDGE, 3G, protocols stack and its sublayers, illustrating graphics and so on. But it attempts to provide the reader aguidance and various other aspects on how to find the interested concepts/areashe/she is looking for further studies. The author attempts to provide an overallsystem development perspective covering the various aspects of implementation anddeployment issues both at macro as well as micro level.

Because of the copyrighted in nature, the author could not provide, in this book,materials from his practical experience, in order to make the contents easier tounderstand. There are plenty of good books available in the market on variousaspects of wireless mobile communication technologies, its protocols and so on. Onemay refer a reference book of his/her choice along with the available, online and freeof cost, standard specifications as described in this book.

The author assumes that the intended audiences, by now, have at least asmartphone, using the various mobile telecommunication services, e,g voice ,data,and have heard of the mobile communication technologies such as the GSM,GPRS/EDGE, 3G and so on, available around us.

Organization Of This book

This book is organized as follows:

Chapter 1 introduces about the 3GPP standard technical specification based on whicha mobile communication network is designed developed, built and operates. Itdescribes about, along with other aspects, how to identify and work on theconcerned standard technical specification that applies to a particular network entity.

Chapter 2 introduces about the various practical aspects and related areas towardsthe development of a mobile communication network based on 3GPP technicalspecifications.

Chapter 3 Introduces about the operation and maintenance of a mobilecommunication network from the field operational point to view.

Chapter 4 introduces about the software, hardware development platforms andrelated areas for a mobile communication network system/entities. It discusses aboutthe available legacy, embedded and multicore hardware platforms.

Chapter 5 lists miscellaneous questions so that you can test your understanding onmobile communication network system.

Rajib TaidDibrugarh, Assam, India.1/1/2015


About Wireless Mobile Communication

Today mobile phones are no more considered a luxury but among the daily necessities.Mobile communication has evolved quickly and revolutionized the way we communicate andhave brought people around the globe more closely than ever before. At the same time themobile telecom industry has witnessed an explosive growth rate over the past many years,offering wide range of services and products.

The latest trend is the penetration of the Smartphones and their growing demand for datahungry applications/services/capabilities is leading to the growing in mobile and internettraffic. In India alone, the number of mobile communication services users is more than halfof the country’s population. The emergence of wireless mobile telecommunications networkstandards such as GSM, GPRS, EDGE, UMTS (3G) and Long Term Evolution (LTE) and thegrowth in the number of mobile subscribers have created a gap between the demand andsupply of skilled telecom professionals who are quick to react to the constant changes.

Mobile communication industry offers an immense employment opportunity.Communication services providers, Network installer, OEMs and telecom Softwaredevelopment firms are demanding skilled and experienced professionals. In mobilecommunication space alone, career opportunities exist across these different verticals andareas such as the following:

(1) Consulting as well as software design, development, including validation andintegration, design analysis services in the Wireless mobile Radio Access Networks(RAN), Core Network (CN), and Mobile Handset (MS) area outsourced by OEMs.

(2) Consulting as well as radio network planning and optimization servicesoutsourced by telecom service providers.

(3) Consulting as well as software development in the area of Customer ExperienceManagement for telecom service providers.

(4) Maintenance and sustenance of Mobile telecom network.

(5) Consulting as well as core network planning and optimization services outsourcedby telecom service providers.

Within the mobile communication space, there are other areas, such as billing, valueadded services etc., too where career opportunities exist.

“You see, wire telegraph is a kind of a very, very long cat. You pull his tail inNew York and his head is meowing in Los Angeles. Do you understand this?And radio operates exactly the same way: you send signals here, they receivethem there. The only difference is that there is no cat.” Albert Einstein.

1


Wireless mobile telecommunications systems and networks are based on the open TechnicalStandards, covering a wide spectrum of knowledge. Developing a communication systembased on the same is not a cakewalk. Within the available universe of technical standardsspecifications, one may become mystified and inundated at first glance.

1.1 Mobile Communication Standard Specification

1.1.1 A brief on Network Element/Entity, Network Architecture

A mobile communication system such as the GSM, EDGE, 3G comprises of complexnetwork of different network elements/entities, such as MS (Mobile Station), BSC(Base Station Controller), BTS (Base Transceiver Station), MSC (Mobile SwitchingCenter), SGSN (Serving GPRS Support Node), and GGSN (Gateway GPRS SupportNode), and so on, that provides services like mobile communication, both voice(Circuit Switched –CS) and data services to (Packet Switched –PS) subscribers.

Note: For the list of glossaries of all the terms, their definitions, and the abbreviationsfound in mobile communication technologies, please refer the 3GPP TR 21.905. Moreabout the 3GPP technical specifications and technical reports are described at a latersection. Abbreviated form of terminologies, such as the MS, BSC, SGSN, CN, EPC andso on, of the various terms of mobile communication technologies are being used inthis book without being referring to them in expanded form. Underlying concepts beingprovided shall become more clearer as one proceeds through the rest of the sections ofthis book.

For example, consider below, see Fig: 1.1, for the different network elements, such asMobile Station (MS), BSS (Base Station Subsystem), and Core Network (CN) found ina typical 2nd generation GSM network.

Fig: 1.1 Network Architecture and Elements of a GSM Network

As seen in the figure above, the BSS (base station subsystem) consists of the networkelement/entities BTS and the BSC whereas the network switching subsystem (NSS)consists of the MSC, HLR and so on. NSS is also known as the Core Network (CN).


Similarly, consider the Fig: 1.2 below for the different network elements, such asMobile Station (MS), BSS, SGSN, found in a GPRS network deployed for data servicesto subscribers.

Fig: 1.2 Network & Protocol Architecture and Elements of a GPRS Communication Network

BSS is responsible for radio communication path control and every call is connected throughthe BSS. Similarly, the NSS/CN primarily takes care of all the call control related functions.Note that calls are always connected by and through the NSS/CN.

1.1.1.1 Mobile Communication Network Architecture

Collection of various network elements and the logical interfaces among themconstitutes a Network Architecture for a particular wireless mobile technology suchas GSM, GPRS, 3G, and LTE. The Network elements and their architecture could bealso divided into logically, comprising of the following:

Access Network (AN) Core Network (CN) Mobile Station or User Equipment (MS/UE)

An Access network (AN) consists of equipment and systems that is responsible forradio transmission and reception in one or more cells to or from the user equipmentor mobile device.

A Core network is the backbone infrastructure for a mobile communication systemconsisting of hardware and systems and also a gateway to the traditional PSTNsystem. A Core network is independent of the radio connection technology, e.g.wireless, wired, for a mobile device.

Above logical divisions of the available mobile communication systems such as theGSM, GPRS, 3G, LTE, with their corresponding network elements, are shown in thefigure below.


Fig: 1.3 Logical Divisions of Wireless Technologies

The Core Network could be further divided logically into the following domains:

Circuit Switched (CS), that provided Voice Call services Packet Switched (PS, that provides Data services IM (IP Multimedia) subsystem.

Note that there are certain specific network elements that are applicable for the CN only.

For details regarding the available mobile network Architectures, its network elements andthe various logical interfaces among them, refer the 3GPP technical specification (TS)#23.002. More about the 3GPP technical specification (TS) and logical interfaces aredescribed at a later section of this book.

The basic configuration of the various network elements of a 3GPP Access PLMN supportingboth the CS and PS services using GSM/GPRS/EDGE, UMTS (3G), EPS (LTE) system are shownin the Fig: 1.4 (a) below. Also shown in this figure are the various logical interfaces amongnetwork elements depicted in the Fig: 1.3 above. Fig: 1.4 (a) also shows how the services ofa network element are being used across the wireless mobile communication technologies.For example, the services of the network element SGSN is used in case of GPRS, UMTS andLTE data services/communications. The same network entity exchanges protocol informationwith the other network entities using a separate logical interface each.


Source: 3GPP TS 23.002. Reproduced with permission from 3GPP.

Fig: 1.4 (a) Basic Configuration of a 3GPP Access PLMN supporting CS and PS services (usingGPRS and EPS) and interfaces

In the figure above, the texts, such as Abis, Um, Uu, S1, S12…., written on the/along theline connecting two network elements represent the corresponding protocol and logicalinterface between them. Refer the 3GPP TS 23.002 for further details. More details aboutthe 3GPP Technical Specifications (TS) are available in the next sections of this book.


Example: Mobile Originated (MO) GSM call to a PSTN phone

Whenever you press the call button in your mobile phone, and then, in order to servethe same, hundreds of information are exchanged among the various networkelements starting from the Mobile station to the core network till the subscriberservice is in use. This is shown in the Fig: 1.4 (b) below. Text inside the bracket showsthe corresponding 3GPP technical specification (described in the next andsubsequent sections) number, where the definition and more details about theconcerned messages could be found.

Fig: 1.4 (b) Mobile Originated (MO) GSM call to a PSTN phone


1.1.1.2 Mobile Communication Network System EngineeringThe system engineering of each of the mobile communication technology can be dividedinto the following areas for providing of various types of services to the users.

Mobility management Air interface management Subscriber and Service management Security management Network maintenance

Above system engineering has been further divided into the different subject areas, astabled in the Table: 1, described at a later section #1.1.5.1.

1.1.2 What is 3GPP (3rd Generation Partnership Program)

A mobile communication network is based on a particular wireless mobile technologyarea such as GSM, GPRS, UMTS, and LTE and so on. A mobile communicationnetwork consists of different network elements to provide end-to-end services to asubscriber. Each network element communicates with each other using a standardprotocol like the different PC and server uses TCP/IP and other protocol tocommunicate with each other over the Internet. Like other international bodies thatdefines various standard protocol such as TCP/IP, FTP, and ICMP and so on, thestandard protocols used in a mobile communication network are defined by anorganization called 3rd Generation Partnership Project, shortly called as 3GPP. It's acollaborative effort among different organizational partners. Those are: ARIB, ATIS,wireless mobile communication System Development CCSA, ETSI, TTA, and TTC,which are regional and national standards bodies, from Asia, Europe & NorthAmerica.

In a nutshell, start visiting the 3GPP site, http://www.3gpp.org/, right away! to learnmore about it and crawl through the various information available under the differentsections and pages. You may find more information on this site that is not availablein this book.

A mobile telecommunication system conforming to 3GPP specifications, consisting ofthe system engineering as mentioned in Section 1.1.1.2 above, a core network andone or more access networks (Section 1.1.1.1) that may be either GERAN, UTRAN, E-UTRAN or a User Equipment/mobile device, is said to be a 3GPP system.

1.1.2.1 3GPP Working Groups

Within the 3GPP, there are four technical specification-working groups (TSG). Thoseare:

Radio Access Networks (RAN),


Service & Systems Aspects (SA), Core Network & Terminals (CT) GSM EDGE Radio Access Networks (GERAN).

Visit this link http://www.3gpp.org/specifications-groups for further details about thedifferent working groups and its responsibilities. There is a table named “Project Co-ordination Group (PCG)” containing hyperlinks for various working group whichcould be explored further by clicking the same. 3GPP specifies such as:

Maintenance and evolution of radio access technologies starting from GSM(2G) to LTE Advanced (4G).

Maintenance and evolution of core network and system architecture startingfrom GSM (2G) to LTE Advanced (4G).

Service Layers such as GSM Services, IMS and so on.

Note that materials on the 3GPP site are open and freely available. You can alsocontact for any information at [email protected].

1.1.3 3GPP Technical Specification and Technical Report

In our day-to-day life, one uses USB based different electronic gadgets just in a plugand play way. Similarly one can remove a SIM card from a phone, insert it intoanother phone with different make and model and start using the same. All these arepossible only when those devices are designed and works based on certainstandards/protocols. The network elements of a mobile communication network tooare designed and work on certain protocols as defined by the 3GPP.

A particular protocol, and its various aspects, as defined by the 3GPP, is identifiedunder a standard terminology called “Technical specification or shortly TS”. There isanother terminology called “Technical Report, shortly called as TR”. TechnicalSpecification is standard specification whereas a Technical Report is for aninformational purpose. A TR, later on, may lead to a Technical Specification.

A sample 3GPP technical specification’s cover page is being shown below.


Fig: 1.5 Cover Page of a 3GPP Technical Specification.

Source: TS 22.060. Reproduced with Permission from 3GPP.

Sample Cover page of a 3GPP TS being shown above contains several information. Inorder to decode and derive the relevant information, you must be aware of thenomenclature being used to identify TS. Meaning and decoding of the variousinformation available on a 3GPP technical specifications are described in thesubsequent sections below.

Visit this link: http://www.3gpp.org/specifications/79-specification-numbering inorder to get familiarity about the nomenclature. Knowing the nomenclature andpicking the correct TS is very important from the conformance point of view.


1.1.4 Stages of a 3GPP Technical Specification

Depending on the scope, a technical specification may also be divided into stagessuch as Stage1, Stage2 and so on.

Descriptions of each stage are in the Fig: 1.6 shown below.

In this case the title of the technical specification will be the same but they will havedifferent specification number. The cover page of a sample technical specificationshown above shows the “Stage1” of the technical specification. Look at theinformation that is available in the cover page of 3GPP technical specification.

For example 3GPP TS 22.060: "General Packet Radio Service (GPRS); ServiceDescription; Stage 1" and 3GPP TS 23.060: "General Packet Radio Service (GPRS);Service Description; Stage 2" and so on.

Picking the correct version of a technical specification is very important as yoursystem will be conforming to that particular release of the technical specificationonly. It’s also critical for global interoperability and roaming among the differentwireless mobile communication technologies such as 2G, 3G networks.

Fig: 1.6 Different Stages of 3GPP TS

Stage1 is the

description

of the various

services

requirements being

offered from the

service user point of

view.

Stage 2 is a logical

analysis, breaking the

problem down into

functional elements and

the information flows

amongst them across

reference points

between functional

entities.

Stage 3 is the concrete

implementation of the

protocols appearing at

physical interfaces

between physical

elements onto which he

functional elements have

been mapped. //RT


1.1.5 3GPP Technical Specification Numbering nomenclature

1.1.5.1 Series Number

Each protocol has a unique specification number. An analogy to a technicalspecification is the RFC number e.g RFC 1234, defined by IETF, of a particularprotocol such as ICMP. For example, in the Fig: 1.2 above number within the bracketidentifies the technical specification number of the concerned protocol layer.Technical Specification numbering system is like this: ab.xyz or ab.xy where ab is theseries number of the technical specification. For example, consider the sample TSshown above; the corresponding technical specification number is TS 22.060, where22 is the series number here.

There are bunches of different protocol technical specifications or standards for eachof the wireless mobile technologies areas such as GSM, GPRS, UMTS and so on.Related protocols/subject areas (e.g. signaling, service aspects) requirements of thesaid wireless mobile technologies are grouped into so called “specification series”. Forexample, 3GPP TS 44 series, 24 series specification etc. Within a particular series, allthe related protocol or protocol stack specifications could be found.

Table: 1, in the next page, list the technical specifications available in each of thedifferent wireless mobile communication technologies, such as GSM, GPRS/EDGE,UMTS, LTE (2nd, 3rd, 4th column), as well as under the particular subject area (1stcolumn) of that wireless mobile communication technology. Details on thespecifications numbering nomenclatures, are available herehttp://www.3gpp.org/specifications/specification-numbering.


Table 1 3GPP Specifications Subject Areas and Series (Source: 3GPP Site)

Subject of specification series 3G andbeyond / GSM(R99 andlater)

GSM only (Rel-4 and later)

GSM only(before Rel-4)

General information (long defunct) 00 series

Requirements 21 series 41 series 01 series

Service aspects ("stage 1") 22 series 42 series 02 series

Technical realization ("stage 2") 23 series 43 series 03 series

Signaling protocols ("stage 3") - userequipment to network 24 series 44 series 04 series

Radio aspects 25 series 45 series 05 series

CODECs 26 series 46 series 06 series

Data 27 series47 series (noneexists) 07 series

Signaling protocols ("stage 3") -(RSS-CN) andOAM&P and Charging (overflow from 32.-range) 28 series 48 series 08 series

Signaling protocols ("stage 3") - intra-fixed-network 29 series 49 series 09 series

Programme management 30 series 50 series 10 series

Subscriber Identity Module (SIM / USIM), ICCards. Test specs. 31 series 51 series 11 series

OAM&P and Charging 32 series 52 series 12 series

Access requirements and test specifications 13 series (1) 13 series (1)

Security aspects 33 series (2) (2)

UE and (U)SIM test specifications 34 series (2) 11 series

Security algorithms (3) 35 series 55 series (4)

LTE (Evolved UTRA) and LTE-Advanced radiotechnology 36 series - -

Multiple radio access technology aspects 37 series - -


Information about the different releases (Release4, 5, 6….) of 3GPP is available later,section #1.3.1, in this book.

Note that after Release 4 or R4, the old GSM specification numbers are increased by40 (2nd column from right in the table above) whereas the UMTS standards orspecification numbering is lowered by 20 numbers (2nd column from left in the tableappearing on this web site page) corresponding to each GSM standard. Thus theGSM standard 01.0x is now becomes GSM 41.00x and UMTS 21.xxx. An example isbeing shown below.

Fig: 1.7 Genealogy (TS specifications tree)

Note that technical specifications of a particular wireless mobile communicationtechnology such GSM, EDGE, UMTS, LTE could span across multiples series. Forexample, LTE has the dedicated specifications series i.e 36, See the Table: 1. You canalso find LTE technical specifications in other series such as the TS 24.008.

1.1.5.2 Version Number of a 3GPP Technical Specification

Each 3GPP technical specification has its own version number in the form of a.b.c. Themeanings are as follows:

a

This is the release field. It is incremented each time a major new functionality isadded to the concerned wireless mobile communication technology area such asGSM, GPRS/EDGE, and UMTS and so on.

b

This is the technical field. It is incremented each time a technical change is madewireless mobile communication system development to the specification. Note thatit’s reset to zero every time the release field is updated.

c

This is the Editorial field. It is incremented each time an editorial change is made tothe specification. Note that it’s reset to zero every time the technical field is updated.

For example TS 44.060 V6.0.0 means that it belongs to 3GPP Release 6. Open aspecification and have a look on the meaning of the each number. It’s important to


design and developed a release compliant communication network element in orderto have a successful inter-operability with other vendor's system.

You should consider referring a specification having the first digit of the version as 3and above, because that is the version of the specification being under changecontrol.

More about the version numbering scheme could be found by visiting this link:http://www.3gpp.org/specifications/specification-numbering/81-version-numbering-scheme

1.1.6 Vocabulary of 3GPP specifications

For a list of glossaries of terms, its definition, and the abbreviations as found in 3GPPspecifications as well as being used in this book, please refer the TR 21.905.

1.1.7 Examples in a 3GPP Technical Specification

3GPP technical specifications are full of theories and you will not find, except in somecases, virtually an illustrating example in any technical specifications. This may makeyou difficult to grasp a particular concept at first go. In this case, study the contentsof a particular message or a TS several times. You may take the help of anexperienced professional/colleague in this regard.

1.1.8 Change Control Process in 3GPP

There are change control processes for a technical specification right from itsinception to its final controlled and subsequent updates. If you would like to knowmore about the handling of technical specifications, updating procedures, ChangeRequest procedures, version control mechanisms, specifications status informationetc., look at the 3GPP TR 21.900.

1.1.9 Standardization of Technical Specifications by 3GPP

Standardization of technical specifications is required and important in order todesign interoperable systems by different vendors/OEMs. Because of Standardization,one can avail the various telecommunications services from the different serviceproviders with his/her hand held devices such as Mobile, POS, IPAD etc.

1.1.10 3GPP Technical Specifications series for Access Network

The access technologies offered by the BSS are described in the 45-series of 3GPPspecifications. The access technologies offered by the RNS (FDD, TDD) are described


in the 25-series of 3GPP specifications. The access technologies offered by E-UTRAN(FDD, TDD) are described in the 36-series of 3GPP specifications.

For the complete list of GSM/GERAN TSs refer the 3GPP TS 41.101 V11.1.0.

1.2 Areas of Mobile Communication Network Software R&D

There are different software developments competency areas for each of the networkelement, such as, but not limited to, MS or handset side, BSC, Core Network and soon, in a wireless mobile communication network, Refer Fig:1.1, Fig:1.2 and Fig: 1.3. Athigh level, software developments areas could also be divided into areas such as MSor handset side, BSC or Radio Access Network (RAN) side, Core Network side and soon. Core Network is an umbrella term, which consists of multiple subsystems such asMSC, HLR, VLR, EIR, AuC and so on.

Each network element is developed based on a standard protocol/specification asdefined by the 3GPP. So one has to start with and put focus on a particular Networkelement of his/her interest. Multiple functions are performed by a particular networkelement. Also each network element may have interfaces with its peer elementtowards its left and right hand side. Consider that you are interested working with aBSC network element.

1.2.1 Example Network Element: BSC

A BSC is also called a Radio Access Network (RAN), Refer Fig: 1.1, because it’s theinterface for the mobile station to start using Core Network services. On one side ofBSC is the BTS and on the other side it’s the MSC, SGSN and so on. So a networkelement like BSC has to perform its core functions as well as should support variousinterfaces towards its peers. For example the BSC has the main responsibilities forallocation of Radio Time slot to the Mobile station; at the same time it shouldsupport the A-bis as well as the A-interface with the BTS and MSC to support otherservices such as handover of an active call to a new cell. This is required in order toestablish a successful end-to-end call processing (Fig: 1.4 (b)) at BTS, BSC and MSCend.

Over an interface between two network elements, they exchange various messages inrelation to a particular event such as call establishment; tear down, handover and soon.

So even within a particular network element, there are different areas of softwaredevelopment in terms of functionality, responsibilities or features being supported bythat particular network element. For example, the BSC has the responsibilities of CallControl Management, Mobility Management, Radio Resource Management,Handover and Power control management and so on. Developing andimplementation of these individual responsibilities/functionalities could itself be aseparate project depending on the scope as defined by the concerned 3GPP TS.


1.2.2 Protocol Interface/Stack

You know about the word “interface” while programming using C++/Java or socketAPIs. An interface, excluding hardware, is a logical point where two different systemsexchange information and communicates with each other. Similarly in the world ofwireless mobile communication too, two different network elements communicatewith each other using the predefined messages or Protocol Data Units (PDU). Thesecollective PDUs or messages define the protocol logical interface between the twoparticular network elements. Using a logical interface, network entities exchangedboth the user data and signaling information through a message or a PDU.

Sometimes, an interface between two network elements may contains only oneprotocol, such as the A-Interface between the BSC and MSC, or multiple protocols ina layered architecture, such as the Gb interface between the BSC ad SGSN, Refer Fig:1.2, giving rise to a protocol stack. An individual protocol layer of protocol stack itselfcould be separate project and module.

Various interfaces/protocols are available, mentioned at a later section #2.1, betweenthe network elements deployed across the different wireless mobile communicationtechnology domains (GSM, GPRD/EDGE, UMTS and so on). In order to achieve asuccessful inter-operability between two network elements from two differentvendors, it’s utmost important to decode, understand and implement correctly eachand every messages defined in a particular interface or protocol specification.

Physical Media being used to carry a logical interface messages could be same ordifferent for different protocols. For example, all the IP based mobile communicationprotocols may use the TCP/IP protocol suite and UTP CAT 5 or 6 cable media.Similarly, for GSM A-bis/A interface or Frame Relay protocol, either E1 (2Mbps) or T1(1.544Mbps) link media is used.

1.2.3 Modules /protocol layers of a network element

Within a particular network element like BSC, there could be different softwaremodules where individual module takes care of its own responsibilities as mentionedabove. For example, in the Fig: 1.2 above, there could be a separate module handlingthe RLC/MAC layer, Call Control Management, Mobility Management, RadioResource Management, A-bis interface, A interface, Radio Resources allocation,configuration management and so on. Each module may implement the concernedprotocol layer as defined by the corresponding 3GPP Technical specification.

Note that some protocol used in a particular interface, such as the A-bis, A-terinterface, may be a proprietary one from a specific vendor and not an open standardprotocol. This is because of the vendor specific hardware network elementsconnecting the concerned protocol interface.


1.2.4 Protocol Conversion

Generally, a protocol exists between two network elements only. A network elementcould be the mobile station, BTS, BSC, and MSC and so on. Each network elementimplements and supports the necessary protocol stack as defined by the 3GPP. If theoriginal message sent by the sender was meant for some other network element,then it need to be forwarded to the concerned network element using protocolconversion where the original message will be send to the concerned networkelement.

For example, in the Fig: 1.2 shown above, if a Mobile wants to access Internet usingGPRS (www, ftp, ping and so on), it will send and receive with the BSC only usingRLC/MAC protocol, across the air interface. The BSC in turn collects and converts thereceived data and sends the Mobile’s data using the appropriate Gb interfaceprotocol to the SGSN.

BSC, simply forwards the data exchanged between the MS and the SGSN, which is apart of the core network. Fig: 1.2 above also shows that the data sent by the mobilegoes through different protocols layers, as does your PC while browsing Internet.

1.2.5 Protocol Grouping/Categorization

1.2.5.1 User Plan or data plane and Control or Signal Plan

Note that the protocols operating within a particular wireless mobile communicationnetwork is grouped /categorized into so called “User plane or data plane” and“Control or Signaling Plane”. Below diagrams Fig: 1.8 below depicts the control planeprotocols of a GPRS network.

Control plane or signaling protocols perform the functionalities required in order tocontrol the behavior of the MS activity as well as various other functionalities inassociation with the user plane protocols in order to transfer information betweenthe source and destination. MS activities that the control plane deals are such as MS


attaching, detaching, MS mobility such as location area and routing area update, MSsession management such as PDP context activation, deactivation and so on.

User plane protocols in a network element perform the functionalities required inorder to transmit the user information between the source and destination and vice-verse. Fig: 1.2, in the Section#1.1.1, shows the GPRS user plane protocol structure.Notice differences between the GPRS User Plane and Control Plane protocolstructure.

One example is the FTP protocol used to upload and download files between twodifferent machines. FTP protocol uses the port number 20 to send user data whereasit uses the port number 21 to exchange control command between the twocommunicating machines. Here you can see that the FTP protocol also uses the socalled user as control plan to facilitate data transfer between two devices.

Note that there are two types of signaling, called out of band (e.g. SS7,LAPDsignaling) and in-band signaling (. e.g. SACCH, FACCH over air interface).

1.2.5.2 Access Stratum/Non Access Stratum

Protocols are also categorized into so called Access Stratum and Non Access Stratum.The Access Stratum contains all the functionalities and protocols using which a UE (in3G or LTE) communicates with the RNC. The Non Access Stratum contains all thefunctionalities and protocols using which a UE (in 3G or LTE) communicates with theCore Network. In this case, say, the RNC simply forwards those transparent NonAccess Stratum related messages to the Core Network. Access Stratum and non-access stratum are terminologies that is used in case of 3G and LTE only. Call control(CC), Mobility Management (MM) layer messages falls into the Non-Access stratumcategory while the Radio Resource (RR) layer message are Access Stratum typemessages. Another example of Non Access Stratum is the mobility and sessionmanagement messages exchanged between the MS and the SGSN.

In case of GSM also, BSC simply forwards the CC and MM layers message receivedfrom the MS to the MSC transparently. Those messages are collectively known as theDirect Transfer Application Part (DTAP) messages. There are non-transparentmessages also that are exchanged between the MSC and BSS and it’s known as theBSSMAP (Base Station System mobile application part). DTAP and BSSMAP arecollective known at the BSSAP (Base Station System Application Part). This is shown inthe figure below.


Fig: 1.8 (a) GSM BSSMAP Layer 3 Protocol- Overview

1.3 How to identify and understand a 3GPP Technical Specification

In order to understand a 3GPP technical specification, follow these steps:

(1) First of all, choose a particular wireless mobile technology such as GSM, GPRS, and

UMTS, LTE as your arear of interest.

(2) Use the information available in the table (2nd, 3rd, 4th column) in the section #

1.1.5.1 above, as a guideline in this regard.

(3) Next, decide the particular network element of interest such as MS, BTS, BSC, MSC,

NodeB and so on.

(4) Now have a look at the protocol stack or different areas, functionalities supported by

the chosen network element. See the table in section # 1.1.5.1 for different areas of

interests for particular wireless mobile technology. One way to understand the supported

protocol stack and its functionality is to compare the each layer with the corresponding

OSI 7 reference layer. OSI model operates at several protocol layers in order to allow the

users/PC/devices to communicate with each other. Similarly, network entities of a mobile

communication network also operates at several protocol layers in order to exchange

messages and provides services to the users.

It may be possible that a particular layer contains a protocol stack consisting of set of sub

protocols. For example, suppose you’re interested in GSM and BSC network element.

Further suppose that you’re interested in the Layer3 protocol or protocol stack of a GSM

BSC. Fig: 1.6 below, the GSM Layer 3, shortly called as L3, protocol stack has three

different protocols such as the:

Mobile

Station

BSC

BSC

MSCDTAP

BSSMAP

Call Control

Radio Res. Mgmt

Mobility Mgmt


Call Control Management (CM),

Mobility Management (MM) and

Radio Resource Management (RR).

Note that the Radio Resource Control (RRC) is a separate layer, not a sub layer, in theUMTS protocol stack.

Note that there are separate Layer 3 protocol stack between BSC (e.g. TS 48.008) andcore network such as MSC and SGSN, between the Mobile Terminals and the corenetwork (e.g TS 24.008) and between Mobile Terminals and the BSC (e.g. TS 44.018).Similarly the Gb interface between the BSC and SGSN has a protocol stack, comprising ofprotocols called BSSGP and NS.

(5) Finally, suppose that you’re interested in the Radio Resource Management (RR) sub

layer of the GSM L3 protocol stack. Note that the Radio Resource Management of a BSC

deals with the signaling functions/messages of the GSM L3 protocol stack. Now refer the

table in the section # 1.1.5.1.

(6) Now for GSM and signaling protocols/messages from a MS to BSC, the

corresponding 3GPP TS series number will be either 44 series (After Release 4, including,

GSM) or 4 Series (Before Release 4 GSM). More about Releases are available in the later

section.

Say, you have considered the 3GPP TS Series 44. Within this series, you will find all thetechnical specifications related to signaling messages from MS to BSC. Now look for thetechnical specifications having the title Radio Resource control/management protocoland voila! You got the desired TS. In this case, it’s the 3GPP TS 44.018. For series 4, thecorresponding TS will be the 3GPP TS 04.18.


If you want to find the corresponding technical specification number for the RadioResource control Protocol in case of UMTS or LTE system, follow the same procedure.Technical specification series number for LTE is 36; for UMTS it’s 25.

Similarly, try to find the technical specification number for the CM and MM sub layer. It’sTS 24.008. This 3GPP TS covers the entire Mobile radio interface Layer 3 specification forGSM/GERAN, UMTS and LTE system.

Exercise:

From the Fig: 1.4(b) call processing sequences, try to identify the different messages thatbelongs to the RR, MM, and CC sub layer. Practicing the same shall make you an expertin easy identification of different messages, its concerned TS and the protocol layer.

Fig: 1.2 shows the protocol stack of GPRS network architecture. It also shows theprotocols being implemented and supported by each of the network element, say in theMS, BSS, and SGSN and so on in order to provide various services to the subscriber. Fromthis diagram, it’s also clear that the subscriber data sent by a MS undergoes throughdifferent protocols layers, each one performing its functions in order to transfer user databetween the source and destination. Note the number within the bracket identifies thecorresponding 3GPP technical specification number for the concerned protocol layer.

You can also use the information available in the specification numbering page(http://www.3gpp.org/specifications/specification-numbering) to locate the area of yourinterests under the “Subject of specification series”. From there, find the correspondingseries number, followed by all the related technical specifications under that series,including your interested one.

A 3GPP technical specification also describes the other aspects of the concerned protocollayer. This may include the various timers, like TCP packet retransmission timer intervaland retry attempts, and their values being supported, various system parameters andtheir default, minimum and maximum values, for the concerned protocol layer beingimplemented between the concerned network elements. Some parameters have range ofvalues and it is useful during a network optimization exercise.

1.3.1 3GPP Releases and its Features

Note that the 3GPP technical specifications are organized into different versions called“releases”, such as Release 99, Release 4, Release 5, Release 6, Release 7, Release 8,Release 9, Release 10. A new functionally or feature is added in each release. Note thatRelease 99 was the first version where UMTS was implemented.

Following table list down the feature being introduced in each 3GPP releases.


Table 2 3GPP Releases and its Feature.

Note down the release number and version of the specification that you are referring. Apart fromthe introduction of a new feature in each 3GPP release, a new message(s) or a new informationelement(s) or a new type of channel, either in downlink or uplink, to an existing protocol layermay be added.

If you want to explore further about each release, visit this link:http://www.3gpp.org/ftp/Information/WORK_PLAN/Description_Releases/

1.3.2 Scope of 3GPP Technical Specification

A particular 3GPP technical specification also specifies its applicability/scope to otherwireless mobile technology areas such as GERAN, UMTS, and LTE. Pay attention to thisfact. You can find this information on the download page of particular TS on the 3GPPsite. An example is being shown below.

Fig: 1.10 Scope of a 3GPP Technical Specification

It might be difficult to understand at first such a specification covering multiple wirelessmobile technologies. In this case, you can go through the relevant sections of yourinterests, i.e. GSM, GPRS, and UMTS and so on, only.

3GPP Releases Feature

Release 99 [Year: 2000] UMTS Access

Release 4 [Year: 2001] UMTS Core

Release 5 [Year: 2002] IMS, HSDPA

Release 6 [Year: 2005] HSUPA

Release 7 [Year: 2007] HSPA+

Release 8/9 [Year: 2010] E-UTRA/LTE

Release 10 [Year: 2011] LTE-Advanced


1.3.3 3GPP TS and its Related/Reference Specifications

A 3GPP technical specification also contains a references section containing the otherrelated specifications that may belongs to different network elements but also hasrelation to the specification you're referring. For example a particular feature orfunctionality deployed in a network may require the services from a different networkelements and hence has affects on those network elements too.

Consider the Network Sharing functionality under the multi-operator core network(MOCN) feature. This functionality involves the services from the MS, BSC as well as theSGSN and implementation of the same affects those network elements. In order todesign, develop and deploy a hassle free network operations it’s important to know theother related specifications too and refer the same wherever applicable.

Before proceeding at the other specifications mentioned at the reference section,complete the current specification as a whole.

Basically you will gather all the requirements and dependencies of your networkelements from all the related specifications during requirements analysis phase.

1.3.4 3GPP Releases and it Specifications mappings

If you want to know the TS and its related 3GPP releases mapping, the same can befound in the “3GPP Specification Release version matrix” page by visiting this link:http://www.3gpp.org/DynaReport/SpecReleaseMatrix.htm.

This is the page that contains the complete list of all 3GPP specification numbers andtitles and so, is the place if you only know the title or the subject, but do not know thespecification number.

1.3.5 Download 3GPP technical specifications

(1)Visit the link: http://www.3gpp.org/ftp/Specs/. It will take you straight to thespecifications, but you need to know what you are looking for i.e. the particular TS.

(2)To find a particular specification by series, look at the specification numbering pagehere: http://www.3gpp.org/specifications/79-specification-numbering.

1.4 Differences among the mobile communication technologies

As you become more familiarity and expert gradually about the various mobile wirelessmobile communication technologies, glaring similarities and differences among them toowill become clear to you. Though one mobile wireless technology had evolved from theprevious one, there are startling differences between two mobile wireless mobiletechnologies. The differences and comparative studies could be performed from variousangles as follows:


At the very high level, look at the types of the services like voice, data,multimedia, interactive, streaming and so on, being offered by each of the mobilecommunication technologies.

Look at each of the mobile communication technologies from architectureevolution point of view (Fig: 1.12). See the network element that is beingintroduced or eliminated from a particular mobile communication technologysuch as GSM, EDGE, UMTS, and LTE and so on.

Look at the various types of channels available – physical, logical and transportchannels. In GSM system, there is no transport channel but it exists in UMTS andLTE system.

Study the differences from the point of Air Interface/radio access (i.e.TDMA/FDMA in GSM/GPRS, WCDMA in 3G, OFDMA in LTE and so on) methodbeing used in each mobile wireless mobile domain. In GSM communication, aframe has duration of 4.615 ms divided into 7 slots, where as in UMTS/LTE it's10ms, divided into 15 slots.

Modulation schemes being used in the Air interface of the respective radio accessmethod, services (i.e. voice, data, multimedia and so on) being offered by eachdomain and so on.

Study the differences from the point of various network elements (i.e. BTS, BSC,NodeB, eNodeB and so on) being deployed in each wireless mobile domain, thenthe functions performed by each network element and so on. For example, inGSM domain, Ciphering is performed by the BTS whereas in GPRS domain thesame is performed by the SGSN.

Differences in the handover types (Intra BSC, Inter BSC, Intra MSC …) and powercontrol mechanism being available in each wireless mobile domain.

View the differences from the protocol stack point of view that is deployed ineach wireless mobile domain. For example, the protocol stack being usedbetween the Radio Access Network (RAN) and core network (CN) in therespective wireless mobile communication domains.

Study the various logical concepts, structures, and terminologies available undereach wireless mobile domain.

Study the Idle mode behavior of a Mobile station under each wireless mobiledomain.

Channel Types

For more details on the various channels types and their mapping, refer the following3GPP technical specifications:

GSM – 3GPP TS 45.002

UMTS – 3GPP TS 25.211

LTE – 3GPP TS 36.211


Fig: 1.11 below shows the various channel types available in each of the wireless mobiletechnology areas and their inter-mapping between them.

Fig: 1.11 Various channel Types and their mappings


Fig: 1.12 below shows the various network entities introduced during the evolution ofthe various wireless mobile technologies from GSM to LTE.

Fig: 1.12 3GPP Wireless mobile Technology Architecture Evolution and Network Entities

Some Network element/entity, such as the SGSN, exists during the entire 3GPP mobilecommunication architecture evolution, having same role across the evolutions.

Briefly, apart from the new types of services and increased data rates, following are thechanges introduced during the evolution from the GSM to LTE system:

New protocol/stacks/interfaces have been added for providing packet dataaccess to internet

New network components have been added for providing packet data access tointernet

Enhancements of Air interface providing packet data access Enhancements of GPRS Air interface to improve data rates Evolution of GSM circuit switched and GPRS/EDGE packet switched data networks Introductions of new air interface, from TDMA/FDMA (GSM/EDGE) to WCDMA

(UMTS) to OFDMA (LTE).


Explore Mobile Communication Systems

2.1 Mobile Communication Network Interfaces

As mentioned in the section #1.2.2, a communication, be it fixed line or wireless, network consistsof various logical interfaces over which two network elements communicates with each other to

exchange messages, either control/signaling or user plane or transmission plane or both.Also note that an interface may contain only a single protocol layer or multiple protocolslayers, making a protocol stack such as the Gb interface, consisting of two protocol layersnamely BSSGP and NS.

This section contains a sample list of the various logical interfaces, see the Fig: 1.4(a),available across the different Mobile communication technology domains such as theGSM, GPRS/EDGE, UMTS and LTE.

2.1.1 Circuit Switch Domain interfaces

Logical Interfaces: SS7, Nc, Nb, Mc, C,D,E, F…

2.1.2 GSM/GPRS/GERAN Domain interfaces

Logical Interfaces: A, A-bis, Gb, Um…

2.1.3 Packet Switch Core Domain interfaces

Logical Interfaces: Gs,Gn,Gp,Gi,Ge,Gc,Gf,Gr,Ga…

2.1.4 UTRAN and E-UTRAN Domain interfaces

Logical Interfaces: E-UTRAN domain: S1, S2, S3, S4,X2,……

UTRAN domain: Iu-CS, Iu-PS, Iub, Iur…..

For a list of the available logical interfaces, and their corresponding 3GPP technicalspecification number, deployed among the network elements in a mobile communicationSystem, have a look at the Section # 6, 3GPP TS 23.002 (Network architecture). Also seethe Fig: 1.4(a) in the section #1.1.1.1, which shows the available logical interfacesinterconnecting the network elements. Try to memorize the interface available betweentwo network elements for example: A –interfaces between the BSC and MSC, Gs interfacebetween the MSC and SGSN, A-bis interface between the BTS and BSC and so on.

2.2 How to encode and decode a mobile telecom message

One important aspect of a communication network is the “signaling” or “message”exchanged between the network elements. A communication signaling is nothing but an

2


exchange of series of information between the network elements in order to provideservices to the service user i.e subscriber. For example signaling can be exchangedbetween the MS and BSC, MS and core network element such as MSC, SGSN and so onor between the BSC and MSC or SGSN etc. Correctly encoding/decoding of a message iscrucial for a successful establishment of a signaling in order to start using the desiredservice or smooth operations of the network elements.

2.2.1 CSN/ASN Encoding/Decoding method used in GPRS/UMTS/LTE

Each network element of a wireless mobile communication network implements multipleprotocols at different layers, such as layer 2, layer3 and so on, for communicating with itspeers on the other side of the network. Now the procedure and syntax for receiving ordecoding and sending or encoding of a signaling or a normal message employed byeach protocol layer may be a different one. For example, to send and receive a Layer 2message that belongs to the RLC/MAC protocol in GPRS, CSN.1 encoding and decodingmethod is used.

Similarly to send and receive a Layer 2 message that belongs to the RLC/MAC protocol inUMTS or LTE, ASN encoding and decoding method is used. CSN.1/ASN.1 is nothing butcertain rules, defined at bit/C-like structure level that one has to follow fordecoding/encoding a message correctly. Many CSN.1 encoded example messages anddata structures can be found in 3GPP TS44.060.

If you’re wondering how a CSN encoding/decoding looks like, here is the CSN encodingmethod used in case of the Packet Control Ack message that is used in GPRScommunication, for example.

Fig: 2.1 CSN Encoding Examples.

Source: TS 44.060. Reproduced with Permission from 3GPP.

For details about CSN rules, visit www.http://csn1.info and for ASN, visit


www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf.

Note that encoding/decoding here means you will be required to develop reusable softwaremodule/functions/procedure or C-macro. For example, develop a function to decode and encodea 1 bit or 2 bits or 16 bits or 32 bits value

The ASN encoding method used in UMTS/3G communication systems is being shown below, forexample.

Fig: 2.2 ASN Encoding Examples

As an example, the ASN.1 format for the RRCConnectionRequest message used in thecase of LTE system is shown below.

RRCConnectionRequest

The RRCConnectionRequest message is used to request the establishment of an RRCconnection.

RRCConnectionRequest message

-- ASN1START

RRCConnectionRequest ::= SEQUENCE {criticalExtensions CHOICE {

rrcConnectionRequest-r8 RRCConnectionRequest-r8-IEs,criticalExtensionsFuture SEQUENCE {}

}}

RRCConnectionRequest-r8-IEs ::= SEQUENCE {ue-Identity InitialUE-Identity,establishmentCause EstablishmentCause,spare BIT STRING (SIZE (1))

}

InitialUE-Identity ::= CHOICE {s-TMSI S-TMSI,randomValue BIT STRING (SIZE (40))

}

EstablishmentCause ::= ENUMERATED {emergency, highPriorityAccess, mt-Access, mo-

Signalling,mo-Data, delayTolerantAccess-v1020, spare2, spare1}

-- ASN1STOP


From the above samples of CSN/ASN decoding, it’s clear that the various protocols underUMTS/LTE/GPRS/EDGE are bit-oriented protocols.

2.2.2 Encoding/decoding method used in GSM/GPRS/EDGE

Details about the encoding/decoding method being employed in GSM communication ina particular layer can also be found in the relevant 3GPP specification. For example, toknow more about the encoding and decoding method applied for layer 3 messages suchas GSM, GPRS Call Control (CC), Mobility Management (MM) and RR (Radio ResourceManagement), refer the 3GPP TS 24.007 and 24.008. Note that each messages haveheader part followed by user information/data part in a tabular format. A message orsignaling carries different information through an attribute called information element(IE) and each information element is identified by a so called Information ElementIdentifier (IEI), having different length such as 1 octet, 2 octets and so on.

Specification also defines the allowed range of values, including reserved value, which anIE may hold. There are different types of IE, having different length, depending on thetype of the information they carries. Presence of an Information element in a particularmessage may be a mandatory (M), optional (O) or conditional(C) one. (FIG: 2.3 below)

To summarize and without delving into depth, all these and other important information,that is not described here, could be found in the above mentioned specification. One hasto decode and encode a particular message utmost carefully as per the given IE format,failing to which services will be impacted, otherwise.

The format used for standard information elements in case of GSM communicationnetwork is being shown below, for example.

An example of a GPRS signaling message exchanged between the BSC and the corenetwork using the above encoding method is shown below.


SNS-ACK

The SNS-ACK PDU is used to acknowledge the SNS-ADD PDU, the SNS-DELETE

PDU, or the SNS-CHANGEWEIGHT PDU.

PDU type: SNS-ACK

Direction: BSS to SGSN, SGSN to BSSTable 9.3.1.1: SNS-ACK PDU contents

Fig: 2.3 Standard Information Element Format

Source: TS 24.007. Reproduced with permission from 3GPP.

From the above sample message encoding of GSM/GPRS (except RLC/MAC in case of GPRS)system, it’s clear that the various protocols under GSM/GPRS/EDGE are byte-oriented protocols.

Example: Here is a sample decoded contents of the GSM Assignment Complete Message, sendfrom BSC to MSC during the Mobile Originated (MO) call.

Standard Specification Version: 3GPP Rel4:Dec 2010Message name: Assignment Complete

Message PDU(3octets):0x06 0x29 0x00

RR Management Message:

06 0000.... Skip Indicator = 0....0110 Protocol Discriminator = 6 :Radio Resource Message

29 00101001 Message Type = 41 :Assignment CompleteAssignment Complete:

(3GPP TS44.018 9.1.3)RR Cause:

(3GPP TS44.018 10.5.2.31)00 00000000 RR Cause = 0 :Normal event

Information element Reference Presence Format LengthPDU type 10.3.7 M V 1NSEI 10.3.6 M TLV 4Transaction ID 10.3.10 M V 1Cause 10.3.2 O TLV 3IP Address a) 10.3.2b C TV 6-18List of IP4 Elements b) 10.3.2c C TLV 10-?List of IP6 Elements b) 10.3.2d C TLV 22-?a) the IP Address IE shall only be present if the "Cause" value is set to

"Unknown IP address".b) one or more of these conditional IEs shall be present if the "Cause" value is

set to "Unknown IP endpoint".


Example: Suppose your network element/entity received a 32-bits value, having fouroctets, in a message from a sender. Also, assume that each octet represents a differentinformation element in the concerned message. Now you have to decode each octet’svalue before taking further course of actions based on the value. In this case, a simpledecoding function or macro could be developed as follows:

DECODE_AND_FILL_4_OCTETS (buffer, value_to_decoded)

{

*(buffer=(unsigned char) (value_to_decoded >>24);

*(buffer+1)=(unsigned char) (value_to_decoded >>16);

*(buffer+2)=(unsigned char) (value_to_decoded >>8);

*(buffer+3)=(unsigned char) (value_to_decoded);

}

2.2.3 Direct/Indirect Encoding Method

Mobile communication messages encoding/decoding methods mentioned in thepreceding sections applies, in general, to all the messages defined in a particular mobilewireless mobile domain such as the GSM. There could be other encoding/decodingmethod that is applicable to a particular message only defined in a particular mobilewireless mobile domain. One such method is called as the “Direct Encoding” or “IndirectEncoding”. They’re used in GSM Radio Resource Control layer’s Immediate Assignmentmessage while allocating a list of hopping radio frequencies from the BSC to the Mobilestation.

For details, refer the corresponding GSM Radio Resource Control 3GPP TS.

2.2.4 Segmented Messages over the Air interface

Even a presence of a single bit of information in a particular communication signalingmessage matters a lot for the receiver of the message because it may not be able todecode received message successfully . Sometimes if the whole information content doesnot fit in a single message, the same may be transferred in a segmented way and this isindicated by a presence of a bit in the 1st message segment.


2.3 Alarm in a mobile telecom network

2.3.1 What is an alarm?

Generally an alarm in any system represents an abnormal event being detected by thenetwork entity that had raised the alarm. Similarly, there is a provision of rising of analarm in wireless mobile communication systems too. Depending on the extent ofservices being affected, an alarm can be classified either as:

minor major or critical

A Critical alarm may require an immediate attention and hence requires a quickworkaround

or solution of the event or problem being identified; otherwise it may affect the ongoingservices as well as block further the availing of services provided by the mobilecommunication network too.

In mobile wireless mobile communication systems, an alarm can be raised either due tosoftware, hardware fault or a communication breakdown between sender and receiver orsometimes the receiver sent back an erroneous data to the sending network element.Example of software fault could be due to a process crash; hardware fault could be dueto a BTS or TRX malfunctioning and so on. Generally, a hardware and software fault alarmis vendor specific and hence requires a proprietary solution/remedy for that alarm.

A 3GPP technical specification (TS) does not define such a vendor specific hardware orsoftware alarm requirement. But in case of network elements, such as BSC and SGSN,communicating on standard interface or protocol as defined by 3GPP TS, provision ofraising of alarm exists. Refer the concerned 3GPP TS for the description of the variousalarms defined by it.

2.3.2 Alarms definition in 3GPP TS

3GPP TS define the alarm to be raised under the “Abnormal Conditions” section of theconcerned protocol specification. Each of the alarm being raised contains the reason ofraising of the particular alarm. Following the particular reason or cause, the operator mayidentify the fault location and take the corrective actions in order to prevent disruptionsin services. A list of possible reasons or causes and their meaning can be found in theconcerned TS. 3GPP TS also contains a section called “General Protocol Error Handling”,shown below, describing the various types of events such as erroneous and non-erroneous, and other aspects such as corrective actions to be taken upon occurrences ofan particular event.


Fig: 2.4 General Protocol Error Handling Section of a TS

Source: TS 48.018. Reproduced with permission from 3GPP.

Consider again the Gb interface between the BSC and SGSN. Gb interface contains aprotocol stack consisting of BSSGP and NS protocol layer. The concerned 3GPP TS ofthese layers mentions all the possible abnormal conditions that may occur between theBSC and SGSN over the Gb interface. If such an abnormal event occurs, a necessary alarmcan be raised by the either party (sender or receiver) for the operator’s immediateattention and followed by a recovery action for the concerned event.

2.4 Performance measurement and optimization of a mobile communicationnetwork

2.4.1 What is a counter

A counter is generally an identifier, that records and maintains the information about theimportant and valuable milestone/task, either successful or failure, by a particularnetwork element during the processing of a service, say mobile originated call, requestreceived from another network element. In communication network, there is a conceptcalled “call processing”, see Fig: 1.4(b). This refers to the various predefined tasks, steps orstages that a network element, say a BSC, becomes engaged for an end-to-end servicesright from the establishments to the successful completion of the call. Various tasksperformed by a BSC could be Mobile admission control, selection and allocation of asignaling and traffic channel to the BTS and MS, channel activation, handover operationsand so on.

Outcome of various tasks/sequences of steps performed by a network element could beeither successful or fail. For example, a BSC mail fail to allocate a traffic channel duringthe radio resource allocation procedure.

A network element maintains and updates the counters for all the important and criticaltasks, including activities associated with both signaling as well as traffic channels,performed by it. Those counters are predefined by the system designer, for varieties ofpurposes (discussed later).

You can consider the various events, stages as the important checkpoints that is a andincrement the concerned counters at these pre-identified checkpoints. A networkelement increment the individual counters being maintained for each successful, failure


or exceptional events or stages belongs to a particular call processing scenario such asmobile originate/terminated call, Handover operations, signaling requests, resourcesallocation/de-allocation request successes/failures and so on.

2.4.2 What is a KPI?

A key performance indicator (KPI) tells the network operator about the performance andhealth of the network element as well as the mobile communication system beingdeployed. It’s alike to an ECG report that tells the doctor about the patient’s health of theheart/body. A KPI is derived from an agreed upon, between the network operator andOEM system vendor, formula. A KPI formula could be a simple to a complex one andconsists of various individual counters or measurements, as mentioned in the above para,recorded by that concerned network element during a particular event or call processing(See Fig: 1.4 (b)) scenario over a period of time.

Individual counters or measurements can be collected at a pre-defined interval, say .5 hr,1 hr and so on, put the values in the KPI formula. From the result evaluate and asseseither the health or performance of the network element or the entire communicationnetwork system. A KPI result is generally expressed in percentage (%) term. For example,Mobile originated call successful rate KPI is say 99.99%, handover success rate KPI is 90%and so on.

Some of the commonly known KPIs in case of GSM system communication are as follows:

SDCCH Blocking (e.g. You wouldn’t be able to send SMS) SDCCH Drop(e.g. Call establishments will fail) TCH Drop Rate (e.g Active Call will be dropped Abnormally) Handover Success Rate ( e.g It may lead to active call drop in moving vehicle)

KPIs exists for data services too. Regardless of the types (voice, data) of communicationservices, KPI can be divided into the following broad categories:

Accessibility

Example: How many times (Resources granted versus the number ofattempts/requested) a mobile user was granted resources i.e. channels, either trafficor signaling, while trying to access the network over a given period?

i.e. Accessibility Formula= (Successful allocation/Number of allocationrequests)*100%

Retain-ability

Example: How long the mobile user was able to continue using the services/callwithout an abnormal drop/disconnection?

If you are not able to make a call, it highly possible that there is a high rate ofSDDCH drop in the concerned cell.


Integrity

Example: What is the throughput, say in kbits/sec, being allocated to the mobileuser? An erroneous telecom link shall not deliver the expected throughput to theend user.

Availability

Example: How long the cellular services was available in a particular cell for a givenperiod of time?

Another example is the availability of Traffic Channels (TCH) because of lack of whichwould lead to service unavailability. In this case, you may would like to look for anyfailure in TRX.

Mobility

Example: What is the success rate of call handover within GSM system or betweenGSM and 3G system? Handover types could be Intra BSC, Inter BSC, Intra MSC, andInter MSC.

Note that KPIs formula are not standardized by 3GPP across the networkelements/vendors. Generally, the telecom service operator may defines the differentbenchmarking (%) KPIs apart from the above categories and is agreed by the OEMsystem vendor. As the network evolve, so KPIs too. If any KPI’s result is below thebenchmark one, then the concerned individual counters are examined and necessaryimprovement steps, either software fix or tuning of concerned network parameters, aretaken.

All the KPIs under the above categories have direct impact on the overall service levelagreement (SLA) between network equipment vendor and the telecom serviceprovider/operator. KPIs are also important from the business point of view for thetelecom service provider/operator. Poor telecom services would make a subscriber tomove out of the current one and chose a different service provider.

Note that a BSC may offer both the circuit switched (voice) as well as packet switched(data) services in a cell. In that case, a BSC/MSC shall maintain performancemeasurements/counters for both the types of services.

Consider the following sample figure of a GSM communication system service area. AGSM service area is served by a MSC. A service area consists of several serving cells andthey are under the control of a particular BSC as shown below.


Fig: 2.5 KPI Evaluation Steps

KPIs for aservice(s)Area

SLA

Measurements counters of different categories, as mentioned above, are beingmaintained on per cell basis by the BSC. Analysis of the measurement counters shallprovide the information about a problematic cell.

By analyzing the measurements counters of all the cells and putting it into therespective formulas, shall provide the KPIs results of different categories for the entireBSC/MSC. From the results, respective improvements and corrective measures could betaken, which could be a software fix, fine tuning of system parameters etc.

Refer the 3GPP TS 32.4XX for more information on the Key Performance Indicators.

In order to improve KPI value and user experience, look for the probable root causessuch as the following ones:

Environmental Factor (e.g. Radio link/Air interface, Interference, LOS…) Important Network parameters, dimensioning and its fine tuning Important Network functions/Features being installed Software Fix Hardware Adjustments/Faulty

Counters/Measurements percells. CELL #1

Counters/Measurements percells. CELL #N Post

Processing/Analysis

Solution/Tuning

BSC, MSC.

//RT


Operations and Maintenance

3.1 Field troubleshooting of mobile communication network issues

A mobile communication network consists of heterogeneous devices and systems fromdifferent vendors that work on open as well as vendor specific standards. So one canexpect issues from such a complex communication network. Sometimes the troublescould be an exciting as well as challenging one, opening a new window to your learningcurve.

No communication system is error or trouble free. Problems could be because of yourown network element, other vendor's network element, inter-working, configuration andnetwork planning issues and so on. Error or trouble are caused by various factors andeach one of them must be addressed to isolate and fix the actual cause; otherwise it mayaffect various telecom services, be it a successful call setup, completion or a successfulhandover completion. A trouble free mobile communication is must for an operator tohave a competitive edge and retain customer’s loyalty.

The most troublesome part of a mobile communication system is the Air interface. Herethe information transmitted by the, say, MS or BTS is subjected to go underenvironmental disturbances, such as interference, weather condition, physical geography(city, atop hill) and so on, leading to the corruption of bits of information. This is trueregardless of the type mobile technologies such as GSM, GPRS or UMTS network beingdeployed. You may have tested thoroughly and found the result as expected from yoursoftware component. But that is at a lab condition, which is under a controlledenvironment where there are no external disturbances to the radio wave propagationbetween the sender and receiver say, a MS and BTS.

To combat error resulting out of air interface issues, each mobile wireless mobiletechnology uses different error correction and recovery mechanisms in order to protectthe user data transmitted by a MS or BTS. Other network element, such a MS, BSC, MSC,SGSN, and so on, may also introduce errors. For example, say you have a BSC fromVendor X and a MSC or SGSN from another vendor say Y. Problem may crop up whenyou try to integrate both the BSC and MSC since they works on open 3GPP standardsand it’s up to the vendor on the Compliance and implementation of their particularproduct.

You could expect any kind of field issues from a mobile communication network.Whenever a customer makes a complaint about his inability to avail a servicesuccessfully, the root cause of the same may not be clear at the first instance itself. Inthat case, you can use your intuition as well as the past experiences as the starting pointto proceed further in resolving the issue. You may also have detailed plans to addressand resolve customer issues. Nevertheless, you can perform the following basic steps totroubleshoot your field issue being reported to you.

3


3.1.1 Drive Test, Data Collection and its Analysis

A Drive test, performed in a particular problematic cell/site, is used to troubleshoot issuesarising out of Air interface related problems, which may affect a single customer, ormultiple customers or other neighbor networks too. A Drive Test can be also used toexamine the serving and surrounding RF conditions as well as successful functionalitytesting such as CS call, GPRS call and so on during a new cell site commissioning phase.A Drive test is performed before a cell/site is released to carry actual customer trafficfrom the newly rolled out site. It’s like perform the test, capture the values, analysis it andthen recommend and tune the appropriate value for corrective actions.

For a Drive Test, there is a special kind of mobile equipment, fitted in a vehicle that canbe used in a particular cell either in stationary or moving condition to simulate the actualmobile user’s behaviors. Also the test mobile equipment or MS can be positioned eithernearer to the base station, little bit far and farther from the base station to simulate theend users behavior. This MS can scan and verify the current Radio environmentconditions, including interference, received and transmitted signal level, neighbor cells,and various system parameters being transmitted by the BSC and received by the MS.

Attached with this special MS is the software that shows the various signaling messagesbeing exchanged between the MS and BSC or the core network. One can examine anddecode the contents of each message and see for any erroneous value, which is possiblycausing the current problem. A cell can be located at a city, village, having obstacles inproper signal propagation or atop a hill.

Depending on the cell site, various system parameters need to be tuned accordingly. Thisis possible through Drive Test exercises, have a look on the current value andrecommend for the appropriate one. A Drive Test procedure is also used to performnetwork optimizations, which is an ongoing activity to utilize the network resourcesincluding the Air interface optimally while offering the desired of quality of services tothe customers. This is because a communication network may evolve over a period oftime, requiring a periodic monitoring and a fine-tuning the same.

A Drive Test can also be used to measure data throughput being provided, say in a GPRScall, in a typical network and rectify the possible causes, if the throughput is found to below and not a satisfactory one.

Some available tools to perform Drive test, collect data and troubleshoot Air interfacerelated issues are:

TEMS Investigation, NEMO.

Look for the online resources to know more about such tools.


3.1.2 Log/Traces collections

There can be problems too arising out of various interfaces such as Air, A-bis, A,Gb , IuCS,IuPS and so on, issues. In that case, identify the suspected interface first that is causingthe current trouble and following it, collect/capture the required messages exchangedover this interface between the concerned network elements such as BSC and MSC orBSC and SGSN and so on. From the logs, verify that the contents of the messages beingexchanged are correct with respect to the concerned 3GPP TS. It’s possible that thesender was sending a wrong value or it did not include a mandatory element as definedthe concerned TS, leading to the current trouble. In that case the bug must be fixed atthe sender side.

Some available tools to collect logs for various interfaces related issues are:

TEMS Investigation: used to collect logs for Air interface related issues Nethawk, M5 Analyzer, K12, OSIX: used to collect and analyze logs for A-bis, A

interface and other interface related issues Wireshark: used to collect logs for IP interface related issues

Wireshark is the most popular IP based and free protocol analysis and troubleshootingtool, used during the development as well as post operational issues, virtually supportingall the available protocols be it mobile communication protocols (GSM, GPRS and so on)or data communications protocols.(TCP,IP, FTP, VRRP, and so on). A sample IP packetsnipping using Wireshark is shown in the Fig: 3.1.

Fig: 3.1 A sample IP packet snipping using Wireshark


You can use the Wireshark to experiment with and understand the various IP protocolseven with your desktop.

Mobile handsets markets are flooded with mobile devices from the various manufactures.Similar is the case for other network elements such as BSC, MSC, HLR, SGSN, and GGSNand so on from different vendors. Problem can crop up anywhere in the networksometime, for example, because of a low quality non-compliant MS that behaveserratically, causing trouble either for the RAN or CN.

3.1.3 Conforming Testing Issues

3.1.3.1 IOT (interoperability testing) Issues

Interoperability is the ability of a network element/system to operate successfully inproviding as well as accepting services by communicating and exchanging informationwith other vendor’s network element/systems.

Interoperability issues due to the integration of network elements from different vendorsthat work on open 3GPP standards may also cause problems. Generally an IOT issue mayarise whenever a piece of information, either in control or user plan message, from aconcerned specification is interpreted wrongly and implemented in an unexpected waythat makes the other network element to discard the same or respond with an error codeto the sender of the message. Sometimes IOT issues may also crop up because ofimplementation of a paradoxical kind of information contained in a 3GPP specification. Inthis case, issues may be troubleshoot and rectified by following the above-mentionedmethods.

3.1.3.2 Protocol Stack testing and validation

Now that you are aware of the fact that 3GPP contains more than dozens of logicalinterfaces, starting from the alphabet 'A', containing a protocol/protocol stack, interconnecting the various network entities of Access Network(AN), Core Network(CN) andalso the handset(MS), of a mobile telecomm system.

For details about the different protocol interfaces, refer the 3GPP TS 23.002.

a) As a starting point, identify your focus area, i.e. AN, CN, MS, of protocol testing.

b) Find the various interface(s) connecting AN and CN, or MS and AN and so on.

c) Study about the various messages/protocol data units (either control plane or user

plane) and its contents exchanged over a protocol interface.

d) You will be also required to study on the usages, and the interpretation of their

report, of various testing tools available. For example, to capture:


Air interface messages exchanged between the MS and AN, you can use TEMSInvestigation tool, NEMO etc.

IP based Protocol message between AN and CN, you can use Nethawk Analyzertool.

To capture any IP based protocol messages, use the most popular tool Wireshark.

e) Drive Test: It’s used to observe and rectify various issues arising out of Air-interface.

Tool such as TEMS Investigation could be used.

f) Interoperability testing (IOT): It's the testing of your network entity/system (say BSC)

with other vendor’s network entities/systems (say SGSN, MSC).Tools such as

Nethawk Analyzer, Wireshark could be used.

g) You may be required to develop a software test stub:

To simulate the behavior of peer protocol/network entity that is not in yourcontrol.

To test every possible input to every variables of a 3GPP message. To test every possible negative, race conditions, exceptional or abnormal

scenarios such as timer expiry, exceeding of max retries and so on. To test every hardware / software configuration/limit as defined in the concerned

3GPP protocol spec. To test the state machine of a protocol layer.

h) You may be required to develop a software defect tracking and management System

for easy bug tracking, testing and record.

i) You need to have experience in creating, managing, reviewing of test plans to

coordinate with several test engineers and also test automation experience, through

scripts.

j) You need to test the performance, in terms of KPI, of your module that implements a

protocol or protocol stack.

k) There are several categories of software testing such as the following ones. Know

about them.

System Integration Subsystem Integration Regression Test Load Test


Mobile Communication System Development

4.1 Development Platform for a mobile communication network

4.1.1 Selecting Hardware Platforms: Legacy Unix/Linux versus PC

Selection a hardware platform could be a complex decision. One can choose from theavailable platforms, hardware as well as software, to be adopted for a particular networkelement to be designed and developed. To select a target platform, a detailed feasibilityand comparative study should be performed on the available platforms, including boththe technical as well as the commercial aspects. You may also use the experience ofyourself, your team and other developers in your network. While doing this exercise,project’s requirements should also be taken into account.

One should consider the various advanced features (described in the late section #4.1.2.2), support, and development as well as debugging tools available, and so on,provided by a particular platform being identified. Available platform could be Windowson Intel, Sun Solaris Unix on Sparc processor. It could be a Digital Signal Processor (DSP)or an embedded version of LINUX/RTOS on embedded processor, including Multicore(more about in the later section), based on PowerPC, ARM, and MIPS architecture.

There could be vendor specific proprietary platform too, both hardware as well assoftware. Choosing and selection a target platform is the key point before a particularnetwork element could be designed and developed as the software architecture of thesame will have a close relationship w.r.t the target platform to be used.

Generally, Unix and RTOS based on embedded digital signal processor (DSP) plug-inunit(PIU) platform are used to deploy core elements (such as BSC, MSC, and so on) of aMobile telecom network as these platforms offer much more flexibility and secured thanthe other platform such as Windows.

Apart from this, almost all the of Unix/Linux flavors offers a varieties of useful tools (e.g.perl, tcl), utilities and commands, such as cut, awk, sed, and so on, that can be used toperform verities of customs tasks such as reporting, scripting, system monitoring and soon. One will have to develop hundreds of lines of code should you opt to perform thesimilar task on a Windows platform.

4.1.1.1 Development using Embedded System - Board Support Package (BSP)

Software design and development on an embedded system with a real time operatingsystem such as Linux, VxWorks OS is different unlike the traditional one using Windowsor UNIX platform. On a traditional system, like Windows or UNIX, one needs to justpower and login to the system and start working the same using the development

4


environment/tools/SDK. For every platform, there is a boot process right from pressingthe power on button till the login window.

During the boot process and till the operating system is loaded and is ready to acceptuser inputs, hundreds of lines of codes are executed and get initializes the various systemresources such as processor, RAM, bus, clock, interrupt, NIC, boot loader and so on. But,in the world of embedded system, one has to develop and write code himself/herself toget initializes the various system resources, mentioned above, make them ready and startusing the embedded system/board by a real time operating system as well as the customapplication software. Those coding, both low level as well as high level, done for differentsystem resources areas are collectively known as the board support package (BSP).

A board support package consists of the functionalities such as:

Boot loader built in self-test (BIST) or power on self-test (POST) Ethernet driver Memory allocation routines Flash Memory routines Interrupt Controller routine Various Registers/drivers initializers Serial port driver

If you choose the Linux as the embedded operating system, you will be require to studyabout the GNU toolchain collection in order to build a proper embedded systemdevelopment environment. GNU toolchain supports the C/C++/Assembly languageprogramming languages. It also contains Linker, Assembler, and an IDE.

Note that BSP is dependent on the particular hardware model/type as well as theoperating system being selected. One needs to study thoroughly the selected hardwaretype and its reference manual in order to provide a stable platform for the applications torun and work properly.

Apart from the development of the BSP on an embedded system using Linux, one maybe required to customized the platform being used for project specific requirements,develop/modification of device drivers, and interrupt controllers and so on,

4.1.1.2 Development using Multicore Hardware Platform based Embedded System

Now that you know about multiprocessor, multiprogramming computing platform as youhave already studied them during your undergraduate course. The latest buzzword is themulticore, which is the new computing paradigm. Yes. It’s an age of embedded multicoreplatform. Multicore platform is everywhere, be it desktop, server, Smartphone and so on.


If you want to explore and experience a bit further on the multicore computing , openyour desktop or Laptop which is already running on general purpose multicore processorsuch as Intel Corei3, i5 processor. Assume that your processor is an Intel Core-i3-2130version with hyper threading enabled. This processor version has 2 physical cores and 2logical cores per physical core, giving it to 4 cores. To see the cores that are in services,open the Windows resource Monitor (On Windows: Choose Start->All Programs->Accessories->System Tools->Resource Monitor)

This shows the number of cores currently running on your system.

Fig: 4.1 Sample Snapshot: Windows Resource Monitor showing multiple cores

Here you will find two cores are being marked as “Parked”, which means they are notactive currently i.e. no processes are running on it. This is how Windows managesmulticore processor and saves the power consumption by the processor. The same coresmay be un-parked i.e. new processes shall run on it, as decided by Windows OS, whenyou are running something that requires a lot of CPU power. You can also assign aprocess manually to be run on a particular core using the Windows Task Manager andobserve the activity on the newly assigned core using the resource monitor.


4.1.1.3 What is a core?

A core is nothing but a processing engine or a unit of a processor. A Multicore processorcontains several cores, either identical or non-identical that forms a computingenvironment. Examples of single core and multicore platforms are shown below.

Fig: 4.2 Single Core and Multicore processor Systems

4.1.1.4 Why use Multicore Processor?Some compelling reasons for deployment of Multicore Processor based system are:

There are power & performance limits in case of single core processor(s). Further

increasing of the clock frequency of the processor shall not raise the performance

but the power requirements will go up. On the other hand, multicore processor

architecture takes advantage of the fact that a small reduction in processor clock

frequency and voltage saves a great deal of power, while reducing performance

only a little.

Advances of Mobile broadband demands network elements or entities having

high performance, high throughput, service rich applications, data or traffic

processing capability from Megabits to Gigabits. This is because of most of the

logical interfaces mentioned earlier are nowadays based on IP layer.

They offer the potential to get more packet processing done while reducing

power consumption, increase capabilities and performance, and, in general, do

more with less.

There is a direct impact and benefit on the real estate requirements as the

multicore system have become small and compact in size. Physical size of the

system deployed based on a multicore system and IP based solution have

reduced to a desktop computer size.

Multicore processor have hardware acceleration blocks/components that offloads

the software in processing compute intensive tasks such as

encryption/decryption, deep packet inspection (DPI) for IDS, IPS (intrusion

detection and prevention).


4.1.1.5 Types of Multicore Systems/Platforms

When utilizing a multicore, there are two fundamental ways the operating system canmanage the cores.

(a) Symmetric multiprocessing/multicore (SMP): Here one operating system iscontrolling multiple cores. (Fig: 4.3) and decides which core to run eachtask/process/thread.

(b) Asymmetric multiprocessing/multicore (AMP): Here one operating system runs onper core. It could be two copies of the same OS or two very different OSs such as anRTOS and a general purpose OS like Linux. One example of AMP is the virtualization, ofdesktop/servers, where more than one OS (different) is deployed. (FIG: 4.3)

There are advantages and disadvantages of both approaches, and the best choicedepends on the requirements and application you're deploying.

Fig: 4.3 SMP and AMP

For the various available and allowed configurations, refer the documentation, SDK thatcomes along with the multicore processor you have purchased. Select the configurationthat suites your system and application requirements.

4.1.1.6 Multicore software computing

Software development on multicore platform, containing cores: 1...N, fundamentallydiffers from the general purpose platform in several ways. In case of the later one, youdevelop software without much bothering about the underlying internals ofhardware/processor being used. But on a multicore platform, one needs to work veryclosely considering its internal details such as hardware/processor/memory/board used.A module written for a traditional general purpose hardware/processor will not work on amulticore platform straightway. Re-architecting and Porting of your module is the answerin this regard. Some areas where you need to focus and know about the embeddedsystem development based on a multicore platform are:

Concurrency among the cores Partitioning of Application Memory Architecture


Interconnection among the cores Synchronization (hardware and software) Hardware Acceleration Languages and Tools System Debug using specific tool such as JTAG.

4.1.1.7 Some challenges in multicore computing

In case for a multicore processor, the level of sharing and concurrency is much

higher and multiple things/events/tasks occur at the same time. Depending on

the architecture, the cores in a multicore system typically share many more

resources, such as interrupt controllers, devices, and caches, say L2 cache.

Requirements of partitioning the application to expose enough concurrency to

use all available processors, and scale up if more processors are added in the

future. When a task or program cannot be partitioned into several subtasks,

application of more effort in terms processing unit “core” may not yield the

desired performance.

Develop and debug software for a multicore environment that allows concurrent

execution of multiple tasks, threads, and processes. Problems arising out of

concurrency and reported from field may be difficult to reproduce at Lab.

Correcting race conditions and deadlocks.

Establishing reliable inter-process and inter processor communication among the

competing cores.

More cores means more work done but at the cost of extra effort and significant

challenges for the developers.

Requirements of re-architecting of application and support the concurrency.

4.1.1.8 Developing Telecom System/network entity using multicore platform

An application is a good candidate for multiprocessing if it requires a large number oftasks to be completed, but the completion of one doesn’t depend or depends onlyslightly on the completion of the other jobs. If the application is a single large job, buteach piece of it depends on another, and also there is a high degree of requiredserialization, then a multicore platform may not be a good choice in this case. Forexample, a child birth takes place after a definite time interval, no matter how muchresources/efforts are put :)

But if you look at the protocol/stack/system architecture of available wireless mobilecommunication technologies (GSM, GPRS, .....), one can choose to deploy a telecomnetwork element based on a multicore platform having 1..N cores. For a telecom networkelement/entity, you can deploy multiple cores and design, architect your softwaremodule in this way at macro level:


Deploy the Symmetric Multicore Platform (SMP) system.

Have dedicated cores or group of cores responsible for controlling and managing

the Control plan/slow path and user plan/Fast path.


the various logical interfaces such as Air, A-bis, Gb, and so on.


the system administration; operations and maintenance tasks.

Have dedicated core for handling uplink and downlink data flow.

Apart from the telecom and networking space, multicore processors and systems havetheir widespread use in OEM/commercial products, switches, routers, and other multiplemarket segments.

For a guide on Multicore Programming Practices Guide, visit the Multicore associationsite here: http://www.multicore-association.org/.

4.1.1.9 Examples of multicore processor

One example of multicore processor deployed in the Telecom segment is the OCTEON IICN68XX family processor from Cavium Networks. See the Fig: 4.4 shown below.

Fig: 4.4 Block diagram of Cavium CN68XX multicore processor


For further details about this multicore processor, visit this link:http://www.cavium.com/OCTEON-II_CN68XX.html.

OCTEON II CN68XX family processor shown above have maximum of 32 cores whereeach core have its own L1 cache and shared L2 cache memory. Have a look at thediagram below for further on the various building blocks and interconnection among thecores. Try to study and compare with other multicore processor such as Intel and AMDdual core processor.

Architecture of a multicore processor could be different from vendor to vendor. Forexample, A multicore processor could be based on the MIPS (from Cavium Network),ARM or Power PC (from Freescale Semiconductor) architecture.

4.1.1.10 Runtime choices of multicore processor

A multicore processor may provide multiple runtime environments/choices to run yourapplications/modules. Refer Fig: 4.3 above.

Simple Executive environment – where a core executes and runs a standalone user

application without the requirements of an operating system such as Linux.

Symmetric Multicore/Multiprocessor environment – Where an operating system

could be run on multiple cores or a single operating system can control multiple

cores. In this case an application may also run in kernel mode.

The choice of runtime environments is derived based on the application’s or entireproject’s requirements. For example, you can run the Linux SMP operating system oncertain cores whereas you can run the simple executive application(s) on the remainingcores.

4.1.1.11 Software programing model for Multicore processor

Even with a SMP multicore system, there are two software programing models that canbe used to designing and development of software module for processing ofcommunication events. These are:

Run-to-completion programing model

Pipelining Programing Model

In run-to-completion programing model, a designated core would perform theprocessing of the entire sequences of tasks/packets processing for a particularcommunication event. This leads to the monolithic software design and can leadsunexpected issues during its maintenance.


In the pipelining programing model, different sequences of tasks/packets processing aredivided into stages and assigned among the available cores. This leads to the modularsoftware design and ease of maintenance in the long run.

Consider the typical case of communication call processing scenario for theestablishments of a mobile originated call, Fig: 1.4 (b). In this call processing scenario, theBSC allocates the necessary radio resources to the requesting mobile device. While doingso, the GSM L3 sub layers: CC, MM, and RR layers perform the required processing forthe concerned mobile device. In this case, the CC, MM and RR protocol sub layers couldbe implemented separately (pipelining) and assigned to an individual core instead of amonolithic (run-to-completion) designed for processing of the same scenario. Any bugcorrection or enhancements made shall affect the concerned layer only in case ofpipelining model.

Selection of a particular programing model based on a multicore processor shall dependon the application’s requirements. For more examples/samples, visit:http://university.caviumnetworks.com/download_center.html.

4.1.1.12 Closed/ proprietary vs Open Platform: Carrier Grade Linux (CGL)

Current mobile communication systems are based on either traditional UNIX, such as SunSolaris, or embedded platform that are closed and proprietary system. Such platformhave both the hardware (processor) and software (OS) that are supplied by the vendor asthe one stop solution. This creates a dependency for the network operator on theplatform vendor; sometimes it could be difficult to maintain the platform by theoperator.

An alternative to close and proprietary platform is the open system such as Linux kernelbased operating system. Open System are advantageous such as: independent of aparticular vendor, less cost, availability of source code, and support for a broad range ofprocessors. But the Kernel of various Linux platforms/distributions (called shortly asdistros) may not be ready for deployment in the communication space. There arerequirements that a Linux Kernel must meet in terms of availability, scalability,manageability and service response time. The Linux Foundation(http://www.linuxfoundation.org/) defines these sets of Linux Kernel’s requirements fordeployment in the communication industry and these requirements is called as the“Carrier Grade Linux” requirements. Current version of tis requirement is CGL 5.0. Formore details on the Linux Kernel’s Requirements, visithttp://www.linuxfoundation.org/collaborate/workgroups/cgl. Linux distros meeting allthese requirements are said to be Carrier Grade Linux.

The term carrier-grade refers to the requirements of availability of a Linux platform,which requires up to 5 nines (99.999 percent) or 6 nines (99.9999 percent) of availability.This translates into a downtime per year of 30 seconds (6 nines) to 5 minutes (5 nines).


Therefore, if you’re planning to design and develop a mobile communication networkelement/system based on an embedded multi-core processor, you may look for thecarrier grade Linux as your operating system, for example, WindRiver Linux. Learn moreabout CGL benefit and advantages here: (http://www.windriver.com/products/linux-cgp/).

4.1.2 Selecting Software Platforms and features

Software development platform to be used has closely links to the hardware andoperating system platform that you have chosen. Each hardware and operating systemplatform has their own development environment in terms of software development kit(SDK).

Apart from this, development languages such as C and C++ are used to develop coreelements of a mobile wireless mobile communication network. This is due to the fact thatthese languages, in combination with inline assembly language, can be used to accessand program hardware, including processor, resources etc. Such capability may berequired depending on the kind of system being developed as well as the operatingsystem and hardware platform being used. Also, all the available operating systemsallows the system services provided by it to be access through a pre-defined sets ofC/C++ APIs, for example, to perform an inter process communication, process/threadcreation/termination and so on.

As per as C/C++ languages are concerned, they expose low-level system facilities andalso allow direct calls to native system libraries. So a full access to the features andperformance of the platform on which the software runs can be performed using theC/C++ languages. You need to be an expert in using and handling of the various datatypes/operators such as the following ones, while implementing protocol layers:

Structure, array and pointer, union, Bit field

right shift(>>), left shift (<<), &, |

Above operators/data types are used in encoding/decoding of protocol information. Onecan also use third party software library tools, e.g. STL, in order to cut down the overalldevelopment time. This will also reduce the software maintenance cost over a period oftime.

If you are going for an open system platform, you can also deploy the GNU toolchaincollection that supports the C/C++/Assembly language programming languages. It alsocontains Linker, Assembler, and an IDE.

4.1.2.1 Available Data/logical Structures to choose

Next comes, while designing and developing of mobile communication software is thedata structures to be chosen and used in your application. You are already aware of thevarious data structures, from a simple to a complex one, available to be used in yourapplication. If a particular data structure is not sufficient and suitable for your particular


application, the essential data structures will have to be built by you. Alternatively, if youdo not want to reinvent the wheel and also do not have time to do so, you may go forany third party software library tools and integrate it in your own application.

Advanced Data Structures

You have already studied about the following advanced data structures in your course.

Linked List Stack Queue Hash Table Trees

Above data structures have different applications and you will be required to choose aone, or a combinations, depending on the nature of your application, kind of data it’sgoing to store and performance requirements. Typically there are types of information:static (such as Mobile user database/credentials) and dynamic (such as the live numberof mobile user that comes and go in a BSC). You will be required identify all types ofdata, and its amount too, that is going to be stored for a particular network element andthen select the best suitable data structure for each type of the data.

For example, to implement a lookup table in order to store and fetch an index, generatedbased on a random number, of a mobile device, you’re like to use the Hash tablestructure because the searching time for a Hash Table could be lesser than the other typeof data structure. A network element contains several information/attributes of differenttypes and in this case you will be required to use any combinations of the above datastructures. For example, a mobile device’s index fetched from a Hash table could be usedto search a tree structure that stores and contains the details about the concernedmobile device.

How Data Structure affects the Application’s Performance

Another important aspect is the selection of the correct data structure whenever there isan alternative one to store, retrieve or modify information in your application. Datastructure to be used by an algorithm or function/procedure can greatly affect theperformance of the same; even the performance of your application could be affected.For example, to store, retrieve or modify, store large amount of data, the best candidatesto be chosen are the self-balancing binary trees such as AVL tree, Red-Black tree, B-treeand so on, because they provide better searching time (Log2N) than an array (O(N)),which takes a linear searching time.

Consider the time to be taken to lookup an item out of 500 items. An array will requirelinear search time for 500 items to be inspected whereas the binary tree will require only9 nodes to be inspected! But Hold On.


A binary tree may not always result into the expected performance because it woulddepends on the order in which the node are inserted runtime. Instead of a half traversingtime, sometimes searching of a binary tree may take the linear time, as with an array, fornodes inserted in the linear order. Consider the following figure of a binary tree.

Searching the binary tree like the Fig: 4.5 (b) above will take linear time, like an array,because after each comparison the remaining number of nodes to be searched isreduced by 1 node only, not by half of the current nodes, as with the binary tree shownin Fig: 4.5 (a). So the searching time for a binary tree would depend on its topology i.e.the order in which the nodes are inserted.

Note that the choice of a particular self-balancing binary tree may again depend on thetype of storage or system, traditional or embedded, being used. For example, for amemory based storage embedded system environment, a Red- Black tree could be moreappropriate whereas for disk based storage, such as UNIX, an AVL or B-tree could bemore appropriate to be used.

4.1.2.2 Selecting an Operating System Services/Facilities

To design and develop wireless mobile communication software, one must have theknowledge and skills on the advanced facilities being provided by the chosen operatingsystem. On UNIX platform, of particularly interests are the requirements of the advancedknowledge on topics such as threads and multithreads programming, differences amongthe semaphore, mutex, condition variables and so on. One must also know thedifferences between the System-V and POSIX IPC mechanisms, including socket, itstypes, usages, and choose the one that is appropriate for his/her application. One of themost important resources being provided by an operating system platform is the timerfacility. Every protocol layer, be it on MS, BSC, MSC and so on, has its own sets of timersthat are used to track a particular event being initiated towards the other end. At theexpiry of the concerned timer, an appropriate predefined action is taken. A soundunderstanding of the timer functionality being provided, either by the hardware orsoftware platform is very important.

Note that two different network elements, for example BSC or MSC, may be running ondifferent platforms with different hardware and software but they do communicates witha common transport media such as IP, Frame Relay(e.g, in GPRS network), ATM(e.g. in 3Gnetwork), E1 interface and so on.


Using Advanced Features of Operating System

One need to be expert on the proper usages of the following advanced features beingprovided by the chosen operating system:

Various IPC (Inter process Communication) mechanisms such Message Queues,Shared Memory, Pipe, Semaphores.

Signal Clock and Timer Synchronizations

Features such as shared memory, message queue, semaphore, socket, pipe and so on,can be used to perform an inter process communication between two processes ormultiple processes. Compare the various IPC mechanisms/facilities provided differentoperating system/platform and chose the one that is best suits your application’srequirements.

On Unix/Linux platform, there are around 30 system defined Signals. You may berequired define and implement a user defined signal apart from the ones provided byyour operating system. One needs to select a particular IPC method depending onhis/her application requirements and also after considering the various pros and cons ofeach method.

Timer is another important resource provided by an operating system. You will berequired to implement various timers as provisioned in the concerned protocol layer andtechnical specification defined by the 3GPP.

4.1.2.3 Portability of systems

During the design and development phase of a particular software module, it’s worth topay an attention on its portability aspects in order to avoid or reduce reworkrequirements, if any, later on. One software module or the entire network element mightbe required to port from one platform (hardware or software) to another one, forexample, from a proprietary UNIX platform to an open source based Linux platform orfrom a prototype hardware board to a production board or from non-embedded to anembedded platform one. If you’re developing a networking module, its better off to usePOSIX based APIs /system calls rather than a platform dependent APIs. Similarly one canuse an open system development environment such as the GNU toolchain set.

4.1.2.4 Software Simulators/Emulators for a mobile communication network

Now that you know that a mobile communication network consists of various networkelements working in tandem with each other following common open sets of standardsas defined by the 3GPP. So, during the development and testing phase of your networkelement/module, you would be required to test all the functionalities and features asdefined by the concerned technical specifications.


Your network element, a protocol stack or a particular module may have interfaces withmultiple other third party network elements. But you may not have the required andexpensive third party network elements from different vendors to be integrated and testwith it your own network element. Sometimes, a system does not work always asexpected. In this situation, a software simulator/emulator comes into handy that will tryto create a real life live network element/environment with the capable of creating bothexpected and unexpected/abnormal scenarios.

Generally a software simulator/emulator is designed, developed and used to exhibits thebehavior of a network element sitting on the other side of the protocol stack byexchanging the concerned messages under successful as well as failure or abnormalscenarios. In this way, you can test your software module or network element and pre-decide the action to be taken following an erroneous condition being detected at field.

Note that not all types of bugs could be caught and fixed during the testing, integrationphase. Should a difficult to reproduced a bug appears from a real life live network at laterphase, the usage of simulator/emulator comes into of great help to try reproduce andfixed the bug in the observed scenario.

You can also use a simulator/emulator to generate load test and measure the near aboutperformance of your module or network element from a real life live network point ofview. For example, assume that you’re developing a module for a customer in order tosupport a large cell site, which will require a large number of Radio channels, equipmentsuch as BTS, TRX and so on. Your lab may not be equipped and have such a largenumbers of equipment in order to test your module to its full capacity. In such ascenario, a network simulator comes into handy. In this case, you need to configure thesimulator to support the required system capacity through software support only andgenerate loads/traffic; thus saving from the requirements of actual lab hardware.

You can measure and improve the performance in terms of reliability, availability, andmemory and CPU utilization, number of call being supported during busy hour periodand so on. A customer will stare and compare at such important performance matricesbefore he decides finally to deploy your network element.

4.1.3 Mobile communication network software debugging

A mobile communication network services may be affected because of an erraticbehavior or undefined behavior of a network element. Leaving aside the other externalfactors, such behavior could be because of poorly designed or carelessly writtensoftware. Debugging procedure of a software issue could be different depending on theplatform, e.g. embedded or non-embedded, being chosen to deploy the networkelement. In this case, follow the debugging procedure being identified for a particularplatform with the available tools supported by it. One can use third party tool too, suchas purify, to debug a software module and make it bug free. You can also develop yourown test stub or a simulator in order to simulate a real and practical, but difficult toreproduce, field like scenarios.


4.1.3.1 Incorrect Usages of Software Library system calls/APIs

Apart from the issues that could appear due to software module design aspects, thereare other software dogmas whose negligence or careless usages can results into asleepless night for you. Those are the dogmas that should not be overlooked while usingthe various facilities being provided by the particular platform/operatingsystem/development language. Some common facilities that are provided by everyplatform are: memory manipulations routines, string manipulations routines, buffermanipulations routines and so on. These facilities are provided in term of reusableroutine or C programming language Library of APIs. Any incorrect usage of theseroutines may results into an undefined behavior of your module at different point oftime, which will make you to hunting down the issue and fix it. Knowing the correctusages and the desired result of each API is utmost important.

4.1.3.2 Incorrect Usages of System Resources

Similarly, there are usages rules to be followed that forms the best programmingpractices one should adhered to. It's especially true as per as the C/C++ languages areconcerned. It’s easy to forget or ignore such practices but the same may throw up somesurprises at later phase after you have shipped your product. This would add to theoverall software maintenance cost. For example it’s easy to forget to release a piece ofmemory before returning from a function or once the piece of memory is no longerneeded. Why bother about memory? You have enough memory :). This will result intomemory leaks, leading to performance degradation of your module. Sometimes, yourmodule could stop responding because of lack of required memory, leading to a failurewhile trying to fork a process.

4.1.3.3 Bad Software Programming Practices

The C language is like a carving knife: simple, sharp, and extremely useful in skilled hands.Like any sharp tool, C can injure people who don’t know how to handle it.

-Andrew Koenig, AT&T Bell Laboratories

Here are some bad programming practices that one should be aware of and pay closeattention during the coding and unit testing phase.

Forget to provide a user defined copy constructor and an assignment operator

for an object, leading to an undefined behavior of a program.

Forget to release a piece of memory after it’s no longer needed, leading to

memory leak and performance degradations.

Forget to release a piece of memory before returning from an erroneous

Scenario, leading to memory leak and performance degradations.


Writing to an array beyond its boundary Reading from an array beyond its

boundary, either static or dynamic.

Forget to lock a global variable using a semaphore before accessing it.

Forget to unlock a global variable using a semaphore after accessing it.

Usage of different data types, assignment and comparison performed in an

expression.

Forget to append a null character to the end of a string.

De-referencing a NULL pointer.

Returning a local variable’s value to a caller of a function.

Forget to check the return value and take an appropriate action, which could be

otherwise turned out to be a dangerous.

Forget to initializes variables inside a constructor of an object.

Forget to provide an appropriate destructor to release memory of an object.

Stack corruptions, leading to recursive function call and program crash.

Leaving a local variable un-initialized to a default value and using the same in the

code.

A Pointer has been checked against NULL but dereference it again at a later

portion of the same block of code.

A Pointer has been dereference before it’s checked against NULL

A variable has been assigned a value or pointer value, say returned from a

function, but the same variable has never been used anywhere in the code; thus

resulting into inefficient resource usages

Forget to check the negative value of variable before using it.

Incorrect usages of local value of variable returned by a function.

Incorrect amount of memory allocation (sizeof()) to a variable or array, leading to

undefined behavior and crashes of program.

Incorrect allocation of stack size to a program. Though your operating system

allocates a default stack size, one may be required to alter the stack size

depending on his program type e.g. a device driver.

Using pieces of memory after it has been freed.

Presence of dead code. Mistakenly, un-commenting a dead source line or

commenting an important source line into dead code, shall result into an

undefined behavior of a program.

Using an uninitialized variable may result into an undefined program behavior.

Improper usages of “delete” operator in case of an array or array [ ].

Forget to check the “Negative” ness of a value of a variable returned by function.

It can be dangerous as it can result into infinite loop, crashes, array corruption

etc.


Missing or forget to put or putting an unnecessary a “break” statement, leading

to unintentional code execution.

Putting an incompatible cast, leading to data lost.

Putting an “=” in instead of “==” comparison.

Putting an unintended “;” in after a while, if, for statement.

Not checking and putting of a divide by zero condition.

Improper usages of string manipulations, leading to buffer over flow.

Without using a coding style and naming convention for development.

Developers tends to use their own

Way of naming a variable, function without following standard or company

specific coding style. This creates difficulty in maintaining software due to

ambiguities.

Lack of a virtual destructor for a base class in case memory is allocated in derived

class.

And the list goes on……..

4.1.3.4 How to avoid software pitfalls

Your network element or a module could throw out some surprises after you hadshipped your product to your customer and at a later phase of the deployment. It may bebecome difficult to identify and fix the same, affecting end users services. To avoid anunexpected behavior of a telecom system and business loss, some of the common badsoftware programming practices mentioned above could be turned into a best practiceand incorporate it in your coding.

Example: Software DisasterAT&T Long Distance Network Collapse (1990) (Source: Web Reference)

Cost: 75 million phone calls missed, 200 thousand airline reservations lost.

Disaster: A single switch at one of AT&T’s 114 switching centers suffered a minormechanical problem and shut down the center. When the switching center has beenrestored, it sent a message to other switching centers, which in turn caused them to shutdown and brought down the entire AT&T network for 9 hours.

Root Cause Report:

The cause of the problem had come months before. In early December, technicians hadupgraded the software to speed processing of certain types of messages. Although theupgraded code had been rigorously tested, a one-line C-Program bug was inadvertentlyadded to the recovery software of each of the 114 switches in the network. The defectwas a C program that featured a “break” statement located within an “if “clause, that wasnested within a switch clause. Because of break statement, the program exited out of the


case statement entirely and began doing optional parameter update, leading to thedisaster.

There are other disasters happened because of software bug(s). Look for the root causesof those interesting history from online sources.

4.1.3.5 Static Code Analysis of Software

As a software engineer, you will spend rest of the time in hunting and correcting softwarebugs once your application is designed, developed and shipped to your customer. If youdevelop a software module without paying a close attention or without following goodprogramming practices, as mentioned above section, or even if you follow, you’re likelyto introduce software pitfalls without your knowledge. This will result into the lowsoftware quality, compliance issue, service unavailability, requiring more softwaremaintenance and so on. Following are the typical software bugs, at broad level, that onecould introduced in his module/code.

Software Concurrency issues such as deadlocks, race conditions and blocking call

misuse etc.

Software Performance Degradation problems due to memory leaks etc.

Software Crash-causing errors such as null pointer dereference, use-after-free,

double free, improper memory allocations and mismatched array new/delete etc.

Incorrect Program Behavior caused by dead code, uninitialized variables, Invalid

use of negative variables etc.

Improper Use of APIs with STL usage errors etc.

Security vulnerabilities due to buffer overflows, insufficient validation etc.

One may not be able to get rid of such software errors even though a very close codereviews are s performed. In order to catch and fix all the possible software bugs, arisingout of poor coding, and improve its quality before it’s shipped to customer, one candeploy a commercial third party software tool for the said task. Such a tool performs aninspection of the entire code during the compile time itself, hence called static, andproduces a pin pointing report showing all the possible bugs in your software. Such staticcode analyzer tool avoids the manual code inspection requirements and increases thedeveloper productivity by finding and helping them to fix defects faster rather thanleaving it till the runtime of the software either at lab or reported from the customer site.

4.1.4 Software Architecture and Software Organization

A fair knowledge about the Software Architecture and Software Organization will help inunderstanding a protocol stack and its associated protocols. Software Architecture refersto the different building blocks of a particular system or a network element. Softwareorganization refers to the arrangement of the identified or crafted building blocks. Forexample, consider the GSM Layer3 protocol stack. Here the layer3 consists of three sublayers or, say, building blocks (architecture) namely CC, MM and RR layer. And now see


how each of the mentioned layers are placed (organization) with respect to the otherone. CM layer is placed on top of the MM layer, which in turn is placed on top of the RRlayer. Each layer of the protocol stack uses the services of the other layer through serviceprimitives, which you have already studied in your course. For example, look at the OSI 7layers reference architecture and organization. Similarly, look at the architecture andorganization of the protocol stack of Gb interface used GPRS network system.

Use the service primitives as mentioned in the concerned 3GPP technical specification ofthe concerned protocol. You could develop a separate module for each of the layerhandling the functionalities as defined in the concerned specification.

Note that the target hardware/platform (e.g normal processor or a Digital SignalProcessor) being chosen will have an impact on your software architecture as well as thesoftware organization. One may choose to run an application on a normal processorwhereas another application may be designed to run on a digital signal processor (DSP).

One may also utilize the power of a multi-core processor while designing his/herapplication accordingly.

Having said the above, you may refer further a good reference book(s) on the variousaspects of software architecture and design in general.

4.1.5 System/Software Requirements Analysis

One must carefully gather the complete requirements, functionalities as well as therelated use cases of the network elements, modules etc., from the concerned 3GPPtechnical specifications. Other dependencies and requirements shall be also derived fromthe related technical specifications listed in the references section of a technicalspecification. Otherwise there would be requirements errors, project cost overheads,unexpected IOT issues, leading to an unsuccessful deployment of the concernednetwork element.

Some functionalities/non-implied requirements are left as the implementationdependent ones. Such requirements should be also captured carefully during thesoftware requirements and analysis phase.

4.1.6 Software Quality: Reliability, Scalability, Availability

One must emphasize on the software quality attributes during its design anddevelopment phase. Some runtime quality attributes are mentioned below.

4.1.6.1 Reliability

Reliability is the ability of a network element/system to continue operating in theexpected way over time. Your software must continue to work under all theenvironmental conditions/circumstances. For example the RF/Antenna system, BTS, BSC


and so on, of a mobile telecom network must be working as expected under all theradio/environmental conditions such as terrain, atop hill, rain, fog and so on.

To ensure this and maintain a user’s services, each of the mobile communicationtechnologies (GSM, GPRS and so on) provides its own error control, correction andrecovery mechanism that needs to be implemented properly as per the 3GPPspecifications.

4.1.6.2 Scalability

Your software must be designed, developed and flexible enough in order to provide andachieve scalability of a mobile communication network. For example, if an operator wantsto increase its network coverage to carry more traffic, it should be possible to do so,without software rework, through a system/software upgrade only.

4.1.6.3 Availability

Your software must be available to provide telecom services to users, say, 99.99% of thetime. It should not behave unpredictably or crashes upon receipt of an external triggeror event, requiring higher amount of maintenance and, affecting services to users.

There are other quality attributes such as Maintainability, Reusability and so on, that oneshould pay close attention during the software design and development phase.

4.1.7 Protocol and Protocol Stack development

You must have read about the stack data structure in your computer science course. Astack is used to organize or stores anything, preferably from the same group, one top onanother one. Remember the TCP/IP protocol suite?

Similarly, in the world of wireless or data communication protocols too, a group ofprotocols can be organized together to form a protocol stack. Each protocol in aprotocol stack performs its defined functions and responsibilities as described in theconcerned 3GPP TS.

4.1.7.1 Protocol Layer development using Service Primitives

A protocol in a protocol stack uses the services from the lower one in the stack. Note thata protocol or a protocol stack is implemented for communicating between two differentnetwork elements, e.g BSC and SGSN. A protocol layer of a protocol stack in a networkelement, say BSC, communicates with the peer layer in the other network element, saySGSN, in the form of service primitives. These primitives are generally called REQuest,INDication, RESponse and CONfirm.


A sample services primitive found in a 3GPP technical specification is shown below.

Fig: 4.6 Protocol Layer Services PrimitivesSource: TS 48.018. Reproduced with permission from 3GPP.

You must have studied about the above primitives during your graduate course. This ishow protocol layers communicate with each other.

A protocol layer may send the above service primitives in the form of a protocol data unit(PDU) in order to carry or exchange signaling as well as user traffic between two networkelements. Refer the concerned 3GPP technical specification for the general structure of aPDU.

The communication mechanism used between the layers of a protocol stackimplemented in a particular network element is an implementation dependent one.Generally, an inter-process communication (IPC) or socket mechanism is used for thesame purpose, assuming that each process does the functions of a particular protocollayer.

As mentioned earlier, a protocol stack is also known or used to call, as interface. Oneexample is the Gb interface defined between the BSC and a SGSN in a GPRS network. TheGb interface, as mentioned earlier, contains two protocol layers, namely BSSGP on top ofthe NS layer.


4.1.7.2 Protocol Layer development using State Machine

A protocol layer may also contain state machine architecture for its various tasks to beperformed in its different states. Remember the different states of TCP? For example,consider the RRC protocol layer of a UMTS and LTE network. In case of UMTS the RRCprotocol has 5 different states whereas in case of LTE, the RRC protocol has only 2 states.For details about the various service primitives, different state machines and otherfunctionalities, such as timers, counters, alarms, system parameters and so on, of aprotocol layer, refer the concerned 3GPP TS. Interpretation and implementation of thesevarious provisions and logical structures mentioned in the concerned 3GPP TS is crucialin order to have a successful inter-operability at a later phase with a network elementfrom a different vendor.

In order to implement a protocol layer state machine, one may would like to use switch –case statement or function pointer tables as provided by C/C++ languages.

Choice of the development platform to be used for a protocol layer development is animplementation dependent one. Someone may use the legacy UNIX, Windows platformwhereas others may use embedded or proprietary system platform.

4.1.7.3 Protocol Layer development using message passing

A Protocol layer may be implemented in a network element in such a way that it passesinformation, either signaling or data, to its peer layer in another network element in theform of a predefined message format only. For example, consider the RLC layer messagesexchanged between the MS and BSC overt the air interface. Such a message, eithersignaling or data, could be sent in a segmented way by the sender, if the informationcannot be accommodated in a single message. The receiving network element does thebuffering. Once the entire segmented messages are processed and re-assembled, thereceiving network entity may perform the protocol conversion and forward the completemessage to another network entity in the form of a PDU only.

Refer the concerned 3GPP technical specification for all the messages, both signaling anddata, of a protocol exchanged between two network entities.

4.1.8 Software Profiling, tools and performance Improvement

One important aspect of a mobile communication network/system is its performance.Overall, the performance could be in terms of the call per seconds (CPS) that acommunication network/system can process. For example, consider a 70 CPS that thecall-processing module can process. A call-processing event may involve executions ofseveral algorithms in order to assign the necessary resources either successfully or failurein allocation.

In order to improve the performance, say, the CPS, of a mobile communicationnetwork/system, you can start working on the concerned call-processing module. To


assist you towards improving the performance of your call-processing module, you canperform a profiling of the concerned module. In this case, you can take the help of thetools provided by the chosen platform. For example, on the UNIX platform, you can usethe tool called gprof in order to perform a profiling of your call-processing module. Seethe UNIX man pages for the usages of gprof.

A Profiling allows one to learn where a program spent its most of time and whichfunctions was called by which other functions during its runtime. This vital informationcan show you which pieces of your call-processing module are slower than you expected,and might be the candidates for rewriting your code (for example, by including anefficient loop) to make your call-processing module execute faster and hence improvethe CPS. A Profiling data can also tell you which functions your call-processing moduleare being called more or less often than you expected.

Another useful tool available on UNIX platform is the truss, to trace various system callscalled by a particular module/process during runtime. Look at the UNIX man page formore details on it.

4.2 Summary

Now that you know the various development platforms, both hardware and software,which can be used to develop a mobile communication, network elements and system.Various platforms and its important knowledge areas have been introduced to youbriefly. In fact, leaving aside the 3GPP protocols/stacks and its specificationsimplementation, each platform, both Hardware + software, domain itself is a largeenough for one to put focus for his career purposes. This is especially true forcommunication system designed based on embedded/multicore system/platform.

In an embedded platform, one has to put an enormous effort (in terms of coding+testing) to make an embedded system board operational and stable enough beforestart using it for the development of 3GPP protocols/stacks and other applicationsimplementations on top it.

If you choose to run, say Linux, on an embedded system board/processor, it may not beready yet and in order to make it, you will be required to develop various drivers/utilitiessoftware, collectively known as the Board Support Package (BSP) that generally,otherwise, comes with legacy PC or UNIX/Linux platforms.

So there could be two teams working in parallel: one, the application domain, for thedevelopment of 3GPP protocol/stacks implementations and another team, the platformdomain, for bringing up of the embedded system board into the working state throughwell tested Board Support Package (BSP). Accordingly, you can select a particular areaand jumpstart your carrier.


Test yourself

5.1 Test your knowledge

Here is a potpourri of questions on various aspects of mobile communication protocols.Attempt and test your knowledge!

(1) Which layer provides a reliable logical link between MS and BSS in GPRS network?

(2) Which layer provides a multiplexing of Mobile Stations onto a physical channel inGPRS network?

(3) Which layer provides a reliable logical link between MS and SGSN in GPRS network?

(4) Which protocol is used to carry user data between SGSN and GGSN?

(5) What are the different states of a Mobile station in GSM, GPRS, UMTS and LTE?

(6) Who performs the ciphering function in case of GSM, GPRS and UMTS call?

(7) Why GSM and GPRS cannot exist on the same TSL /channel?

(8) How Packet Traffic channels and control channels are multiplexed in GPRS protocol?

How a mobile identifies what type of channel is being used in a particular block?

(9) How to detect any L1 and L2 layer problems problem observed on Air- Interface?

(10) What is Interleaving and IR?

(11) What are logical channels and physical channels?

(12) Which channels are used to deliver a SMS to a MS?

(13) What is a BER and BEP?

(14) What are different ways to establish TBF in GPRS network?

(15) What is a contention resolution?

(16) Name the radio access method used in case of GSM, UMTS and LTE. (17)

What is the purpose of the E-bit in a RLC header?

5


(18) What is a USF granularity?

(19) In which 3GPP release, FANR feature was introduced? What will the behavior of MS ifFANR bit set in the IMM. ASSIGN MSG? What is the benefit of using it?

(20) What is the purpose of Address control bit of the RLC header? Is it OK to set AC=1and TFI=31?

(21) What is a location area, routing area and tracking area update?

(22) Which protocols carries user data and signaling between BSC and SGSN?

(23) What is a MSRAC? Is MSRAC containing both GSM1800 and GSM1900 band a validone? If not, why?

(24) Can you use the same TFI in UL +DL TBF?

(25) What happens during GPRS ATTACH and PDP CONTEXT ACTIVATION procedures?

(26) How does a SMS is delivered if a MS in Packet Transfer Mode?

(27) Which coding scheme is used in GPRS network for transmitting RLC/MAC controlblock and why?

(28) What do you mean by puncturing and why is it required?

(29) What are Transaction Identifier (TI) and Skip Indicator (SI) in GSM L3 protocol stack?Why they are used and why? How will do identify whether a call is Mobile terminated orMobile originated one?

(30) Which channel is considered is the lighthouse of a BTS?

(31) What is the purpose of Protocol discriminator (PD) and Message Discriminator inthe GSM L3 protocol stack? Why SMS and Supplementary services have the same PD asCall Control messages?

(32) What is a BSSAP and DTAP message in GSM L3 protocol stack? Name the DTAPmessages that are processed by BSC.

(33) What is a handover? Who decide it? What are the different types of handover inGSM/GPRS and UMTS?

(34) What is a paging group in GSM? Why is it required?

(35) What are the purposes of TLLI, USF, TFI in a GPRS protocol?

(36) How does a mobile know in which RLC block to transmit a in GPRS call?


(37) How does the Mobile indicate to the network whether a RLC block has been receivedcorrectly or not in a GPRS call?

(38) What is a polling bit and why it’s required in a GPRS call?

(39) What is a Countdown value and Final Block Indicator bit used in GPRS protocol?

(40) What is the purpose of the timer T3192 and T3193?

(41) What is the purpose of the timer T3212?

(42) What are the different classes of Mobile station in a GPRS network?

(43) What are the different Network control mode and operation mode?

(44) What is a Gs interface and why is it needed?

(45) What is an in-band and out of band signaling?


The Last Note: Where do you want to go next…

Now that you have gone through and have been introduced to the world of wirelessmobile communication network and its various network elements with a gradualtransition to understanding the various stages for a network element design,development, deployment and its further operation and maintenance.

As per as the wireless mobile communication network software development isconcerned, one can chose to start his career either in the Mobile Handset or BSS (RAN-Radio Access Network) or core network area, at the macro level. Then he/she can furtherrefine the area of interest such as Layer1, Layer2 or Layer3 and so on, within theparticular network element.

There are other areas as mentioned in the section #1, at the beginning of this book,where one can chose to start his career in the mobile telecommunications domain.

You have been also introduced to the various development platforms, be it a legacysystem or embedded or multicore based system. You have gone through the hardwareas well as the software platforms available along with the various other aspects that oneneed to pay close attention during the software design, development, coding andvalidation phase.

Regardless of the area chosen, it’s hoped that the materials presented in this book willprovide the necessary foundational background towards your unexplored domain.Having said this, the various aspects and areas towards the development anddeployment of a mobile communication system that I had shared above are not the endbut are just a start for one to pursue further his/her career in the mobile communicationdomain.

So, where do you want to go next?

A new dawn has started! Go on and do it. You’re hired!

“You don’t have to be great to start, but you have to start to be great”.

-Zig Ziglar

6


Appendix

7.1 Useful Links

1. 3GPP site (www.3gpp.org)

2. Download 3GPP Specifications

(http://www.3gpp.org/specifications/specification-numbering

3. Keywords and Acronym

(http://www.3gpp.org/technologies/keywords-acronyms)

4. Vocabulary for 3GPP Specifications

(TR 21.905 "Vocabulary for 3GPP Specifications)

5. Download 3GPP specs

(http://www.3gpp.org/DynaReport/XX-series.htm)

6. About CSN encoding rules

(http://www.csn1.info)

7. About ASN encoding rules

(www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf.)

8. Multicore Association site: www.multicore-association.org

7


About the Author

The author had graduated in the Bachelor of Computer Science and Engineering from the JorhatEngineering College, Assam, India, in the year 1996. He began his career as an Engineer(Telemetry) at GAIL, a public sector entity.

The author worked there for 4 years, including design and development, in the area of SCADAsystem for gas pipeline. Then he joined a Gurgaon based US Communication software services aswell as product development MNC ,Aricent Technologies (www.aricent.com), formerly known asHughes Software Systems, where he started working in the area of wireless mobilecommunication domain software R&D. He worked there for the last 12 years (2001 to 2013), bothindividual contributor and lead role, in software R&D area, in the RAN and Core Network domain.

He was also sent on foreign/onsite assignments for integration and troubleshooting of the justcommissioned satellite based GSM mobile communication system. The author had left the privatecorporate and telecom domain software R&D sector; again joined, specializing in the ITmanagement area, in a public sector entity in the year 2013 at Dibrugarh, close to his home town,Assam. He hails from the Jorhat district of Assam, India.

For feedback, improvement or any other comments, the author may be contacted by using themessage sending facilities available in the LinkedIn profile.

LinkedIn: in.linkedin.com/pub/rajib-taid/27/b08/b25/

8

Documents

Wirless-Mobile-Communication-System-Development