Product report

GSM Call Service

1DT054 Project CS
Ebby Wiselyn Jeyapaul
Egemen Taskin
Erik Grafström
Fartash M. Nejad
Fredrik Pasanen
Max Morén
Mohammadreza Taghilu
Moritz Rogalli
Praveenkumar Bhadrapur

February 16, 2012

 Abstract

Developing and testing new GSM services requires use of proprietary hardware
and software which can be tedious due to inherent high complexity and cost.
The product GSM call service developed by nine master students at Uppsala
University provides a vendor independent, low cost, IP based solution according
to 3GPP specifications. The system designed and developed using Erlang/OTP
is a framework capable of calls, subscriber management and additional GSM
services.
The finished product offers developers a testing environment to build and ex-
periment with new and existing GSM services.
Glossary

Abis Abis interface, RSL

ACM Addressing Complete Message
AGCH Access Grant Channel
AN Access Network
ANM Answer Message
API Application Programming Interface
ATT IMSI Attach
BC Bearer Capability
BCCH Broadcast Control Channel
BNT B-Number Type
BO B-number Origin
BSC Base Station Controller
BSS Base Station Subsystem
BSSAP Base Station System Application Part
BSSMAP Base Station System Management Application sub-Part
BTS Base Transceiver Station
CC Connection Confirm
CGI Common Gateway Interface
CI Cell Identifier
CIC Circuit Identification Code
CM Connection Management
CN Core Network
CPG Call Progressing
CR Connection Request
CS Connection Service
DETS Disk based Erlang Term Storage
DLR Destination Local Reference
DPC Destination Point Code
DTAP Direct Transfer Application Part
DT1 Data form 1
DT2 Data form 2
E1/TDM E1/Time Division Multiplexing
ETS Erlang Term Storage
FSM Finite State Machine
G-MSC Gateway MSC
GMSC Gateway MSC
GSM Global System for Mobile Communication
HLR Home Location Register

1
IAM Initial Address Message
IMSI International Mobile Subscriber Identity
IP Internet Protocol
IPA ip.access
ISUP ISDN User Part
IT Inactivity Test/Timer
LAI Location Area Identifier
LAPm Link Access Procedure for Modems
MA Mobile Arts
MAP Mobile Application Part
ME Mobile Equipment
MG Media Gateway
MGC Media Gateway controller
MGCP Media Gateway Control Protocol
MM Mobility Management
M-MGW Mobile Media Gateway
MNRF Mobile Not Reachable Flag
MO Mobile Originating
MS Mobile Station
MSC Mobile-service Switching Centre
MSISDN Mobile Subscriber Integrated Services Digital Network Number
MSRN Mobile Station Roaming Number
MT Mobile Terminating
MUS Mobile User Service
NAPI Numbering Plan Identifier
NDC National Destination Code
NITB Network In The Box
NP Numbering Plan
OBA Origin for B-Number Analysis
OPC Originating Point Code
OTP Open Telecom Platform
PC Point Codes
PID Process Identifier
PLMN Public Land Mobile Network
PS Packet Switching
PSTN Public Switch Telephone Network
REL Release
RLC Release Complete
RLSD Released
RR Radio Resource
RSL Radio Signalling Link
RTP Real Time Protocol
RTP-TA RTP Termination Agent
SABM Set Asynchronous Balanced Mode
SASL System Application Support Libraries
SLR Source Local Reference
SS7 Signalling System 7
SCCP Signalling Connection Control Part
SCN Switched Circuit Network
SIM Subscriber Identity Module

2
SLR Source Local Reference
TCH Traffic Channel
TCP/IP Transmission Control Protocol/Internet Protocol
T-MSC Terminating MSC
TM Transit Module
TMSI Temporary Mobile Subscriber Identity
TTM Time To Market
V-MSC Visiting MSC
VLR Visitor Location Register
VTY Virtual Terminal
2G Second Generation
3GPP The 3rd Generation Partnership Project

3
Contents

1 Introduction 6
2 Preliminaries 7
2.1 GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 Access Network . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.2 Core Network . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.3 Call procedures . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.4 Location procedures . . . . . . . . . . . . . . . . . . . . . 10
2.1.5 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Development environment . . . . . . . . . . . . . . . . . . . . . . 12
3 Product description 13
3.1 Problem description . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 GSM call service . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.1 nanoBTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.2 OpenBSC . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.3 MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.4 Media Gateway . . . . . . . . . . . . . . . . . . . . . . . . 15
4 System description 16
4.1 Design concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.1 Signalling/Interfaces . . . . . . . . . . . . . . . . . . . . . 17
4.1.2 Application platform . . . . . . . . . . . . . . . . . . . . . 17
4.1.3 Supervision . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.1 Transmission Control Protocol/Internet Protocol server . 18
4.2.2 Mobile User Service (MUS) . . . . . . . . . . . . . . . . . 19
4.2.3 Home Location Register . . . . . . . . . . . . . . . . . . . 20
4.2.4 Visitor Location Register . . . . . . . . . . . . . . . . . . 20
4.2.5 Application platform . . . . . . . . . . . . . . . . . . . . . 22
4.2.6 Tabman . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.7 Supervision structure . . . . . . . . . . . . . . . . . . . . 28
4.3 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3.1 Location procedures . . . . . . . . . . . . . . . . . . . . . 28
4.3.2 Call handling . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3.3 Media handling . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3.4 Connection Service . . . . . . . . . . . . . . . . . . . . . . 41
5 Evaluation and testing 44
5.1 Testing procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.1.1 Performance testing . . . . . . . . . . . . . . . . . . . . . 44
5.1.2 Unit testing . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4
 5.1.3 System testing . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2 Known issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2.1 Session invalidation on TCP disconnect . . . . . . . . . . 45
