Product reportGSM Call Service

1DT054 Project CS

Ebby Wiselyn JeyapaulEgemen TaskinErik Grafström

Fartash M. NejadFredrik Pasanen

Max MorénMohammadreza Taghilu

Moritz RogalliPraveenkumar Bhadrapur

February 16, 2012

Abstract

Developing and testing new GSM services requires use of proprietary hardwareand software which can be tedious due to inherent high complexity and cost.

The product GSM call service developed by nine master students at UppsalaUniversity provides a vendor independent, low cost, IP based solution accordingto 3GPP specifications. The system designed and developed using Erlang/OTPis a framework capable of calls, subscriber management and additional GSMservices.

The finished product offers developers a testing environment to build and ex-periment with new and existing GSM services.

Glossary

Abis Abis interface, RSLACM Addressing Complete MessageAGCH Access Grant ChannelAN Access NetworkANM Answer MessageAPI Application Programming InterfaceATT IMSI AttachBC Bearer CapabilityBCCH Broadcast Control ChannelBNT B-Number TypeBO B-number OriginBSC Base Station ControllerBSS Base Station SubsystemBSSAP Base Station System Application PartBSSMAP Base Station System Management Application sub-PartBTS Base Transceiver StationCC Connection ConfirmCGI Common Gateway InterfaceCI Cell IdentifierCIC Circuit Identification CodeCM Connection ManagementCN Core NetworkCPG Call ProgressingCR Connection RequestCS Connection ServiceDETS Disk based Erlang Term StorageDLR Destination Local ReferenceDPC Destination Point CodeDTAP Direct Transfer Application PartDT1 Data form 1DT2 Data form 2E1/TDM E1/Time Division MultiplexingETS Erlang Term StorageFSM Finite State MachineG-MSC Gateway MSCGMSC Gateway MSCGSM Global System for Mobile CommunicationHLR Home Location Register

1

IAM Initial Address MessageIMSI International Mobile Subscriber IdentityIP Internet ProtocolIPA ip.accessISUP ISDN User PartIT Inactivity Test/TimerLAI Location Area IdentifierLAPm Link Access Procedure for ModemsMA Mobile ArtsMAP Mobile Application PartME Mobile EquipmentMG Media GatewayMGC Media Gateway controllerMGCP Media Gateway Control ProtocolMM Mobility ManagementM-MGW Mobile Media GatewayMNRF Mobile Not Reachable FlagMO Mobile OriginatingMS Mobile StationMSC Mobile-service Switching CentreMSISDN Mobile Subscriber Integrated Services Digital Network NumberMSRN Mobile Station Roaming NumberMT Mobile TerminatingMUS Mobile User ServiceNAPI Numbering Plan IdentifierNDC National Destination CodeNITB Network In The BoxNP Numbering PlanOBA Origin for B-Number AnalysisOPC Originating Point CodeOTP Open Telecom PlatformPC Point CodesPID Process IdentifierPLMN Public Land Mobile NetworkPS Packet SwitchingPSTN Public Switch Telephone NetworkREL ReleaseRLC Release CompleteRLSD ReleasedRR Radio ResourceRSL Radio Signalling LinkRTP Real Time ProtocolRTP-TA RTP Termination AgentSABM Set Asynchronous Balanced ModeSASL System Application Support LibrariesSLR Source Local ReferenceSS7 Signalling System 7SCCP Signalling Connection Control PartSCN Switched Circuit NetworkSIM Subscriber Identity Module

2

SLR Source Local ReferenceTCH Traffic ChannelTCP/IP Transmission Control Protocol/Internet ProtocolT-MSC Terminating MSCTM Transit ModuleTMSI Temporary Mobile Subscriber IdentityTTM Time To MarketV-MSC Visiting MSCVLR Visitor Location RegisterVTY Virtual Terminal2G Second Generation3GPP The 3rd Generation Partnership Project

3

Contents

1 Introduction 62 Preliminaries 7

2.1 GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.1 Access Network . . . . . . . . . . . . . . . . . . . . . . . . 82.1.2 Core Network . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.3 Call procedures . . . . . . . . . . . . . . . . . . . . . . . . 102.1.4 Location procedures . . . . . . . . . . . . . . . . . . . . . 102.1.5 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Development environment . . . . . . . . . . . . . . . . . . . . . . 123 Product description 13

3.1 Problem description . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 GSM call service . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3 Reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.3.1 nanoBTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.3.2 OpenBSC . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3.3 MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3.4 Media Gateway . . . . . . . . . . . . . . . . . . . . . . . . 15

4 System description 164.1 Design concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1.1 Signalling/Interfaces . . . . . . . . . . . . . . . . . . . . . 174.1.2 Application platform . . . . . . . . . . . . . . . . . . . . . 174.1.3 Supervision . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.2.1 Transmission Control Protocol/Internet Protocol server . 184.2.2 Mobile User Service (MUS) . . . . . . . . . . . . . . . . . 194.2.3 Home Location Register . . . . . . . . . . . . . . . . . . . 204.2.4 Visitor Location Register . . . . . . . . . . . . . . . . . . 204.2.5 Application platform . . . . . . . . . . . . . . . . . . . . . 224.2.6 Tabman . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.2.7 Supervision structure . . . . . . . . . . . . . . . . . . . . 28

4.3 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.3.1 Location procedures . . . . . . . . . . . . . . . . . . . . . 284.3.2 Call handling . . . . . . . . . . . . . . . . . . . . . . . . . 324.3.3 Media handling . . . . . . . . . . . . . . . . . . . . . . . . 374.3.4 Connection Service . . . . . . . . . . . . . . . . . . . . . . 41

5 Evaluation and testing 445.1 Testing procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.1.1 Performance testing . . . . . . . . . . . . . . . . . . . . . 445.1.2 Unit testing . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4

5.1.3 System testing . . . . . . . . . . . . . . . . . . . . . . . . 455.2 Known issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.2.1 Session invalidation on TCP disconnect . . . . . . . . . . 455.2.2 Disconnect race condition . . . . . . . . . . . . . . . . . . 455.2.3 VLR robustness . . . . . . . . . . . . . . . . . . . . . . . 455.2.4 MG and MGC robustness . . . . . . . . . . . . . . . . . . 46

6 Related work 476.1 Existing products . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.1.1 OpenBSC . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.1.2 OpenMSC . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

7 Conclusion and future work 487.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

7.2.1 Conference calls . . . . . . . . . . . . . . . . . . . . . . . 487.2.2 Call waiting and call deflection . . . . . . . . . . . . . . . 497.2.3 GPRS/EDGE support . . . . . . . . . . . . . . . . . . . . 497.2.4 3G support . . . . . . . . . . . . . . . . . . . . . . . . . . 497.2.5 Multiple BTS/BSCs per MSC . . . . . . . . . . . . . . . . 497.2.6 External ISUP interface . . . . . . . . . . . . . . . . . . . 497.2.7 Media Gateway transcoding . . . . . . . . . . . . . . . . . 497.2.8 MA HLR . . . . . . . . . . . . . . . . . . . . . . . . . . . 507.2.9 SMS support . . . . . . . . . . . . . . . . . . . . . . . . . 507.2.10 Tones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

8 Appendix A: Installation instructions 538.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538.3 Installing the call service . . . . . . . . . . . . . . . . . . . . . . . 538.4 Installing the media gateway . . . . . . . . . . . . . . . . . . . . 548.5 Install OpenBSC . . . . . . . . . . . . . . . . . . . . . . . . . . . 548.6 Configure nanoBTS . . . . . . . . . . . . . . . . . . . . . . . . . 548.7 Starting the system . . . . . . . . . . . . . . . . . . . . . . . . . . 54

9 Appendix B: Maintenance instructions 559.1 Managing circuits . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

9.1.1 Using the launch module . . . . . . . . . . . . . . . . . . 559.1.2 Adding terminations in the MG . . . . . . . . . . . . . . . 559.1.3 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

10 Appendix C: Test cases 57

5

Chapter 1

Introduction

The project idea was to implement a Global System for Mobile Communica-tion (GSM) Call Service which can provide a foundation for experimentationand research purposes in GSM-networks for GSM voice calls and location man-agement.

The project was done in collaboration with Mobile Arts in the fall of 2011and it involved programming in Erlang. The development methodology usedwas Scrum [13, 18] which is an agile software development methodology. Theproject methodology and working environment is covered in the supplementarycourse report [22].

The challenge of the project was to develop a soft real-time system that canbe used in a portable low-cost way instead of large expensive systems that areusually associated with GSM services.

6

Chapter 2

Preliminaries

