Product report GSM Call Service

(1)

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

(2)

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.

(3)

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

(4)

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

(5)

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

(6)

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 management.

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.

(9)

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.

(10)

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 contains 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).

(11)

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).

(12)

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 terminating 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.

(13)

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 management procedures. [2]

A

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 protocol 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.

B

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

C

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.

(14)

D

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

E

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.

(15)

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

(16)

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 working 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)

(17)

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.

(18)

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.

(19)

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 framework 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 routing 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 communicate directly on the external interfaces. They instead send their information 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.

(20)

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.

(21)

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 connection 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

(22)

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 allocation, 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.

(23)

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 process, 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]

(24)

4.2.5 Application platform

Following section will describe application platform components in a more detailed 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 terminations 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

(25)

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

(26)

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 currently 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 transcoding 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

(27)

Figure 4.7: H.248 Connection Model

(28)

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.

(29)

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).

(30)

4.2.7 Supervision structure

m u s _ s u p

m g c _ s u p m u s

t c p _ s e r v e r vlr t a b m a n

m g c _ m a i n

...

m u s _ w o r k e r 1 m u s _ w o r k e r N

v l r _ w o r k e r 1 vlr_worker N m u s _ c o n

m o n i t o r m o n i t o r

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

(31)

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.

(32)

Figure 4.10: IMSI attach signalling sequence.

(33)

Figure 4.11: FSM of MSC location procedure.

(34)

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 procedures 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

(35)

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.

(36)

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

(37)

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

(38)

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 information 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.

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

Examples (selection)

BNT=0 represents an unknown number and thus OBA is 30.

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

(39)

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

(40)

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.

(41)

Figure 4.17: RTP circuit.

(42)

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

(43)

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 connection release mechanism.

Connection Setup

A virtual switch having two ports can be connected either in bothway or backward 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.

(44)

Figure 4.19: Connection Service - Finite State Machine

(45)

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 descriptors are opened and the corresponding socket details are updated into the termination details data store.

(46)

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.

(47)

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.

(48)

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.

(49)

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.

(50)

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.

(51)

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 corresponding 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.

(52)

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 functionality 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.

(53)

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.

08_series/08.58/0858-700.zip, 1998. Base Station Controller - Base Transceiver Station (BSC - BTS) interface; Layer 3 specification.

23_series/23.002/23002-700.zip, 2005. Technical Specification Group Services and Systems Aspects; Network architecture.

23_series/23.018/23018-700.zip, 2005. Technical Specification Group Core Network and Terminals; Basic call handling; Technical realization.

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.

29_series/29.002/29002-700.zip, 2005. Technical Specification Group Core Network and Terminals; Mobile Application Part (MAP) specification.

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.

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.

23_series/23.003/23003-700.zip, 2006. Technical Specification Group Core Network and Terminals; Location management procedures.

Product report GSM Call Service