5.2.2 Disconnect race condition . . . . . . . . . . . . . . . . . . 45
5.2.3 VLR robustness . . . . . . . . . . . . . . . . . . . . . . . 45
5.2.4 MG and MGC robustness . . . . . . . . . . . . . . . . . . 46
6 Related work 47
6.1 Existing products . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.1.1 OpenBSC . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.1.2 OpenMSC . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7 Conclusion and future work 48
7.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.2.1 Conference calls . . . . . . . . . . . . . . . . . . . . . . . 48
7.2.2 Call waiting and call deflection . . . . . . . . . . . . . . . 49
7.2.3 GPRS/EDGE support . . . . . . . . . . . . . . . . . . . . 49
7.2.4 3G support . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.2.5 Multiple BTS/BSCs per MSC . . . . . . . . . . . . . . . . 49
7.2.6 External ISUP interface . . . . . . . . . . . . . . . . . . . 49
7.2.7 Media Gateway transcoding . . . . . . . . . . . . . . . . . 49
7.2.8 MA HLR . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.2.9 SMS support . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.2.10 Tones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
8 Appendix A: Installation instructions 53
8.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.3 Installing the call service . . . . . . . . . . . . . . . . . . . . . . . 53
8.4 Installing the media gateway . . . . . . . . . . . . . . . . . . . . 54
8.5 Install OpenBSC . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
8.6 Configure nanoBTS . . . . . . . . . . . . . . . . . . . . . . . . . 54
8.7 Starting the system . . . . . . . . . . . . . . . . . . . . . . . . . . 54
9 Appendix B: Maintenance instructions 55
9.1 Managing circuits . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
9.1.1 Using the launch module . . . . . . . . . . . . . . . . . . 55
9.1.2 Adding terminations in the MG . . . . . . . . . . . . . . . 55
9.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 experimentation
and 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 2011
and it involved programming in Erlang. The development methodology used
was Scrum [13, 18] which is an agile software development methodology. The
project methodology and working environment is covered in the supplementary
course report [22].
The challenge of the project was to develop a soft real-time system that can
be used in a portable low-cost way instead of large expensive systems that are
usually associated with GSM services.

6
Chapter 2

Preliminaries

This chapter explains the GSM network entities, protocols and interworking
required to handle GSM subscribers and GSM calls.
The intention of this overview is to cover the scope of the product, not the
complete GSM specifications. For further readings, see Bibliography.