This chapter explains the GSM network entities, protocols and interworkingrequired to handle GSM subscribers and GSM calls.

The intention of this overview is to cover the scope of the product, not thecomplete GSM specifications. For further readings, see Bibliography.

2.1 GSM

The 3GPP specifications define different network entities, protocols and theirinterworking. As seen in Figure 2.1 a GSM system consists of Mobile Stations2.1.1, an Access Network (AN) 2.1.1 and a Core Network (CN) 2.1.2. Thisenables a subscriber to call another subscriber with the use of its phone number,or in technical terms its Mobile Subscriber Integrated Services Digital NetworkNumber (MSISDN). Call setup is covered in more detail in section 2.1.3.

7

Figure 2.1: GSM overview.

2.1.1 Access Network

In a general GSM system the Access Network (AN) consists of the Base StationSubsystem (BSS), Mobile Station (MS) and Media Gateway (MG).

Mobile Station

Mobile Station (MS) refers to the subscriber equipment in a Public Land Mo-bile Network (PLMN). Mobile Equipment (ME) and Subscriber Identity Mod-ule (SIM) are subcomponents of the MS. The ME is the physical hardware,consisting of transceivers, protocol handlers and a user interface. The SIM con-tains the unique International Mobile Subscriber Identity (IMSI) which is usedto identify a subscriber within the network.

Base Station Subsystem

The Base Station Subsystem (BSS) refers to the network entities between theMS and the core network. It consists of one or more Base Transceiver Station(BTS) controlled by a Base Station Controller (BSC). The BTS relays radiosignalling from the MS on the Um interface to its controller on the Abis interface.The BSC forwards the signalling over the A interface to its controller in the CN,the Mobile-service Switching Centre (MSC).

8

Base Station Controller

The Base Station Controller (BSC) controls a set of BTSs which implies handlingsubscribers and common radio procedures. The BSC relays service requests tothe core network and handles the radio aspect of the subscriber.

Base Transceiver Station

The Base Transceiver Station (BTS) is the radio transceiver which handles MSsin one radio area. The hardware consists of the antennas and digital signalprocessors. The BTS relays signalling to the BSC and the media to the CN.

2.1.2 Core Network

Mobile-service Switching Centre

The Mobile-service Switching Centre (MSC) is the main routing entity in theCore Network (CN). It handles the A and E interface, which is used for callset-up and subscriber management. An MSC acts differently depending on therequested service, the roles are covered in 2.1.3.

The MSC creates circuits on which the signalling and media is carried. TheMSC controls several BSCs and manages subscribers for a certain geographicalarea which is called the MSC area.

Visiting MSC (V-MSC) is the MSC module which handles the mobile originating(calling party) call service. TheTerminating MSC (T-MSC) module handlesmobile terminating (called party) call service, and the Gateway MSC (G-MSC)module handles the routing of incoming calls to a terminating MSC.

Home Location Register

The Home Location Register (HLR) is the central subscriber database in theCN. The HLR stores subscriber information such as the subscriber directorynumber also called Mobile Subscriber Integrated Services Digital Network Num-ber (MSISDN), subscriber location and subscriber service level.

Visitor Location Register

To reduce the load on the HLR, every MSC uses a Visitor Location Register(VLR) to store data about subscribers for a certain MSC area. The MSC pullssubscriber data from the HLR when a subscriber attaches and purges the datawhen the subscriber leaves the MSC area. The VLR is used for core servicessuch as call procedures (see 2.1.3) and location procedures (see 2.1.4).

9

2.1.3 Call procedures

The following sections describe a call set-up with the use of originating, gatewayand terminating MSC roles.

Originating

If a Visiting MSC (V-MSC) receives a service request from an MS indicatinga call service the V-MSC will act as an originating exchange in the CN. TheMSC will check the current state of the subscriber in the VLR to determine ifthe subscriber is allowed to make a call. If the VLR checks are OK, the theMSC will send a call request to the G-MSC.

Gateway

The Gateway MSC (G-MSC) is responsible for routing incoming calls to a ter-minating MSC. It will interrogate the HLR to find the location of the calledsubscriber and forward the call request to that terminating exchange.

Terminating

The Terminating MSC (T-MSC) will receive the call request and check the calledsubscriber state in its VLR. If the VLR checks are OK the subscriber will benotified of the call. At this point the circuit has been set up and subsequentmessages will be passed over the circuit and released when either party hangsup.

2.1.4 Location procedures

When an MS is powered on, it will try to associate itself with the network. TheVLR will interrogate the HLR to determine if the subscriber is allowed servicesin the network. When the subscriber is associated it is assumed to periodicallyreconfirm the association and explicitly tell the CN when it is powered down.The VLR and HLR tracks the subscribers, purge unconfirmed subscribers andpropagate information when subscribers roam between networks or areas.

2.1.5 Interfaces

As seen in Figure 2.2, the AN and CN interworking is carried out over a coupleof interfaces using service specific protocols. This section contains an overviewof those protocols, lower layer protocols such as Signalling System 7 (SS7) andTransmission Control Protocol/Internet Protocol (TCP/IP) are omitted.

10

Figure 2.2: Signalling protocol stack over A and E Interface

Abis

The Radio Signalling Link (RSL) is used between the BTS and BSC over theAbis interface. The protocol consists of radio link establishment and manage-ment procedures. [2]

A

There are several protocols on the A interface which are used between the BSCand MSC. Signalling Connection Control Part (SCCP) is the lower layer pro-tocol which provides connection oriented and connectionless services. [15] Thetop layer protocols which use SCCP are Base Station System Management Ap-plication sub-Part (BSSMAP) and Direct Transfer Application Part (DTAP).

The BSSMAP protocol defines procedures for managing radio resources, circuits,paging and handover. [7]

The DTAP protocol defines procedures for Mobility Management, Call Controland Radio Resources. [1] Most of the common GSM services such as locationand call procedures are defined within DTAP.

B

Interrogation of the VLR is done over the B interface. The main protocol isMobile Application Part (MAP) which covers signalling for subscriber man-agement. [6] The MSC interrogates the VLR during location and call proce-dures. [3, 4]

C

MAP is used on the C interface for routing calls. The G-MSC interrogates theHLR to find out where the called party resides. Calls from and to the PLMNfrom Public Switch Telephone Network (PSTN) are also routed through theG-MSC.

11

D

MAP is used on the D interface for subscriber data exchange between a VLRand HLR in location procedures.

E

The E interface uses ISDN User Part (ISUP) for connecting calls between acalling (originating) and called (terminating) party. [14]

2.2 Development environment

Erlang/OTP is a development environment for building distributed real-timehigh availability systems with a short Time To Market (TTM). In Erlang/OTPthere are design principles that have been thoroughly tested and are easy toimplement. The following were the design principles used:

application Combining different modules into a single application.

gen_fsm Finite State Machine (FSM).

gen_server A server in a client-server relation.

supervisor Supervises other processes and restarts them if they terminate inan abnormal way.

12

Chapter 3

Product description

3.1 Problem description

The project meant to extend existing work by Mobile Arts and implement anextensible testing framework for GSM services. The framework was to supportMobile Originating (MO) Mobile Terminating (MT) calls and location servicesnatively, and make integration and evaluation of additional GSM componentspossible.

More details on which components could be reused is covered in section 3.3.

3.2 GSM call service

The GSM call service delivers call functionality according to The 3rd GenerationPartnership Project (3GPP) specifications.

All-IP

• The Real Time Protocol (RTP)-based voice circuit emulation togetherwith IP based nanoBTS eliminates the need for expensive E1/Time Divi-sion Multiplexing (E1/TDM) hardware.

Subscriber and location management

• Easy to attach and detach regular MSs once SIM card IMSI is known.

• Only registered subscribers can access the network making it safe for useas it does not disrupt service for others in the area.

Key features

• Designed as a framework for the possibility of adding features. Other GSMservices such as SMS can be added to the developed GSM call service with

13

little modifications. It allows developers to test the behaviour of new GSMservices or products acting as a test environment. See future work 7.2 formore examples of possible future features.

• Concurrent voice calls and service use is supported. Erlang’s concurrencyproperty has been used to provide this feature.

• Easily deployable. It needs only a nanoBTS and a computer with a work-ing Linux installation working Erlang environment to run. A nanoBTS iseasily configured, as well as GSM call service (see 8 for installation andconfiguration instructions).

3.3 Reuse

Figure 3.1: Reuse overview

Figure 3.1 shows the components which were reused as-is, components whichexisted but could not be used, components which were enhanced to support callservice requirements and components that were developed.

3.3.1 nanoBTS

For the radio connection between the BSC and the MS an ip.access nanoBTS [19]is used, a 2G picocell. It encapsulates the Abis protocol in Internet Protocol (IP)

14

packets and media into RTP. The nanoBTS [19] supports up to 7 media circuitconnections at the same time. This allows us to have 3 simultaneous calls ifboth ends are associated with the same BTS or 7 simultaneous calls if only oneside of each call was associated with the nanoBTS.

3.3.2 OpenBSC

OpenBSC [11] is a Base Station Controller (BSC) implementation. It imple-ments a subset of BSC-, MSC- and HLR-functionality over the Abis and Ainterface. In its Network In The Box (NITB) mode it provides standaloneGSM network functionality. In GSM call service openBSC is used in its BSC-only mode as a standalone component that acts only as a Base Station Con-troller (BSC) and media relay.

It communicates with the MSC application using GSM over IP on the A inter-face.

Real Time Protocol bridge

OpenBSC does not support media handling as required for the GSM call service.It was therefore extended with a simple media relay using the existing RTPproxy code for handovers.

The relay forwards the media coming in from the BTS to the first MG in theGSM core network.

3.3.3 MSC

Work from previous Project CS instances and master theses at Mobile Arts wasreused for some components.

The existing GSM codecs could in large part be used as-is. Additional messagetypes were required and the IPA and SCCP codecs were rewritten. The newIPA and SCCP codecs were based on work by the Osmocom project [23].

VLR

The VLR written during the previous year’s Project CS did not provide theprocedural features that the project required and its design made extending itdifficult. Because of this, a new one was written using a more modular approach.

3.3.4 Media Gateway

Henrik Back and Ming Zhao’s MG master thesis work Voice mail system for IPMultimedia Subsystem [12] was reused and modified to suit the requirements ofcall service.

15

Chapter 4

System description

This section describes the technical details of the GSM call service. Section 4.1describes the goal of the design and the resulting design decisions, section 4.2discusses the system’s components and section 4.3 describes how componentsinteract for location handling, call handling and media handling.

4.1 Design concepts

Figure 4.1: System overview

The goal for the design phase of the project was to build an extensible andmodular platform. The platform should offer a modular and flexible structurethat would enable future developers to extend the system and use it to developand debug services for GSM networks.

16

4.1.1 Signalling/Interfaces

The signalling taking place within the MUS is implemented in the form of workerFinite State Machines. This design was chosen because the roles given in thespecifications are defined in terms of states and transitions maps directly intoErlang/OTP gen_fsm.

The entity that sits closest to the external interfaces (A and E) is the MUScore module. This server module decides if anything coming in from the outsideworld belongs to an existing session or if one needs to be created. When a newsession is created, the module instantiates the appropriate FSM workers andinitializes internal records with state information.

The information pertaining to sessions is kept and managed by the MUS frame-work in the session store. This way the session workers can act as isolatedentities as if their session is the only one in the system. The process of rout-ing packets to the correct FSM instances within the session is abstracted in aanother per-session module; the MUS controller.

When transmitting and receiving messages, the workers themselves never com-municate directly on the external interfaces. They instead send their informa-tion back through their instance of MUS controller, which then decides wherethe message is headed using available information it has about the session.This allows the workers to stay agnostic about their routes towards the mobilestations and the network, at the cost of adding some complexity to the MUScontroller.

4.1.2 Application platform

Components which can be used as applications by other GSM services aregrouped together, so that reuse of these components is possible. The Appli-cation platform consists of Session Store, Transit Module, RTP terminationAgent, Connection Service, MGC (H.248 client) and the Operations and Main-tenance components. Each of the components are described in detail in section4.2.

4.1.3 Supervision

If a crash occurs somewhere in the system, it should be handled in an isolatedmanner to not affect the other ongoing services. A common design pattern usedin Erlang systems is to use a supervision hierarchy.

For the GSM call service, we use such a scheme to allow a call or other serviceto crash without taking anything else down with it. Combined with processmonitoring, resources pertaining to the crashed service is cleaned up by modulesfurther up in the hierarchy as they are notified when crashes occur.

17

4.2 Components

Figure 4.2: System architecture

GSM call service architecture is detailed in Figure 4.2. The BSS consists ofa nanoBTS [19] and OpenBSC [11], which handles the radio communicationwith the user’s MS. The Mobile User Service (MUS) handles signalling; theapplication platform offers services like circuit switching and media control forthe MUS. The Application platform components provide services which canbe re-used by other GSM services. The MG together with the RTP-bridgein OpenBSC handles audio streaming. The VLR and the HLR are used foruser management and for routing, location and access requests by the MUS.Design considerations and decision reasoning has been described in respectivesub-sections.

4.2.1 Transmission Control Protocol/Internet Protocol server

The TCP/IP server maintains a Transmission Control Protocol/Internet Pro-tocol (TCP/IP) connection to the BSC which is the A interface. The messagesare passed on the A interface as binary blobs from the BSC to the MSC, andvice versa.

18

4.2.2 Mobile User Service (MUS)

Figure 4.3: MUS component.

MUS Core

The MUS Core performs the decoding of IP packets using the codecs library.The decoding converts the binary IP packet carrying the level-3 message payloadto Erlang message format. It also associates every incoming message to eitheran existing MUS session or a new MUS session.

An MUS session contains the session information for service requests that arehandled by the MUS. The session information keys are listed below.

Source Local Reference (SLR) A reference number which is generated andused by the local node to identify the connection section after the connec-tion section is set up.

Destination Local Reference (DLR) A reference number which, in outgo-ing messages, has been allocated to the connection section by the remotenode

Circuit Identification Code (CIC) Used to identify a voice circuit.

International Mobile Subscriber Identity (IMSI) A unique identificationassociated with all GSM network mobile phone users. It is stored as a 64bit field in the SIM inside the phone and is sent by the phone to thenetwork

19

Temporary Mobile Subscriber Identity (TMSI) The identity that is mostcommonly sent between the mobile and the network. TMSI is randomlyassigned by the VLR to every mobile in the area.

The session association is done by matching keys and values to ongoing sessions.If a key is matched, the message is sent to the MUS Controller associated withthe matching session. Otherwise a new session is created and an MUS Controlleris started and associated with that session. The MUS Core also handles straymessages, that is, received messages that is not associated with a session butshould normally be.

Workers

The originating call and resource handling is handled by the MOWorker [5,7,14].The terminating call is handled by the MT Worker [5, 7, 14], and the gatewayfunctionality is handled by the gateway worker [14].

MUS Controller

The MUS Controller handles the creation of worker processes for every requestand routes the messages received from the MUS Core to the correct worker. Itencodes Erlang messages going to the BSC into a binary IP packet and sendsit to the TCP/IP Server. It also handles the release of the relevant SCCPconnection when the session is done [10].

Circuit management

The MUS requests resource like communication channels and circuits for al-location, and manages their deallocation after use. This is done by the MUSworkers.

4.2.3 Home Location Register

The HLR handles the basic MAP signalling on the C and D interfaces forlocation and call procedures, refer 2.1.3 and 4.3 for further information. Itcontains a operator defined subscriber white-listing which is a mapping betweenan IMSI with an MSISDN. The current HLR implementation is a small Erlangmodule pending replacement by the fully featured Mobile Arts (MA) HLR.

4.2.4 Visitor Location Register

The VLR is the local subscriber database tied to one MSC.

The VLR is implemented as an gen_server which handles the B and D interfaces.The VLR stores the following data for each associated subscriber in a DETSbackend.

20

IMSIKey identifier

TMSIKey identifier

Last TMSI updateLast time the TMSI was reallocated to decide when to update the TMSIagain

Location Area Identifier (LAI)The current location area the MS is in

DetachedIs set true when an MS detaches or is inactive for a period of time

Location info confirmed in HLRWhether or not the HLR has confirmed knowledge about that the MS iscurrently residing in the area of responsibility of this VLR

Subscriber data confirmed by HLRWhether the HLR has confirmed the subscriber information

Confirmed by radioWhether the subscriber data was confirmed by the MS

Mobile Not Reachable Flag (MNRF)Set when the MS is not reachable

MSISDNThe subscriber’s number for displaying purposes during a call

The VLR provides its services via the following gen_fsm workers, refer 4.3.1 formore information about the procedures.

vlr_locFSM subset implementation of the Update_Location_Area_VLR pro-cess, refer Figure 4.11 for the MSC side of the procedure. [9]

vlr_ochFSM subset implementation of OCH_VLR process. [4]

vlr_ichFSM subset implementation of ICH_VLR process. [4]

21

4.2.5 Application platform