2.1 GSM
The 3GPP specifications define different network entities, protocols and their
interworking. As seen in Figure 2.1 a GSM system consists of Mobile Stations
2.1.1, an Access Network (AN) 2.1.1 and a Core Network (CN) 2.1.2. This
enables a subscriber to call another subscriber with the use of its phone number,
or in technical terms its Mobile Subscriber Integrated Services Digital Network
Number (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 Station
Subsystem (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 used
to identify a subscriber within the network.

Base Station Subsystem

The Base Station Subsystem (BSS) refers to the network entities between the
MS and the core network. It consists of one or more Base Transceiver Station
(BTS) controlled by a Base Station Controller (BSC). The BTS relays radio
signalling 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 handling
subscribers and common radio procedures. The BSC relays service requests to
the core network and handles the radio aspect of the subscriber.

Base Transceiver Station

The Base Transceiver Station (BTS) is the radio transceiver which handles MSs
in one radio area. The hardware consists of the antennas and digital signal
processors. 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 the
Core Network (CN). It handles the A and E interface, which is used for call
set-up and subscriber management. An MSC acts differently depending on the
requested service, the roles are covered in 2.1.3.
The MSC creates circuits on which the signalling and media is carried. The
MSC controls several BSCs and manages subscribers for a certain geographical
area 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 handles
mobile 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 the
CN. The HLR stores subscriber information such as the subscriber directory
number 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 pulls
subscriber data from the HLR when a subscriber attaches and purges the data
when the subscriber leaves the MSC area. The VLR is used for core services
such 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, gateway
and terminating MSC roles.

Originating

If a Visiting MSC (V-MSC) receives a service request from an MS indicating

a call service the V-MSC will act as an originating exchange in the CN. The
MSC will check the current state of the subscriber in the VLR to determine if
the subscriber is allowed to make a call. If the VLR checks are OK, the the
MSC 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 called
subscriber and forward the call request to that terminating exchange.

Terminating

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

2.1.4 Location procedures

When an MS is powered on, it will try to associate itself with the network. The
VLR will interrogate the HLR to determine if the subscriber is allowed services
in the network. When the subscriber is associated it is assumed to periodically
reconfirm the association and explicitly tell the CN when it is powered down.
The VLR and HLR tracks the subscribers, purge unconfirmed subscribers and
propagate 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 couple
of interfaces using service specific protocols. This section contains an overview
of those protocols, lower layer protocols such as Signalling System 7 (SS7) and
Transmission 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 the
Abis interface. The protocol consists of radio link establishment and manage-
ment procedures. [2]

There are several protocols on the A interface which are used between the BSC
and MSC. Signalling Connection Control Part (SCCP) is the lower layer pro-
tocol which provides connection oriented and connectionless services. [15] The
top 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 Control
and Radio Resources. [1] Most of the common GSM services such as location
and call procedures are defined within DTAP.

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

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

11
D

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

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

2.2 Development environment

Erlang/OTP is a development environment for building distributed real-time
high availability systems with a short Time To Market (TTM). In Erlang/OTP
there are design principles that have been thoroughly tested and are easy to
implement. 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 in

an abnormal way.

12
Chapter 3

Product description

3.1 Problem description

The project meant to extend existing work by Mobile Arts and implement an
extensible testing framework for GSM services. The framework was to support
Mobile Originating (MO) Mobile Terminating (MT) calls and location services
natively, and make integration and evaluation of additional GSM components
possible.
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 Generation
Partnership Project (3GPP) specifications.
All-IP

• The Real Time Protocol (RTP)-based voice circuit emulation together

with 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 use
as it does not disrupt service for others in the area.

Key features

• Designed as a framework for the possibility of adding features. Other GSM

services 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 GSM
services or products acting as a test environment. See future work 7.2 for
more examples of possible future features.
• Concurrent voice calls and service use is supported. Erlang’s concurrency
property 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 is
easily configured, as well as GSM call service (see 8 for installation and
configuration instructions).

3.3 Reuse

Figure 3.1: Reuse overview

Figure 3.1 shows the components which were reused as-is, components which
existed but could not be used, components which were enhanced to support call
service 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 circuit
connections at the same time. This allows us to have 3 simultaneous calls if
both ends are associated with the same BTS or 7 simultaneous calls if only one
side 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 A
interface. In its Network In The Box (NITB) mode it provides standalone
GSM 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 RTP
proxy code for handovers.
The relay forwards the media coming in from the BTS to the first MG in the
GSM core network.

3.3.3 MSC

Work from previous Project CS instances and master theses at Mobile Arts was
reused for some components.
The existing GSM codecs could in large part be used as-is. Additional message
types were required and the IPA and SCCP codecs were rewritten. The new
IPA 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 the
procedural features that the project required and its design made extending it
difficult. 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 IP
Multimedia Subsystem [12] was reused and modified to suit the requirements of
call service.

15
Chapter 4

System description

This section describes the technical details of the GSM call service. Section 4.1
describes the goal of the design and the resulting design decisions, section 4.2
discusses the system’s components and section 4.3 describes how components
interact 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 and
modular platform. The platform should offer a modular and flexible structure
that would enable future developers to extend the system and use it to develop
and debug services for GSM networks.

16
4.1.1 Signalling/Interfaces

The signalling taking place within the MUS is implemented in the form of worker
Finite State Machines. This design was chosen because the roles given in the
specifications are defined in terms of states and transitions maps directly into
Erlang/OTP gen_fsm.
The entity that sits closest to the external interfaces (A and E) is the MUS
core module. This server module decides if anything coming in from the outside
world belongs to an existing session or if one needs to be created. When a new
session is created, the module instantiates the appropriate FSM workers and
initializes 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 isolated
entities 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 a
another 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 where
the message is headed using available information it has about the session.
This allows the workers to stay agnostic about their routes towards the mobile
stations and the network, at the cost of adding some complexity to the MUS
controller.

4.1.2 Application platform

Components which can be used as applications by other GSM services are

grouped together, so that reuse of these components is possible. The Appli-
cation platform consists of Session Store, Transit Module, RTP termination
Agent, Connection Service, MGC (H.248 client) and the Operations and Main-
tenance components. Each of the components are described in detail in section
4.2.

4.1.3 Supervision

If a crash occurs somewhere in the system, it should be handled in an isolated

manner to not affect the other ongoing services. A common design pattern used
in Erlang systems is to use a supervision hierarchy.
For the GSM call service, we use such a scheme to allow a call or other service
to crash without taking anything else down with it. Combined with process
monitoring, resources pertaining to the crashed service is cleaned up by modules
further 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 of
a nanoBTS [19] and OpenBSC [11], which handles the radio communication
with the user’s MS. The Mobile User Service (MUS) handles signalling; the
application platform offers services like circuit switching and media control for
the MUS. The Application platform components provide services which can
be re-used by other GSM services. The MG together with the RTP-bridge
in OpenBSC handles audio streaming. The VLR and the HLR are used for
user management and for routing, location and access requests by the MUS.
Design considerations and decision reasoning has been described in respective
sub-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 messages
are passed on the A interface as binary blobs from the BSC to the MSC, and
vice 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 payload
to Erlang message format. It also associates every incoming message to either
an existing MUS session or a new MUS session.
An MUS session contains the session information for service requests that are
handled by the MUS. The session information keys are listed below.

Source Local Reference (SLR) A reference number which is generated and

used 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 remote
node
Circuit Identification Code (CIC) Used to identify a voice circuit.
International Mobile Subscriber Identity (IMSI) A unique identification
associated with all GSM network mobile phone users. It is stored as a 64
bit field in the SIM inside the phone and is sent by the phone to the
network

19
Temporary Mobile Subscriber Identity (TMSI) The identity that is most
commonly sent between the mobile and the network. TMSI is randomly
assigned 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 with
the matching session. Otherwise a new session is created and an MUS Controller
is started and associated with that session. The MUS Core also handles stray
messages, that is, received messages that is not associated with a session but
should normally be.

Workers

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

MUS Controller

The MUS Controller handles the creation of worker processes for every request
and routes the messages received from the MUS Core to the correct worker. It
encodes Erlang messages going to the BSC into a binary IP packet and sends
it to the TCP/IP Server. It also handles the release of the relevant SCCP
connection 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 MUS
workers.

4.2.3 Home Location Register

The HLR handles the basic MAP signalling on the C and D interfaces for
location and call procedures, refer 2.1.3 and 4.3 for further information. It
contains a operator defined subscriber white-listing which is a mapping between
an IMSI with an MSISDN. The current HLR implementation is a small Erlang
module 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 DETS
backend.

20
 IMSI
Key identifier

TMSI
Key identifier
Last TMSI update
Last time the TMSI was reallocated to decide when to update the TMSI
again
Location Area Identifier (LAI)
The current location area the MS is in
Detached
Is set true when an MS detaches or is inactive for a period of time
Location info confirmed in HLR
Whether or not the HLR has confirmed knowledge about that the MS is
currently residing in the area of responsibility of this VLR
Subscriber data confirmed by HLR
Whether the HLR has confirmed the subscriber information
Confirmed by radio
Whether the subscriber data was confirmed by the MS
Mobile Not Reachable Flag (MNRF)
Set when the MS is not reachable
MSISDN
The subscriber’s number for displaying purposes during a call

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

vlr_loc
FSM subset implementation of the Update_Location_Area_VLR pro-
cess, refer Figure 4.11 for the MSC side of the procedure. [9]
vlr_och
FSM subset implementation of OCH_VLR process. [4]
vlr_ich
FSM 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 referred
here 4.2.
A call-set up interaction involves the MUS components instructing the CS to set
up a media context. This is accomplished by seizing the virtual switches. The
Context 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 for
communicating between the two termination points requested by MUS modules
when 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 Figure

4.5. Routing of a call is done based on the dialled digits and from where the
message 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 a
new destination point code (DPC) and CIC for the outgoing connection. It
sets the originating point code (OPC) of the message with its own point code
and routes the message to its destination. There is one CIC and PC pair for
each connection and anything received on such a pair is sent to the other pair
associated with it (Figure 4.5). The TM keep track of the CIC and PC pair for
every 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 Connection
Service (CS) uses a soft-switching mechanism which is part of the application
platform.
A context is an association between a collection of terminations. A termination
is a source and/or sink for one or more streams of information. For a graphical
depiction 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 all
available terminations.
The CS interface is called by the MUS modules. Visiting MUS and Terminating
MUS are access switch users while Gateway MUS is a service switch user. More
detailed description of switch users is also provided in the 4.3.4 section.
Transcoding of the media bearers must be handled by Media Gateway. Since
RTP was used as bearer for both terminations, there was no need for transcod-
ing functionality. The Figure 4.7 explains the need for transcoding between
RTP and Switched Circuit Network (SCN) bearers. In Figure 4.7 if one of the
terminations 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 making
the next call possible. Interoperability between different types of networks is
achieved, since MG can convert between the different transmission and coding
techniques. [16, p. 6]
The available media bearers of a MG can be notified to the Media Gateway
controller (MGC). Modifying of the terminations characteristics are supported
by 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 between
the 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 to
communicate and manage MGs. Most of the commands are sent from an MGC
to MG. The exceptions are the Notify command, which is always sent from
an MG to an MGC, and the ServiceChange command, which can be sent from
either 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 terminations
can exist in a context.

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

• Subtract: Disconnects a termination from its context and returns statistics
on 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, and
statistics 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 Gateway
Controller that a termination or group of terminations is about to be taken
out of service, or has just been returned to service. A number of Service
Change Reasons have been defined which provide further details.

Media Gateway

The Media Gateway (MG) is often controlled by a separate Media Gateway

Controller which provides call control and signalling functionality.
Media Gateways understand and decipher the Megaco commands from MGC
and act according to the instruction provided.

26
Both MG and MGC are Megaco users. A MG registers itself by sending a
Service 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 resources
available. The MUS operator interface instructs the RTP termination agent
to associate CICs available with the termination identifiers. Lastly the MG
operator interface instructs the MG to add RTP terminations into the media
resource 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 manages

voice circuit information. The modules connected to this one are the MUS and
the 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 to
the 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 are
available, the RTP-TA will respond with a CIC and a termination ID for each
termination. The CIC is later used when assigning the circuit in the BSC and
the termination ID for requesting switches with the CS.
When the call is over, the terminations are released and the RTP-TA marks
them as available again.

4.2.6 Tabman

Tabman is the module performing the table management, for a process which
needs to retain its ETS-table after a crash. It does this by using the inheritance
system of ETS-tables. A process that needs to retain the ETS-table registers
tabman as the inheritor. Whenever this process crashes tabman inherits the
ETS-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

monitor
tcp_server vlr mgc_sup tabman mus

monitor

vlr_worker 1 ... vlr_worker N mgc_main mus_con

mus_worker 1 ... mus_worker N

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 the
Erlang/OTP platform are not persistent. This was solved by using a global
table manager, tabman, that uses the inbuilt inheritance feature of ETS-table
to assign a process as the heir of the table. When the worker is restarted it
checks with tabman if there is a saved table. If there is one it receives the
ownership of that table and executes with its restored state. This makes sure
that 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 if
an 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_worker
crashes, the mus_con crashes too (including all other mus_workers) informing
the mus which mus_con and thus which session crashed. This enables the mus
to do a proper clean-up.

4.3 Services
GSM call service handles the location 4.3.1 and call procedures 4.3.2 as specified
by 3GPP. [4,9] It also handles media which is provided through the Connection
Service 4.3.4 and RTP circuit emulation.

4.3.1 Location procedures

The GSM 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 area
covered by an MSC. As shown in Figure 4.9 an example of that is MSC-1
covering Polacksbacken via one BSC and two BTSs.
If an MS is turned on in the Polacksbacken area it will request itself to be
associated with the network via IMSI attach or normal updating procedure, see
Figure 4.10. This will be received by MSC-1 as an Location Updating Request
which contains the subscriber identity and forwarded to the VLR as seen in
Figure 4.11. If the subscriber is known in the VLR, the MSC will send an
Location Updating Accept message back to the MS.
If the MS isn’t known in the VLR the VLR will interrogate the HLR via the
MAP signalling seen in 4.10. If the HLR confirms the subscriber as valid the
VLR will allocate a TMSI and pass that to the MS in the Location Updating
Accept 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 specified
to send an explicit Detach indication message when it’s powered off. For each
attached subscriber, there is an implicit detach timer which upon timeout will
mark 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 Figure
4.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 resource
management 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 3
information piggybacked on the SCCP connection request message via the A
interface to the MSC.
On the MSC side the MUS Controller creates a new session and spawns an MO
worker 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 the
subscriber is allowed to make a call. This is determined by the VLR incoming
call 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 identity
request and deny or acknowledge the request.
On an identity request, the MS sends back an identity response, containing its
IMSI.
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 not
present 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 a
DTAP service accept message back on the A interface. Then the VLR instructs
the originating MSC whether it should reuse an existing TMSI or use a new
TMSI.
The originating MSC now waits for a DTAP setup message from the MS. On
a DTAP setup message the originating MSC makes a request info for outgoing
call request to the VLR on the E interface. If the call is an emergency call
the VLR rejects the call since the system does not support emergency call
handling. Otherwise the VLR checks whether the requested service is supported
and replies to the originating MSC with a complete call message. On a complete
call message, the originating MSC requests a RTP termination, sends a DTAP
call proceeding message to the MS and a BSSMAP assignment request on the A
interface to allocate the voice circuit on the BSS side.
The BSS replies with a BSSMAP assignment complete to confirm. Now the
originating MSC sends an ISUP Initial Address Message (IAM) message to the
GMSC over the E interface. The GMSC requests the necessary information
for addressing and routing the call and replies with ISUP Addressing Complete
Message (ACM) if successful, and with an ISUP Release (REL) message if failed.
The GMSC then forwards an ISUP Call Progressing (CPG) message from the
terminating MSC to indicate, that the terminating MS has received the call
and is alerting. On the ISUP CPG message the originating MSC sends a DTAP
alerting message to the MS.
On answering, the GMSC forwards the ISUP Answer Message (ANM) to the
originating MSC which completes the CS context and sends a DTAP connect
message 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 and
VLR 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 from
the GMSC. On receiving the IAM the terminating MSC sends an send info
for incoming call message via the B interface to the VLR and requests a RTP
termination from the termination agent.
The VLR incoming call handler routine checks the validity of the request and
its parameters and replies with a page MS message or a send info for incoming
call negative response back to the terminating MSC.
On a page MS message from the VLR the terminating MSC sends a BSSMAP
paging message to the terminating MS, an ISUP ACM message to the GMSC
and then it waits for the BSSMAP page response.
On a BSSMAP page response the terminating MSC makes a process access
request to its VLR and waits for the result. The VLR checks the state of the
subscriber and replies with a complete call message or a negative response.
On receiving the complete call message from the VLR the terminating MSC
sends a DTAP setup via the A interface to the MS and waits for a response to
the 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 message
to 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 inform
the originating side about the call progressing. and waits for the MS to answer
the call.
On answering the call the MS sends a DTAP connect on which the terminating
MSC 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 all
MSC instances support ISUP REL and ISUP RLC commands at any time in
the call process. On releasing the ISUP REL are forwarded to the next MSC
in the call entity chain. All MSCs release their respective media resources and
the 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 the
dialed digits and who the message originated from. The transit module does
a 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 outgoing
connection. 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 other
pair associated with it.

IMSI origin analysis The B-Number analysis consists of IMSI origin analysis
to determine the B-number Origin (BO). Here we assume the BO to be 30 which
signifies it is a call originating message. The result of the IMSI origin analysis is
sent to the Pre-Analysis, The Pre-Analysis calculates the (Origin for B-Number
Analysis (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 international
number directly to an Origin for B-Number Analysis (OBA) containing only
numbers in the international format. Pre-analysis is used as a filtering and
selection tool.

Examples (filtering)

BNT=2, B-number=0047, NAPI=0

This would be ignored since NAPI is 0 which is a reserved value.

BNT=2, B-number=0047, NAPI=1

In this case we continue in the origin specified in the table.

Examples (selection)

BNT=0, B-number=0047, NAPI=1

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

B-number analysis The analysis checks where the message is supposed to

be 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-network

the G-MSC has to request routing information from the HLR, which in turn
requests a roaming number from the VLR in which area of responsibility the
called MS is currently roaming. Our system supports roaming numbers to be
spec-compliant. On a request for routing information from the g_worker to the
HLR stub. The HLR stub requests a roaming number from the VLR. Since
the HLR is stubbed, all requests go directly to our VLR. The VLR allocates
a roaming number (refer 4.15 for details on the procedure in the VLR) for the
call 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 finished
or canceled.

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

4.3.3 Media handling

RTP circuit emulation

The project aimed to emulate a traditional E1/TDM setup in terms of media

handling using RTP over IP as the bearer. In a time division multiplexing
system the physical end-to-end connections are split into logical circuits by
giving 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 time
slots for media in every piece of interconnecting equipment. These time slots
are 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 associated
with a termination ID in the RTP-TA. The termination ID is a reference to a
semi-static RTP termination that is created by the operator in the MG.
This special type of termination is not to be confused with ephemeral RTP
terminations found in MGCP and Megaco compliant media gateways. It acts
like a physical termination, because it is moved in and out of the Null context
when 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 the
correct RTP session given through the BSSMAP assignment CIC and can start
their media communicating directly without any signalling outside of the A
interface, 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 the
BSC and MG. The MG then communicates the terminations it has added to
the 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. This
emulates a static circuit system accurately and makes it possible to use solely
the 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 to
the BSC’s running configuration.
2. Using the MG operator module, give the same RTP details to the MG
and receive a termination ID referring to a newly created termination
3. Using the MUS operator module, associate this new termination ID with
its 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 have
implemented bothway connection. Two virtual switches are joined by using the
join 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 which
would 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 element
grabbing(seize_avs) access virtual switch will result FSM to go to avs_state
again. A complete_context message from the last core network element is a
context_established state. Context is unique reference id returned back to the
core network element which completes the context.
Connection Release

Virtual switches are disjoined by using the disjoin function. Virtual ports of a
virtual switch are disconnected by disconnect function.
The FSM is in the context_established state when a context is established and
a call is ongoing. If any of the network elements decide to release connection,
they do by calling release. An access virtual switch grabbed network element
when 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 the
service switches are released. When the last network element releases the access
virtual switch the FSM goes to context_release state. In the context_release
state, 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 used
as 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 into
Megaco message of adding two terminations into a given con-
text.Megaco commands are sent over Megaco/IP to the Media
Gateway.
• When a connection is released by the Connection Service, the
subtract terminations command for a given context is sent to the
MG.
2. Update the RTP terminating agent with available resources (RTP ports)
[20] in the MG.

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

Connecting the media

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

messages from the MGC.
(a) Create contexts, Add/Remove terminations.
• Termination identifiers provided by the MGC as part of context
are used to get the termination details. Termination details are
obtained by looking up the termination details data store created
by the Operator. The Local and Remote Descriptors for a given
pair of terminations are formatted into the Megaco notation. Lo-
cal Descriptor defines the RTP ports which are opened to listen
from remote terminations. The Remote descriptors define the
remote termination entities to which the RTP data packets will
be sent to. The MG is responsible for transforming media codecs
if 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 details
into the data store. RTP ports for the local termination descrip-
tors are opened and the corresponding socket details are updated
into 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 tools
that are shipped with OTP.
For unit testing we used EUnit. In addition to unit testing we also tried the
PropEr tool. PropEr is a tool for doing model based and property testing. The
model part implies writing an abstract model of the stateful application’s side
effects and behaviour. This makes it possible to more thoroughly test servers
and state machines, which is much harder or impossible with regular unit style
testing tools.
Property testing is a new method of testing software where you don’t manually
define a set of assertions, but rather an input and output specification and
some properties of the input output relation. The tool then generates a set of
randomized 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. The
time it takes to write the models and properties was instead spent on developing
new features.
In the final code and testing rules the requirements for testing was to use EUnit
tests whenever possible.

5.1.1 Performance testing

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

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

5.1.2 Unit testing

The unit tested parts of the code is mainly the more simple generic servers and
some of the GSM codecs. The more complicated servers and state machines
turned out to be too time consuming to test the same way as they are highly
dependent 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 on
each milestone to track the progress of the overall goal, and to find the critical
crasher 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 related
to the lost MSC is deleted in OpenBSC. It is currently not cleared in our system
however, which causes inconsistency.
The easiest workaround is currently to restart the system, which purges all the
necessary state information.

5.2.2 Disconnect race condition

If the called and calling party hang up at the same time, both the release MT
and release MO sequence will start. When this happens the system becomes
unstable. Among other things, the connection service crashes. The reason is
that in its current design it expects the terminations to be released in a specific
order.
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 withstand
crashing processes in most places. An exception is the VLR and its workers
which currently takes all of its tables with it when it crashes. This means that
it 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 working
supervision structure. As it was not part of the primary requirements, work was
not put into making them withstand crashes.
A crash in the gateway causes the gateway controller in the MUS to crash and
leaves the system in an unstable state. The same thing happens if the controller
itself 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 example
Authentication and SMS) but it is written in C and there is no division between
originating, gateway and terminating MSC. [11]

6.1.2 OpenMSC

The OpenMSC [21] project provided the SMS capable MSC. GSM Call Service
could make use of the codecs retrieved from the TCP Server. TCP Server of
OpenMSC project was enhanced to encode and decode messages pertaining to
call service. VLR implemented in OpenMSC was looked into, GSM Call Service
re-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 for
Mobile Arts. The product is supposed to be used for experimentation purposes
which was reflected in the design and implementation. This enables further
work 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 the
team to commit to work while the customer was assured of an high quality
product.
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-existing
feature in commercial GSM networks is conference calls where three or more
parties are in a call together. The GSM call service architecture should allow
extending the system with conference calls. The connection service supplies
the basic tools for introducing a third party into the call through a conference
call service switch. Conference calls are closely related to Call Waiting and
Call Deflection, see 7.2.2 The Media Gateway would have to be extended with
transcoding functionalities to support combining the corresponding streams, see
7.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 allows
the user to receive a second call while in an active call. This is not currently
supported, the signalling and virtual circuit-switching are designed to work with
linear calls. However, since signalling is according to 3GPP specifications the
signalling 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 have
to be at least partly implemented to support conference calls. The conference
call initiating MS must be able to park a running call to call or answer a call
from 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-project
has open source GPRS projects running [11], this work could be used to extend
the call service with data transmissions.

7.2.4 3G support

According to [11], the OpenBSC project is planning to support 3G. As soon as

OpenBSC supports 3G it would be feasible to integrate 3G support into our call
service. The similar structure of 2G and 3G networks should allow this without
changing 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 the
call 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 calls
could an external ISUP interface make it possible to connect the call service to
other 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 support
different codecs on different hardware and to be able to manipulate voice traffic
in the media gateway. This is needed for example when doing conference calls
or 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 HLR
functionality has only been stubbed. There exists an Erlang interface for the SS7
stack provided by Mobile Arts from last year, that according to our investigation
during 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 into
this 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 be
adapted 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 error
tones or info tones depending on the cause/reason for sending tone. A tone
could 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 3
specification.
[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 - Base
Transceiver 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 Group
Services 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 Group
Core 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 Group
Core 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 Group
Core 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 Group
GSM/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 Group
GSM/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 Group
Core 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 Group
GSM 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 reason
description.
[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: Installation
instructions

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 log
information here so make sure there is enough space.
$ cd <INSTALLATION_DIRECTORY>
$ t a r x f z <PATH_TO_RELEASE_ARCHIVES>/ c a l l s e r v . t a r . gz

53
8.4 Installing the media gateway
Similarly, extract the media gateway release.
$ cd <INSTALLATION_DIRECTORY>
$ t a r x f z <PATH_TO_RELEASE_ARCHIVES>/mg . t a r . gz

8.5 Install OpenBSC

OpenBSC uses the common UNIX pattern for compiling and installation.
$ cd <TERMPORARY_DIRECTORY>
$ t a r x f z <PATH_TO_RELEASE_ARCHIVES>/openbsc . t a r . gz
$ cd openbsc
$ . / c o n f i g u r e −−e n a b l e −osmo−b s c
$ 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/ b i n /mg s t a r t

And finally OpenBSC:

$ osmo−b s c

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

54
Chapter 9

Appendix B: Maintenance
instructions

9.1 Managing circuits

9.1.1 Using the launch module

The shipped OpenBSC configuration adds 10 default terminations to the RTP

bridge and sets the media gateway IP address to localhost. To quickly add 10
circuits that use these terminations the launch module can be used.
We first attach to the MG and create the terminations there.
$ mg/ b i n /mg c o n s o l e
1> l a u n c h : assoc_mg ( ) .

They should register with the MGC and we can now attach to the MUS and
associate them with CICs.
$ c a l l s e r v / bin / c a l l s e r v c o n s o l e
1> l a u n c h : a s s o c _ c a 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 operator
interface.
In this example we add one termination with the ID "27", that listens on port
15027 and sends to port 20027.
$ mg/ b i n /mg c o n s o l e
1> Ip = i n e t _ p a r s e : ntoa ( { 1 2 7 , 0 , 0 , 1 } ) ) . % IP o f t h e h o s t r u n n i n g OpenBSC .
2> o p e r a t o r _ i n t e r f a c e : c r e a t e _ t e r m i n a t i o n ( 1 , 1 5 0 2 7 , 2 0 0 2 7 , 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 c o n s o l e
1> mus_operator : a s s o c i a t e _ t e r m i n a t i o n ( " 2 7 " , 2 7 )

We have now associated the termination with the CIC 27 in the MUS. Lastly
we need to add it in the BSC through its VTY interface. In this example we
assume 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 4242
OsmoBSC> e n a b l e
OsmoBSC# c o n f i g u r e t e r m i n a l
OsmoBSC( c o n f i g )# msc
OsmoBSC( msc)# mg 1 2 7 . 0 . 0 . 1
OsmoBSC( msc)# c i c 27 20027 15027

As can be seen above the port numbers are reversed on the BSC since we want
to 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 Reasons
1 SingleCall_MO_release Passed
2 SingleCall_MT_release Passed
3 SingleCall_MO_MT_release_same_time Passed
4 SingleCall_MO_MT_alerting_timeout Passed
5 SingleCall_MO_alerting_release Passed
6 SingleCall_MT_alerting_release Passed
7 SingleCall_MO_early_release(before paging response) Passed
8 SingleCall_MT_not_registered_in_VLR Passed
69 SingleCall_MT_not_registered_in_HLR Passed
70 SingleCall_MT_is_absent_in_VLR Passed
9 SingleCall_MO_external_call(Should display phone number not valid) Passed
10 SingleCall MO – TM + 00 Passed
11 SingleCall MO – TM + Invalid Number Passed
12 SingleCall MO – TM +Number Passed
13 SingleCall_MO_subscriber_call_not_allowed Passed
14 SingleCall_MO_MT_Cic_blocked Passed Actual circuit blocking is unsupported, but assignment failure
was tested and is working.
15 SingleCall MO_MT_alerting_release_same_time Passed
58

16 USSD Passed Message appears: mo_worker <0.126.0>: wf_clear_complete –

Unhandled Msg {use_existing_tmsi}
17 SMS Passed Message appears: mo_worker <0.126.0>: wf_clear_complete -
Unhandled Msg {use_existing_tmsi}
67 Successful call setup with voice Passed

While a call is running

18 MultiCall_MO_release Passed
19 MultiCall_MT_release Passed
20 MultiCall_MO_MT_release_same_time Failed Starts both MO and MT release sequences. CS gets confused.
21 MultiCall_MO_MT_alerting_timeout Passed
22 MultiCall_MO_alerting_release Passed
23 MultiCall_MT_alerting_release Passed
24 MultiCall_MO_early_release(before paging response) Passed
25 MultiCall_MT_not_registered_in_VLR Passed
72 MultiCall_MT_not_registered_in_HLR Passed
26 MultiCall_MT_subscriber_call_not_allowed Passed
27 MultiCall_MO_MT_Cic_blocked Passed
 28 MultiCall_MO_number_invalid Passed
29 MultiCall_MO_external_call(Should not crash) Passed
30 MultiCall_MO_MT_alerting_release_same_time Passed
71 MultiCall_MT_is_absent_in_VLR Passed
31 USSD Passed
32 SMS Passed
33 MultiCall MO – TM + 00 Passed
34 MultiCall MO – TM +Number Passed
35 Imsi Attach Passed
36 Imsi Detach Passed
68 Successful call setup with voice Passed

Generic Cases
37 Call a person who is in an active MO-MT call Passed
38 Call a person who is in an active MO-MT call and release Passed
39 MO-MT call where A-Number is equal to the B-Number(Calling yourself) Passed Isn't exactly handled, but it does not crash anything. The MS is
paged and the paging response is ignored and SCCP cleared.
40 MO-MT call where A-Number is equal to the B-Number(Calling yourself) and Passed See above.
release
59

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

Test Cases for Supplementary Services

45 Call Hold – Should not crash Passed
46 Invocation of a multiparty call before basic call – should handle no Passed
unexpected behaviour
47 MSA/MSB sets call forwarding option Passed
48 MSA/MSB sets call waiting option Passed

VLR/HLR tests
50 Location Info Not confirmed (make HLR unhappy) – System should work as Passed
expected / Shouldn't crash
51 MO_Call Subscribe who detached Passed
52 MO_MT Call each other Passed
53 Implicit detach timeout Passed
54 Roaming Number not found(Simulate by removing entries from Passed
roaming_number dets table)
 57 Location update for subscriber that is known to HLR and VLR Passed
58 Location update for subscriber that is known to HLR but not VLR Passed
59 Location update for subscriber that is not known to HLR or VLR Passed
60 Periodic location update for subscriber that is known to HLR and VLR Passed
61 Periodic location update for subscriber that is known to HLR but not VLR Passed
62 Periodic location update for subscriber that is not known to HLR or VLR Passed
63 Explicit IMSI detach for subscriber known to VLR Passed
64 Explicit IMSI detach for subscriber not known to VLR Passed
65 Implicit IMSI detach for subscriber known to VLR Passed
66 Implicit IMSI detach for subscriber not known to VLR Passed

Robustness tests
73 Call worker crashes, other sessions and their data should survive Passed
74 Session Store crashes, all sessions and data should survive Passed
75 TM or TM dbs crashes, all sessions and data should survive Passed
76 RTP TA crashes, all sessions and data should survive Passed
77 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 OCH, ICH and LOC worker takes down the whole VLR and its
tables.
60

79 MUS crashes, all sessions and data should survive Passed

80 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 Failed MGC tries to register a megaco user again and fail.
83 Connection Service crashes, other sessions and their data should survive Passed
84 Tabman crashes, all sessions and data should survive Failed Things will keep running until something that uses tabman
crashes, which will go unnoticed by the new tabman.
85 MUS Controller dies, other sessions and their data should survive Passed
86 Location worker crashes, other sessions and their data should survive Passed