Following section will describe application platform components in a more de-tailed manner. The application platform component interaction can be referredhere 4.2.

A call-set up interaction involves the MUS components instructing the CS to setup a media context. This is accomplished by seizing the virtual switches. TheContext provided by CS will be formatted into a message of adding two termi-nations by the MGC. The MGC instructs the MG to set up media resources forcommunicating between the two termination points requested by MUS moduleswhen they seize virtual switches.

Session store

The Session Store is an internal storage for the MUS Module for storing sessions,it is used for easy look up, insert and delete functionality

Transit Module (TM)

Figure 4.4: Overview of the TM functionality.

A TM routes ISUP messages sent between MSCs, as can be seen in Figure4.5. Routing of a call is done based on the dialled digits and from where themessage originated from. The transit module does a B-number analysis to check

22

if the format of the dialled number is in our network or not. It then selects anew destination point code (DPC) and CIC for the outgoing connection. Itsets the originating point code (OPC) of the message with its own point codeand routes the message to its destination. There is one CIC and PC pair foreach connection and anything received on such a pair is sent to the other pairassociated with it (Figure 4.5). The TM keep track of the CIC and PC pair forevery connection. [14]

Figure 4.5: Routing CIC and PCs

23

Connection Service

Figure 4.6: CS overview

The Connection Service (CS) provides a media context for a call service. Fig-ure 4.6 provides the Connection Service component overview. The ConnectionService (CS) uses a soft-switching mechanism which is part of the applicationplatform.

A context is an association between a collection of terminations. A terminationis a source and/or sink for one or more streams of information. For a graphicaldepiction of these concepts. Refer to figure 4.7

Null context refers to a context which contains all terminations which are cur-rently not in any other context. Initially a null context is a resource pool of allavailable terminations.

The CS interface is called by the MUS modules. Visiting MUS and TerminatingMUS are access switch users while Gateway MUS is a service switch user. Moredetailed description of switch users is also provided in the 4.3.4 section.

Transcoding of the media bearers must be handled by Media Gateway. SinceRTP was used as bearer for both terminations, there was no need for transcod-ing functionality. The Figure 4.7 explains the need for transcoding betweenRTP and Switched Circuit Network (SCN) bearers. In Figure 4.7 if one of theterminations with RTP as bearer goes down, another Switched Circuit Net-work (SCN) bearer for the given termination can still be used if the Media

24

Figure 4.7: H.248 Connection Model

25

Gateway has functionality to transcode between RTP and SCN codecs makingthe next call possible. Interoperability between different types of networks isachieved, since MG can convert between the different transmission and codingtechniques. [16, p. 6]

The available media bearers of a MG can be notified to the Media Gatewaycontroller (MGC). Modifying of the terminations characteristics are supportedby H.248. [16]

H.248 client / MGC

The MGC is responsible for handling signalling and controlling media. Mega-co/H.248 is the client server protocol that is used for communication betweenthe MG and the MGC. Megaco/H.248 protocol commands are applied to ter-minations that are related to a context. Megaco/H.248 provides commands tocommunicate and manage MGs. Most of the commands are sent from an MGCto MG. The exceptions are the Notify command, which is always sent froman MG to an MGC, and the ServiceChange command, which can be sent fromeither an MG or MGC.

A short description of the commands are as follows:

• Add: Adds a termination to a context. Add command on the first Ter-mination in a context is used to create a context. Only two terminationscan exist in a context.

• Modify: Modifies the properties, events, and signals of a termination.

• Subtract: Disconnects a termination from its context and returns statisticson the termination’s participation in the context.

• Move: Atomically moves a termination to another context.

• Audit Value: Returns the current state of properties, events, signals, andstatistics of terminations.

• Notify: Allows the Media Gateway to inform the Media Gateway Con-troller of the occurrence of events in the Media Gateway.

• Service Change: Allows the Media Gateway to notify the Media GatewayController that a termination or group of terminations is about to be takenout of service, or has just been returned to service. A number of ServiceChange Reasons have been defined which provide further details.

Media Gateway

The Media Gateway (MG) is often controlled by a separate Media GatewayController which provides call control and signalling functionality.

Media Gateways understand and decipher the Megaco commands from MGCand act according to the instruction provided.

26

Both MG and MGC are Megaco users. A MG registers itself by sending aService Change command when it discovers a Megaco user.

The MG is instructed by the operator to make resources available to MGC.

Operator Interface

The Operator can add the media resources and maintain the media resourcesavailable. The MUS operator interface instructs the RTP termination agentto associate CICs available with the termination identifiers. Lastly the MGoperator interface instructs the MG to add RTP terminations into the mediaresource pool. Please refer to 9.1 for more details about adding terminations.

RTP termination agent

The RTP-TA is a component residing in the application platform that managesvoice circuit information. The modules connected to this one are the MUS andthe MGC.

The MGC keeps the RTP-TA updated about changes in the terminations re-ported by the MG. It adds new ones if they are available.

The operator can then associate a CIC to a termination making it available tothe MUS for making calls.

When a call is made the MUS will request two terminations from the RTP-TA.If it can not provide them, the call set-up will be cancelled. If terminations areavailable, the RTP-TA will respond with a CIC and a termination ID for eachtermination. The CIC is later used when assigning the circuit in the BSC andthe termination ID for requesting switches with the CS.

When the call is over, the terminations are released and the RTP-TA marksthem as available again.

4.2.6 Tabman

Tabman is the module performing the table management, for a process whichneeds to retain its ETS-table after a crash. It does this by using the inheritancesystem of ETS-tables. A process that needs to retain the ETS-table registerstabman as the inheritor. Whenever this process crashes tabman inherits theETS-table and returns ownership of it whenever the new process asks for it(typically when it is initialising).

27

4.2.7 Supervision structure

mus_sup

mgc_sup m u stcp_server vlr t a b m a n

mgc_main

.. .

. . .

mus_worker 1 mus_worker N

vlr_worker 1 vlr_worker N mus_con

monitor

moni tor

Figure 4.8: MUS supervision

Servers and workers in the system are supervised as can be seen in Figure 4.8.ETS-tables are used for storing information. The ETS-tables provided in theErlang/OTP platform are not persistent. This was solved by using a globaltable manager, tabman, that uses the inbuilt inheritance feature of ETS-tableto assign a process as the heir of the table. When the worker is restarted itchecks with tabman if there is a saved table. If there is one it receives theownership of that table and executes with its restored state. This makes surethat as long as tabman does not crash information is not lost.

In order to provide isolation during crashes and to make sure the mus knows ifan mus_worker has crashed, the mus monitors the mus_con having a link be-tween the mus_con and the mus_workers. This way, whenever an mus_workercrashes, the mus_con crashes too (including all other mus_workers) informingthe mus which mus_con and thus which session crashed. This enables the musto do a proper clean-up.

4.3 Services

GSM call service handles the location 4.3.1 and call procedures 4.3.2 as specifiedby 3GPP. [4,9] It also handles media which is provided through the ConnectionService 4.3.4 and RTP circuit emulation.

4.3.1 Location procedures

TheGSM call service supports the following subscriber management procedures.

• IMSI attach

• Normal/periodic updating

• Explicit/implicit detach

28

Figure 4.9: Location procedures overview.

The GSM call service handles one location area, which is a geographical areacovered by an MSC. As shown in Figure 4.9 an example of that is MSC-1covering Polacksbacken via one BSC and two BTSs.

If an MS is turned on in the Polacksbacken area it will request itself to beassociated with the network via IMSI attach or normal updating procedure, seeFigure 4.10. This will be received by MSC-1 as an Location Updating Requestwhich contains the subscriber identity and forwarded to the VLR as seen inFigure 4.11. If the subscriber is known in the VLR, the MSC will send anLocation Updating Accept message back to the MS.

If the MS isn’t known in the VLR the VLR will interrogate the HLR via theMAP signalling seen in 4.10. If the HLR confirms the subscriber as valid theVLR will allocate a TMSI and pass that to the MS in the Location UpdatingAccept message.

While an MS is associated with the network it is required to periodically recon-firm that it’s alive by sending a Location Updating Request. An MS is specifiedto send an explicit Detach indication message when it’s powered off. For eachattached subscriber, there is an implicit detach timer which upon timeout willmark the subscriber as detached.

Roaming from another operator or location area is common in GSM networks,an example of that is moving between Polacksbacken and Boländerna in Figure4.9 which handled by the GSM call service.

29

Figure 4.10: IMSI attach signalling sequence.

30

Figure 4.11: FSM of MSC location procedure.

31

4.3.2 Call handling

The GSM call service handles calls according to specifications. Radio resourcemanagement is done according to [1, ch. 3], signalling is according to [1, ch. 5].Messages and their contents are according to [4, ch. 8].

Making a call

Originating calls are handled according to [1, 5.2.1]. The MSC and VLR pro-cedures used are subsets of the procedures in [4, 7.1].

Figure 4.12: Originating call sequence

When making a call, the MS requests the allocation of Radio Resource (RR)from the BSS. On successful resource allocation, the BSC sends a Base Sta-tion System Management Application sub-Part (BSSMAP) complete layer 3information piggybacked on the SCCP connection request message via the Ainterface to the MSC.

On the MSC side the MUS Controller creates a new session and spawns an MOworker to handle the incoming call. The incoming call handler queries the VLR

32

with a process access request over the B interface to determine whether thesubscriber is allowed to make a call. This is determined by the VLR incomingcall handler which checks the state of the subscriber in the VLR.

The incoming call handler in the VLR will request the MS’ IMSI with an identityrequest and deny or acknowledge the request.

On an identity request, the MS sends back an identity response, containing itsIMSI.

On denial, the originating MSC sends a Direct Transfer Application Part (DTAP)service reject message via the A interface, the connection to the MS is released,all resources freed and the session ended. This can happen when the MS is notpresent in the VLR, blocked for calling in this LAI or on a failure in the system.

On acknowledging the process access request, the originating MSC sends aDTAP service accept message back on the A interface. Then the VLR instructsthe originating MSC whether it should reuse an existing TMSI or use a newTMSI.

The originating MSC now waits for a DTAP setup message from the MS. Ona DTAP setup message the originating MSC makes a request info for outgoingcall request to the VLR on the E interface. If the call is an emergency callthe VLR rejects the call since the system does not support emergency callhandling. Otherwise the VLR checks whether the requested service is supportedand replies to the originating MSC with a complete call message. On a completecall message, the originating MSC requests a RTP termination, sends a DTAPcall proceeding message to the MS and a BSSMAP assignment request on the Ainterface to allocate the voice circuit on the BSS side.

The BSS replies with a BSSMAP assignment complete to confirm. Now theoriginating MSC sends an ISUP Initial Address Message (IAM) message to theGMSC over the E interface. The GMSC requests the necessary informationfor addressing and routing the call and replies with ISUP Addressing CompleteMessage (ACM) if successful, and with an ISUP Release (REL)message if failed.

The GMSC then forwards an ISUP Call Progressing (CPG) message from theterminating MSC to indicate, that the terminating MS has received the calland is alerting. On the ISUP CPG message the originating MSC sends a DTAPalerting message to the MS.

On answering, the GMSC forwards the ISUP Answer Message (ANM) to theoriginating MSC which completes the CS context and sends a DTAP connectmessage to the originating MS. The MS confirms with a DTAP connect ACK,at this point the call is active.

Receiving a call

Terminating calls are handled according to [1] subsection 5.2.2. The MSC andVLR procedures used are subsets of the procedures in [4] section 7.3.

33

Figure 4.13: Terminating call sequence

The terminating MSC initially gets an ISUP IAM via the E interface fromthe GMSC. On receiving the IAM the terminating MSC sends an send infofor incoming call message via the B interface to the VLR and requests a RTPtermination from the termination agent.

The VLR incoming call handler routine checks the validity of the request andits parameters and replies with a page MS message or a send info for incomingcall negative response back to the terminating MSC.

On a page MS message from the VLR the terminating MSC sends a BSSMAPpaging message to the terminating MS, an ISUP ACM message to the GMSCand then it waits for the BSSMAP page response.

On a BSSMAP page response the terminating MSC makes a process accessrequest to its VLR and waits for the result. The VLR checks the state of thesubscriber and replies with a complete call message or a negative response.

On receiving the complete call message from the VLR the terminating MSCsends a DTAP setup via the A interface to the MS and waits for a response tothe setup message.

On a DTAP call confirmed message from the terminating MS the terminating

34

MSC sends a BSSMAP assignment request to the BSS to establish the connec-tion between the BSS and the MS.

On successful connection establishment the MS sends a DTAP alerting messageto confirm, that the terminating MS has received the call request and is alerting.The terminating MSC sends an ISUP CPG message to the GMSC to informthe originating side about the call progressing. and waits for the MS to answerthe call.

On answering the call the MS sends a DTAP connect on which the terminatingMSC initiates the CS to connect the media, sends an ISUP ANM to the GMSC,a DTAP connect ACK back to the MS and a complete call ACK to the VLR.At this point, the call is established.

Releasing a call

Releasing a call is also described in and implemented according to [1].

Figure 4.14: Example for a release sequence

All participating MSCs and MSs can release a call at any time. For that allMSC instances support ISUP REL and ISUP RLC commands at any time inthe call process. On releasing the ISUP REL are forwarded to the next MSCin the call entity chain. All MSCs release their respective media resources andthe O-MSC and T-MSC disconnect the connection to their respective MS.

Routing a call

When a message is sent to the transit module, routing is done based on thedialed digits and who the message originated from. The transit module doesa B-number analysis in order to check if the format of the number is correct.Then it selects a new Destination Point Code (DPC) and CIC for the outgoingconnection. It sets its own point code (PC) as the Originating Point Code (OPC)and sends the message where it is supposed to be sent. There is one CIC and

35

PC for each connection and anything received on one pair is sent to the otherpair associated with it.

IMSI origin analysis The B-Number analysis consists of IMSI origin analysisto determine the B-number Origin (BO). Here we assume the BO to be 30 whichsignifies it is a call originating message. The result of the IMSI origin analysis issent to the Pre-Analysis, The Pre-Analysis calculates the (Origin for B-NumberAnalysis (OBA)) of the B-Number analysis.

Pre-Analysis The pre-analysis table makes use of the extra information con-tained in the setup message originating from the MS, the B-Number Type(BNT) and the Numbering Plan Identifier (NAPI). By using the extra informa-tion about the B-number, it is possible, for example to direct an internationalnumber directly to an Origin for B-Number Analysis (OBA) containing onlynumbers in the international format. Pre-analysis is used as a filtering andselection tool.

Examples (filtering)

BNT=2, B-number=0047, NAPI=0This would be ignored since NAPI is 0 which is a reserved value.

BNT=2, B-number=0047, NAPI=1In this case we continue in the origin specified in the table.

Examples (selection)

BNT=0, B-number=0047, NAPI=1BNT=0 represents an unknown number and thus OBA is 30.

BNT=1, B-number=0047, NAPI=1BNT=1 represents an international number and thus OBA is 32.

B-number analysis The analysis checks where the message is supposed tobe routed by looking at the country code (CC) and national destination code(NDC).

Requesting a roaming number To be able to route a call in a GSM-networkthe G-MSC has to request routing information from the HLR, which in turnrequests a roaming number from the VLR in which area of responsibility thecalled MS is currently roaming. Our system supports roaming numbers to bespec-compliant. On a request for routing information from the g_worker to theHLR stub. The HLR stub requests a roaming number from the VLR. Sincethe HLR is stubbed, all requests go directly to our VLR. The VLR allocatesa roaming number (refer 4.15 for details on the procedure in the VLR) for thecall and returns it to the HLR, which returns it back to the g_worker. The

36

roaming number is released by the mt_worker after the call has been finishedor canceled.

Figure 4.15: The allocation process in the VLR to provide a roaming numberfor an incoming call

4.3.3 Media handling

RTP circuit emulation

The project aimed to emulate a traditional E1/TDM setup in terms of mediahandling using RTP over IP as the bearer. In a time division multiplexingsystem the physical end-to-end connections are split into logical circuits bygiving each of them a specific time slot within the period time.

As can be seen in Figure 4.16, in the case of E1, there are 32 available timeslots for media in every piece of interconnecting equipment. These time slotsare mapped to the 5 least significant bits of the 32-bit Circuit Identification

37

Code (CIC). The rest of the bits selects which piece of equipment to use. [8,3.2.2.2]

To emulate this, our system maps CIC to a circuit the operator has associatedwith a termination ID in the RTP-TA. The termination ID is a reference to asemi-static RTP termination that is created by the operator in the MG.

This special type of termination is not to be confused with ephemeral RTPterminations found in MGCP and Megaco compliant media gateways. It actslike a physical termination, because it is moved in and out of the Null contextwhen added or removed from contexts, rather than being created and destroyed.[16, 6.2]

The RTP bridge in the BSC has a mapping directly from CIC to RTP session(refer Figure 4.17). The result is that both the MSC and BSC will find thecorrect RTP session given through the BSSMAP assignment CIC and can starttheir media communicating directly without any signalling outside of the Ainterface, just like with a regular E1/TDM setup.

Figure 4.16: E1 circuit.

38

Figure 4.17: RTP circuit.

39

Circuit management

Figure 4.18: CIC establishment throughout the system’s components

As can be seen in figure 4.18, the operator configures the circuit both in theBSC and MG. The MG then communicates the terminations it has added tothe RTP termination agent residing in the MUS over H.248 through the MGC.

Ports are pre-bound and kept active across calls in both the BSC and MG. Thisemulates a static circuit system accurately and makes it possible to use solelythe CIC to choose an RTP session and activate a call.

The operator will:

1. Using the Virtual Terminal (VTY), add a CIC and RTP session details tothe BSC’s running configuration.

2. Using the MG operator module, give the same RTP details to the MGand receive a termination ID referring to a newly created termination

3. Using the MUS operator module, associate this new termination ID withits corresponding CIC in the BSC

40

The resulting mapping looks like this:

• BSC knows CIC and associated RTP session details.

• MG knows termination ID and associated RTP session details.

• RTP termination agent knows CIC and associated termination ID.

4.3.4 Connection Service

Building a context

Connection Service with the following functionalities builds a context for a call.

1. Provide soft-switching among the GSM network elements.

2. Create a context of terminations for each call service.

Finite state machine (FSM) Figure 4.19 depicts the connection setup and con-nection release mechanism.

Connection Setup

A virtual switch having two ports can be connected either in bothway or back-ward direction. Backward connection between ports is needed to insert tones.Bothway connection between virtual ports is needed for a call service. We haveimplemented bothway connection. Two virtual switches are joined by using thejoin command.

Init method can initialise a connection service instance for a given CIC(call).The core network element can grab(seize_avs) an access virtual switch whichwould put the FSM into avs_state. The next core network element grabs(sieze_svs)a service switch resulting FSM to go to svs_state. Subsequent grabbing(seize_svs)of service switches will result in svs_state. The last core network elementgrabbing(seize_avs) access virtual switch will result FSM to go to avs_stateagain. A complete_context message from the last core network element is acontext_established state. Context is unique reference id returned back to thecore network element which completes the context.

Connection Release

Virtual switches are disjoined by using the disjoin function. Virtual ports of avirtual switch are disconnected by disconnect function.

The FSM is in the context_established state when a context is established anda call is ongoing. If any of the network elements decide to release connection,they do by calling release. An access virtual switch grabbed network elementwhen releases the switch, FSM goes from context_established state to the con-text_exists state. The FSM remains in the state context_exists until all theservice switches are released. When the last network element releases the accessvirtual switch the FSM goes to context_release state. In the context_releasestate, all the tables (resources) for soft-switching would be removed.

41

Figure 4.19: Connection Service - Finite State Machine

42

Controlling the Media Gateway

1. Manage and control Media Gateway (MG).

(a) Register MGs.• Service Change command from MG (reason as restart) is usedas registration and Service Change command is sent as response.[17, p. 16]

(b) Create / Release Terminations and manage contexts.• Context details from the Connection Service is formatted intoMegaco message of adding two terminations into a given con-text.Megaco commands are sent over Megaco/IP to the MediaGateway.

• When a connection is released by the Connection Service, thesubtract terminations command for a given context is sent to theMG.

2. Update the RTP terminating agent with available resources (RTP ports)[20] in the MG.

• When the Media Gateway sends the Service Change command (dueto new terminations added to it by the operator), the MGC adds theavailable resources to the RTP terminating agent.

Connecting the media

1. Register to the Media Gateway controller (MGC) and handle Megacomessages from the MGC.

(a) Create contexts, Add/Remove terminations.• Termination identifiers provided by the MGC as part of contextare used to get the termination details. Termination details areobtained by looking up the termination details data store createdby the Operator. The Local and Remote Descriptors for a givenpair of terminations are formatted into the Megaco notation. Lo-cal Descriptor defines the RTP ports which are opened to listenfrom remote terminations. The Remote descriptors define theremote termination entities to which the RTP data packets willbe sent to. The MG is responsible for transforming media codecsif necessary.

2. Create and manage RTP terminations when instructed by the MG Oper-ator.

(a) Create termination (RTP port) resources. Please refer Figure 4.18• The Operator instructs MG to add a termination with detailsinto the data store. RTP ports for the local termination descrip-tors are opened and the corresponding socket details are updatedinto the termination details data store.

43

Chapter 5

Evaluation and testing

5.1 Testing procedure

There are several testing tools available for Erlang. We focused on the toolsthat are shipped with OTP.

For unit testing we used EUnit. In addition to unit testing we also tried thePropEr tool. PropEr is a tool for doing model based and property testing. Themodel part implies writing an abstract model of the stateful application’s sideeffects and behaviour. This makes it possible to more thoroughly test serversand state machines, which is much harder or impossible with regular unit styletesting tools.

Property testing is a new method of testing software where you don’t manuallydefine a set of assertions, but rather an input and output specification andsome properties of the input output relation. The tool then generates a set ofrandomized test values according to these specifications.

We ended up not using PropEr in the end mostly due to time constraints.Another reason is the relatively low requirements on correctness we had. Thetime it takes to write the models and properties was instead spent on developingnew features.

In the final code and testing rules the requirements for testing was to use EUnittests whenever possible.

5.1.1 Performance testing

We did not do any performance testing like benchmarking since the providedhardware handles up to three simultaneous MO-MT calls (7 TCH channels).The formal requirement was to be able to handle one mobile originating, mobileterminated call. The product is capable of handling, any number of calls intheory, given enough processing power. The base-station used limits, this thenumber of simultaneous calls to three. Because of this, detailed performancetests were not performed.

44

Manual testing showed that the system is capable to sustain all the calls thebase station can serve radio to, and one additional MS that gets rejected dueto the insufficient radio resources.

5.1.2 Unit testing

The unit tested parts of the code is mainly the more simple generic servers andsome of the GSM codecs. The more complicated servers and state machinesturned out to be too time consuming to test the same way as they are highlydependent on other parts of the system in a tightly coupled manner.

5.1.3 System testing

For full system testing there was an updated list (10) of tests to be performed oneach milestone to track the progress of the overall goal, and to find the criticalcrasher bugs.

5.2 Known issues

5.2.1 Session invalidation on TCP disconnect

If the connection between the BSC and MSC is lost, all state information relatedto the lost MSC is deleted in OpenBSC. It is currently not cleared in our systemhowever, which causes inconsistency.

The easiest workaround is currently to restart the system, which purges all thenecessary state information.

5.2.2 Disconnect race condition

If the called and calling party hang up at the same time, both the release MTand release MO sequence will start. When this happens the system becomesunstable. Among other things, the connection service crashes. The reason isthat in its current design it expects the terminations to be released in a specificorder.

To fix this the system has to be restarted.

5.2.3 VLR robustness

With the help of supervision and table inheritance the system can withstandcrashing processes in most places. An exception is the VLR and its workerswhich currently takes all of its tables with it when it crashes. This means thatit will forget all subscribers that has ever attached or detached in the system.

The workaround is to simply re-attach the mobile stations.

45

5.2.4 MG and MGC robustness

The MG and MGC consists of mostly reused code which came without a workingsupervision structure. As it was not part of the primary requirements, work wasnot put into making them withstand crashes.

A crash in the gateway causes the gateway controller in the MUS to crash andleaves the system in an unstable state. The same thing happens if the controlleritself is the offender.

A system restart fixes this problem.

46

Chapter 6

Related work

6.1 Existing products

6.1.1 OpenBSC

OpenBSC provides a network in a box mode where OpenBSC acts as MSC, HLR,VLR and Media Gateway. It has more features than our system (for exampleAuthentication and SMS) but it is written in C and there is no division betweenoriginating, gateway and terminating MSC. [11]

6.1.2 OpenMSC

The OpenMSC [21] project provided the SMS capable MSC. GSM Call Servicecould make use of the codecs retrieved from the TCP Server. TCP Server ofOpenMSC project was enhanced to encode and decode messages pertaining tocall service. VLR implemented in OpenMSC was looked into, GSM Call Servicere-implemented VLR functionalities according to the 3GPP specifications.

47

Chapter 7

Conclusion and future work

7.1 Conclusion

The main goal of this project has been to implement a GSM call service forMobile Arts. The product is supposed to be used for experimentation purposeswhich was reflected in the design and implementation. This enables furtherwork as introduced in the following sections.

Erlang/OTP design principles helped to design a modular distributed system.An agile process such as Scrum helped in planning efficiently and allowed theteam to commit to work while the customer was assured of an high qualityproduct.

The team and MA considers the project successful.

7.2 Future work

7.2.1 Conference calls

The GSM call service allows calls between 2 parties. However, a long-existingfeature in commercial GSM networks is conference calls where three or moreparties are in a call together. The GSM call service architecture should allowextending the system with conference calls. The connection service suppliesthe basic tools for introducing a third party into the call through a conferencecall service switch. Conference calls are closely related to Call Waiting andCall Deflection, see 7.2.2 The Media Gateway would have to be extended withtranscoding functionalities to support combining the corresponding streams, see7.2.7.

48

7.2.2 Call waiting and call deflection

Call Waiting can be used to park and/or redirect active calls. It also allowsthe user to receive a second call while in an active call. This is not currentlysupported, the signalling and virtual circuit-switching are designed to work withlinear calls. However, since signalling is according to 3GPP specifications thesignalling components in the MUS can be adapted according to the correspond-ing specifications by the 3GPP.

Call Waiting and Call Deflection are closely related to conference calls and haveto be at least partly implemented to support conference calls. The conferencecall initiating MS must be able to park a running call to call or answer a callfrom a third party for a conference call.

7.2.3 GPRS/EDGE support

GSM call service does not support any data transmission. In light of the pop-ularity of data services this would be a useful addition. The OpenBSC-projecthas open source GPRS projects running [11], this work could be used to extendthe call service with data transmissions.

7.2.4 3G support

According to [11], the OpenBSC project is planning to support 3G. As soon asOpenBSC supports 3G it would be feasible to integrate 3G support into our callservice. The similar structure of 2G and 3G networks should allow this withoutchanging too much of the call service’s architecture.

7.2.5 Multiple BTS/BSCs per MSC

To cover bigger areas and support more concurrent calls at the same time thecall service could be extended to support multiple BSCs and/or multiple BTSs.

7.2.6 External ISUP interface

While more BSCs and/or BTSs can cover a wider area and more concurrent callscould an external ISUP interface make it possible to connect the call service toother GSM networks.

7.2.7 Media Gateway transcoding

Transcoding is closely related to several other future work items in this list.It is needed to connect the call service to other types of network, to supportdifferent codecs on different hardware and to be able to manipulate voice trafficin the media gateway. This is needed for example when doing conference callsor in-call acoustical signals from the network.

49

7.2.8 MA HLR

The MA feature was originally planned to be in the call service, but the HLRfunctionality has only been stubbed. There exists an Erlang interface for the SS7stack provided by Mobile Arts from last year, that according to our investigationduring the project would be sufficient for call handling with a few small changes.

7.2.9 SMS support

Previous year’s project CS course product SMS service, was not integrated intothis product. Doing that would improve the completeness of the GSM function-ality covered by the call service. The architecture of the SMS service has to beadapted to the new structure of the call service.

7.2.10 Tones

Inserting tones would be a necessary addition which could be used to send errortones or info tones depending on the cause/reason for sending tone. A tonecould be generated and sent to the Mobile Station.

50

Bibliography

[1] 3GPP. GSM 04.08 v.7.0.0. http://www.3gpp.org/ftp/Specs/archive/04_series/04.08/0408-700.zip, 1998. Mobile radio interface layer 3specification.

[2] 3GPP. GSM 08.58 v.7.0.0. http://www.3gpp.org/ftp/Specs/archive/08_series/08.58/0858-700.zip, 1998. Base Station Controller - BaseTransceiver Station (BSC - BTS) interface; Layer 3 specification.

[3] 3GPP. GSM 23.002 v.7.0.0. http://www.3gpp.org/ftp/Specs/archive/23_series/23.002/23002-700.zip, 2005. Technical Specification GroupServices and Systems Aspects; Network architecture.

[4] 3GPP. GSM 23.018 v.7.0.0. http://www.3gpp.org/ftp/Specs/archive/23_series/23.018/23018-700.zip, 2005. Technical Specification GroupCore Network and Terminals; Basic call handling; Technical realization.

[5] 3GPP. GSM 24.008 v.7.0.0. http://www.3gpp.org/ftp/Specs/archive/24_series/24.008/24008-700.zip, 2005. Technical Specification GroupCore Network and Terminals; Mobile radio interface Layer 3 specification;Core network protocols; Stage 3.

[6] 3GPP. GSM 29.002 v.7.0.0. http://www.3gpp.org/ftp/Specs/archive/29_series/29.002/29002-700.zip, 2005. Technical Specification GroupCore Network and Terminals; Mobile Application Part (MAP) specifica-tion.

[7] 3GPP. GSM 48.008 v.7.0.0. http://www.3gpp.org/ftp/Specs/archive/48_series/48.008/48008-700.zip, 2005. Technical Specification GroupGSM/EDGE Radio Access Network; Mobile Switching Centre - Base Sta-tion System (MSC-BSS) interface; Layer 3 specification.

[8] 3GPP. GSM 48.008 v.7.0.0. http://www.3gpp.org/ftp/Specs/archive/48_series/48.008/48008-700.zip, 2005. Technical Specification GroupGSM/EDGE Radio Access Network; Mobile Switching Centre - Base Sta-tion System(MSC-BSS) interface; Layer 3 specification.

[9] 3GPP. GSM 23.012 v.7.0.0. http://www.3gpp.org/ftp/Specs/archive/23_series/23.003/23003-700.zip, 2006. Technical Specification GroupCore Network and Terminals; Location management procedures.

51

[10] 3GPP. GSM 48.006 v.7.0.0. http://www.3gpp.org/ftp/Specs/archive/48_series/48.006/48006-700.zip, 2006. Technical Specification GroupGSM EDGE Radio Access Network; Signalling transport mechanism spec-ification for the Base Station System - Mobile-services Switching Centre(BSS - MSC) interface.

[11] Harold Welte. Free Software GSM Protocol Stacks OpenBSC, OpenS-GSN, OpenGGSN, OsmocomBB. http://elinux.org/images/6/65/Elce2010-welte-openbsc.pdf, 2010.

[12] Henrik Back and Ming Zhao. Voice Mail System for IP Multimedia Sub-system. Master’s thesis, Uppsala University, 2008.

[13] Henrik Kniberg. Scrum and XP from the Trenches. InfoQ, 2007.

[14] ITU-T. Q.764. http://www.itu.int/rec/T-REC-Q.764-199912-I, 1999.Signalling connection control part formats and codes.

[15] ITU-T. Q.713. http://www.itu.int/rec/T-REC-Q.713-200103-I, 2001.Signalling connection control part formats and codes.

[16] ITU-T. H.248.1. http://www.itu.int/rec/T-REC-H.248.1-200509-I,2005. Gateway control protocol: Version 3.

[17] ITU-T. H.248.8. http://www.itu.int/rec/T-REC-H.248.8-200708-I,2007. Gateway control protocol: Error code and service change reasondescription.

[18] Ken Schwaber and Jeff Sutherland. Scrum Guide. http://www.scrum.org/storage/scrumguides/Scrum_Guide.pdf, 1991-2011.

[19] nanoBTS. The world’s most deployed picocell. http://www.hexazona.com/nexwave/docs/ipaccess/nanoGSM%20Brochure.pdf, 2012.

[20] Network Working Group. RTP: A Transport Protocol for Real-Time Ap-plications. http://www.ietf.org/rfc/rfc3550.txt, 2003. RFC 3550.

[21] Olle Gällmo. Projekt DV (Project CS) 2010. http://www.it.uu.se/edu/course/homepage/projektDV/ht10, 2010.

[22] Team Mobile Arts Project CS 2011. Course report GSM Call Service, 2012.

[23] The Osmocom Project. Osmocom SS7 codec git repository. http://cgit.osmocom.org/cgit/erlang/osmo_ss7/, 2011.

[24] The Osmocom project. nanoBTS. http://openbsc.osmocom.org/trac/wiki/nanoBTS, 2012.

52

Chapter 8

Appendix A: Installationinstructions

8.1 Hardware

• One ip.access nanoBTS GSM 1800 (v.139 rev.31)

• At least one x86_64 compatible computer

8.2 Software

• x86_64 Linux distribution

• GNU C compiler and basic build essentials

• libosmocore (0.3.5)

• libosmo-abis (0.1.0.3.0b5)

• libosmo-sccp (0.0.6.1.1)

8.3 Installing the call service

We begin by extracting the release archive somewhere. The servers will loginformation here so make sure there is enough space.

$ cd <INSTALLATION_DIRECTORY>$ tar x f z <PATH_TO_RELEASE_ARCHIVES>/c a l l s e r v . ta r . gz

53

8.4 Installing the media gateway

Similarly, extract the media gateway release.

$ cd <INSTALLATION_DIRECTORY>$ tar x f z <PATH_TO_RELEASE_ARCHIVES>/mg. ta r . gz

8.5 Install OpenBSC

OpenBSC uses the common UNIX pattern for compiling and installation.

$ cd <TERMPORARY_DIRECTORY>$ tar x f z <PATH_TO_RELEASE_ARCHIVES>/openbsc . ta r . gz$ cd openbsc$ . / c on f i gu r e −−enable−osmo−bsc$ make$ su# make i n s t a l l

8.6 Configure nanoBTS

To configure the nanoBTS see [24].

8.7 Starting the system

To start the system we need to start the three applications.

First start the call server:

$ c a l l s e r v /bin / c a l l s e r v s t a r t

Then start the media gateway:

$ mg/bin /mg s t a r t

And finally OpenBSC:

$ osmo−bsc

To be able to make calls we need to create some circuits. See 9.1.

54

Chapter 9

Appendix B: Maintenanceinstructions

9.1 Managing circuits

9.1.1 Using the launch module

The shipped OpenBSC configuration adds 10 default terminations to the RTPbridge and sets the media gateway IP address to localhost. To quickly add 10circuits that use these terminations the launch module can be used.

We first attach to the MG and create the terminations there.

$ mg/bin /mg conso l e1> launch : assoc_mg ( ) .

They should register with the MGC and we can now attach to the MUS andassociate them with CICs.

$ c a l l s e r v /bin / c a l l s e r v conso l e1> launch : a s s o c_ca l l s e r v ( ) .

9.1.2 Adding terminations in the MG

The operator can add terminations in the media gateway using the MG operatorinterface.

In this example we add one termination with the ID "27", that listens on port15027 and sends to port 20027.

$ mg/bin /mg conso l e1> Ip = inet_parse : ntoa ({127 , 0 , 0 , 1 } ) ) . % IP o f the host running OpenBSC .2> ope ra to r_ in t e r f a c e : c reate_terminat ion (1 , 15027 , 20027 , Ip ) .

55

To associate this new termination with a CIC, we attach to the MUS.

$ c a l l s e r v /bin / c a l l s e r v conso l e1> mus_operator : a s soc i a t e_te rminat i on ( " 2 7 " , 27)

We have now associated the termination with the CIC 27 in the MUS. Lastlywe need to add it in the BSC through its VTY interface. In this example weassume that the BSC and call service is running on localhost.

$ t e l n e t l o c a l h o s t 4242OsmoBSC> enableOsmoBSC# con f i gu r e te rmina lOsmoBSC( con f i g )# mscOsmoBSC(msc)# mg 12 7 . 0 . 0 . 1OsmoBSC(msc)# c i c 27 20027 15027

As can be seen above the port numbers are reversed on the BSC since we wantto listen for incoming packets on port 20027 and send packets on 15027.

9.1.3 Logging

Logging of important information in the system is done using the System Ap-plication Support Libraries (SASL) for most of the modules in the product.

56

Chapter 10

Appendix C: Test cases

57

Status Reasons1 Passed2 Passed3 Passed4 Passed5 Passed6 Passed7 Passed8 Passed

69 Passed70 Passed

9 Passed10 Passed11 Passed12 Passed13 Passed14 Passed

15 Passed16 USSD Passed

17 SMS Passed

67 Successful call setup with voice Passed

While a call is running 18 Passed19 Passed20 Failed Starts both MO and MT release sequences. CS gets confused.21 Passed22 Passed23 Passed24 Passed25 Passed72 Passed26 Passed27 Passed

SingleCall_MO_releaseSingleCall_MT_releaseSingleCall_MO_MT_release_same_timeSingleCall_MO_MT_alerting_timeoutSingleCall_MO_alerting_releaseSingleCall_MT_alerting_releaseSingleCall_MO_early_release(before paging response)SingleCall_MT_not_registered_in_VLRSingleCall_MT_not_registered_in_HLRSingleCall_MT_is_absent_in_VLRSingleCall_MO_external_call(Should display phone number not valid)SingleCall MO – TM + 00SingleCall MO – TM + Invalid NumberSingleCall MO – TM +NumberSingleCall_MO_subscriber_call_not_allowedSingleCall_MO_MT_Cic_blocked Actual circuit blocking is unsupported, but assignment failure

was tested and is working.SingleCall MO_MT_alerting_release_same_time

Message appears: mo_worker <0.126.0>: wf_clear_complete – Unhandled Msg {use_existing_tmsi}Message appears: mo_worker <0.126.0>: wf_clear_complete - Unhandled Msg {use_existing_tmsi}

MultiCall_MO_releaseMultiCall_MT_releaseMultiCall_MO_MT_release_same_timeMultiCall_MO_MT_alerting_timeoutMultiCall_MO_alerting_releaseMultiCall_MT_alerting_releaseMultiCall_MO_early_release(before paging response)MultiCall_MT_not_registered_in_VLRMultiCall_MT_not_registered_in_HLRMultiCall_MT_subscriber_call_not_allowedMultiCall_MO_MT_Cic_blocked

58

28 Passed29 Passed30 Passed71 Passed31 USSD Passed32 SMS Passed33 Passed34 Passed35 Passed36 Passed68 Successful call setup with voice Passed

Generic Cases37 Call a person who is in an active MO-MT call Passed38 Call a person who is in an active MO-MT call and release Passed39 MO-MT call where A-Number is equal to the B-Number(Calling yourself) Passed

40 Passed See above.

42 Leaving Network and Coming back (IMSI Attach and Detach) Passed43 Emergency call handling ? Untested44 Try multi-call during an existing MO-MT call(conference) Passed

Test Cases for Supplementary Services45 Call Hold – Should not crash Passed46 Passed

47 MSA/MSB sets call forwarding option Passed48 MSA/MSB sets call waiting option Passed

VLR/HLR tests50 Passed

51 MO_Call Subscribe who detached Passed52 MO_MT Call each other Passed53 Implicit detach timeout Passed54 Passed

MultiCall_MO_number_invalidMultiCall_MO_external_call(Should not crash)MultiCall_MO_MT_alerting_release_same_timeMultiCall_MT_is_absent_in_VLR

MultiCall MO – TM + 00MultiCall MO – TM +NumberImsi AttachImsi Detach

Isn't exactly handled, but it does not crash anything. The MS is paged and the paging response is ignored and SCCP cleared.

MO-MT call where A-Number is equal to the B-Number(Calling yourself) and release

Invocation of a multiparty call before basic call – should handle no unexpected behaviour

Location Info Not confirmed (make HLR unhappy) – System should work as expected / Shouldn't crash

Roaming Number not found(Simulate by removing entries from roaming_number dets table)

59

57 Location update for subscriber that is known to HLR and VLR Passed58 Location update for subscriber that is known to HLR but not VLR Passed59 Location update for subscriber that is not known to HLR or VLR Passed60 Periodic location update for subscriber that is known to HLR and VLR Passed61 Periodic location update for subscriber that is known to HLR but not VLR Passed62 Periodic location update for subscriber that is not known to HLR or VLR Passed63 Explicit IMSI detach for subscriber known to VLR Passed64 Explicit IMSI detach for subscriber not known to VLR Passed65 Implicit IMSI detach for subscriber known to VLR Passed66 Implicit IMSI detach for subscriber not known to VLR Passed

Robustness tests73 Call worker crashes, other sessions and their data should survive Passed74 Session Store crashes, all sessions and data should survive Passed75 Passed76 RTP TA crashes, all sessions and data should survive Passed77 TCP server crashes, all sessions and data should be removed. Failed BSC restarts but MSC workers and sessions survives (bad).78 VLR crashes, all sessions and data should survive Failed

79 MUS crashes, all sessions and data should survive Passed80 MG worker crashes, other sessions and their data should survive Failed MG main acts weird. MGC crashes in MUS.81 MG crashes, all sessions and data should survive Failed MG workers crash. MGC crashes in MUS.82 MGC crashes, all sessions and data should survive Failed83 Connection Service crashes, other sessions and their data should survive Passed84 Failed

85 MUS Controller dies, other sessions and their data should survive Passed86 Location worker crashes, other sessions and their data should survive Passed

TM or TM dbs crashes, all sessions and data should survive

OCH, ICH and LOC worker takes down the whole VLR and its tables.

MGC tries to register a megaco user again and fail.

Tabman crashes, all sessions and data should survive Things will keep running until something that uses tabman crashes, which will go unnoticed by the new tabman.

60