
2/68


3/68

Teknisk- naturvetenskaplig fakultetUTH-enheten

Besksadress:ngstrmlaboratorietLgerhyddsvgen 1Hus 4, Plan 0

Postadress:Box 536751 21 Uppsala

Telefon:018 471 30 03

Telefax:018 471 30 00

Hemsida:http://www.teknat.uu.se/student

Abstract

GSM Voice Mail Service TDM Call Control

Ebby Wiselyn Jeyapaul

The Voice Mail Service (VMS) enables forwarding of calls to a dedicated VoiceMail Server (VMS) on behalf of the call receiving subscriber during certain conditionssuch as 'busy subscriber', 'no answer', 'always', etc.

The standardization forum 3GPP has specified the Global System for Mobilecommunication (GSM) while the standardization forum ITU-T has specified theIntegrated Services Digital Networks (ISDN) User Part (ISUP) call control protocol.Both of these standards rely on the use of Time Division Multiplex (TDM) as amedia bearer and SS7 as signalling bearer, where both bearers require use of veryexpensive telecom-specific hardware.

The thesis proposes the solution to use RTP as media bearer and IP as signallingbearer towards the handset in GSM and only use TDM as media bearer and SS7

as signalling bearer towards the VMS.

The thesis demonstrates the feasibility and the advantages provided, by creatingan implementation in Erlang/OTP and testing it to check if it confirms to thespecification.

Tryckt av: Reprocentralen ITCIT 12 072Examinator: Lisa Kaatimnesgranskare: Ping Wu

Handledare: Lars Kari


4/68


5/68

Acknowledgements

This master thesis would not have been possible without the guidance and helpof my supervisor Lars Kari, and my reviewer Ping Wu. I would like to thank allmy friends and family who supported me during my stay and study in UppsalaUniversity.


6/68

Glossary

3GPP The 3rd Generation Partnership ProjectAbis Abis interface, Radio Signalling LinkA-law Alaw algorithmAN Access Network

BSC Base Station ControllerBSS Base Station SubsystemBSSMAP Base Station System Management Application Sub-partBTS Base Transceiver StationCAMEL Customized Applications for Mobile network Enhanced LogicCEPT European Conference of Postal and Telecommunications

AdministrationsCF Call ForwardingCFB Call Forwarding BusyCFU Call Forwarding Unconditional

CFNRc Call Forwarding Not ReachableCFNRy Call Forwarding No ReplyCIC Circuit Identification CodeCN Core NetworkCS Connection ServiceDPC Destination Point CodeDTAP Direct Transfer Application PartDTMF Dual Tone Multi-frequencyE-Mail Electronic MailE1 European-carrier 1

EFR Enhanced Full RateETSI European Telecommunications Standards InstituteG-MSC Gateway Mobile-service Switching CentreGSM Global System for Mobile CommunicationGTH Generic Telecom HardwareHLR Home Location RegisterIAM Initial Address Message

6


7/68

IMSI International Mobile Subscriber IdentityINAP Intelligent Network Application PartIP Internet Protocol

ISDN Integrated Services Digital NetworkISUP ISDN User PartITU-T The ITU Telecommunication Standardization SectorM3UA MTP Level3 User Adaptation LayerMA Mobile ArtsMAP Mobile Application PartMAF Mobile Additional FunctionMCC Mobile Country CodeMNC Mobile Network CodeME Mobile Equipment

MG Media GatewayMGC Media Gateway ControllerMMS Multimedia Messaging ServiceMS Mobile StationMSC Mobile-service Switching CentreMSISDN Mobile Subscriber Integrated Services Digital Network NumberMSU Message Signalling UnitMTP Message Transfer PartMUS Mobile User ServiceNSS Network Switching Subsystem

OPC Originating Point CodePLMN Public Land Mobile NetworkPOTS Plain Old Telephony SystemsPSTN Public Switch Telephone NetworkRSL Radio Signalling LinkRTP Real-time Transport ProtocolSCP Service Control PointSCCP Signalling Connection Control PartSCTP Stream Control Transmission ProtocolSIGTRAN Signalling TransportSIM Subscriber Identity ModuleSMS Short Message ServiceSS Supplementary ServiceSS7 Signalling System 7TCAP Transmission Capability Application PartTDM Time Division MultiplexingT-MSC Terminating Mobile-service Switching Centre

7


8/68

TM Transit ModuleTMSI Temporary Mobile Subscriber IdentityNDUB Network Determined User Busy

UDUB User Determined User BusyUSSD Unstructured Supplementary Service DataV-MSC Visiting Mobile-service Switching CentreVLR Visitor Location RegisterVM Voice MailVMS Voice Mail Service

8


9/68

Contents

1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Motivation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3 Purposes And Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 61.4 Thesis Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 GSM Overview andSS7 Protocols 82.1 GSM Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 Access Network . . . . . . . . . . . . . . . . . . . . . . . . . 102.1.2 Core Network . . . . . . . . . . . . . . . . . . . . . . . . . . 112.1.3 Location Procedures . . . . . . . . . . . . . . . . . . . . . . 132.1.4 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Signalling System 7 Protocols Overview. . . . . . . . . . . . . . . . 15

2.2.1 M3UA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.2 Integrated Services Digital Network (ISDN) User Part. . . . 172.2.3 Mobile Application Part (MAP) . . . . . . . . . . . . . . . . 19

2.3 GSMCall Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3 GSM Voice Mail Service and its Call Control 223.1 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2 System Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.3 Media Control Integration . . . . . . . . . . . . . . . . . . . . . . . 28

4 Design 29

4.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2.1 Mobile User Service. . . . . . . . . . . . . . . . . . . . . . . 354.2.2 VLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.2.3 MAPHandlers . . . . . . . . . . . . . . . . . . . . . . . . . 384.2.4 Transit Module . . . . . . . . . . . . . . . . . . . . . . . . . 394.2.5 Connection Service . . . . . . . . . . . . . . . . . . . . . . . 39

i


10/68

4.3 Call Control Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . 404.3.1 Map Handler Signals . . . . . . . . . . . . . . . . . . . . . . 404.3.2 VLRInterface . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.3.3 HLRInterface . . . . . . . . . . . . . . . . . . . . . . . . . . 414.3.4 MUSInterface. . . . . . . . . . . . . . . . . . . . . . . . . . 414.3.5 Connection Server Interface . . . . . . . . . . . . . . . . . . 414.3.6 ISUPAccess Handler TietoISUPstack . . . . . . . . . . 414.3.7 Transit Module ISUP access handler. . . . . . . . . . . . 42

4.4 Handling Bearer Differences . . . . . . . . . . . . . . . . . . . . . . 434.4.1 ISUP Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 43

5 Implementation And Test 455.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.2 Environment Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.3 Implementation Groups . . . . . . . . . . . . . . . . . . . . . . . . 475.4 Design Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.5 Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6 Discussions & Conclusions 516.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526.2 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526.4 Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7 Future Work 54

ii


11/68

Chapter 1

Introduction

1


12/68

1.1 Background

The first generation cellular systems had a diverse growth in the early 1980s, each

development was incompatible with other existing ones at that time. Global Sys-tem for Mobile Communication (GSM)is a standard set developed by EuropeanTelecommunications Standards Institute (ETSI) to describe protocols for secondgeneration (2G) cellular networks (that are digital). It was formed by the EuropeanConference of Postal and Telecommunications Administrations (CEPT) to studyand develop a pan-European public land mobile system.

Phase 1 of theGSM was published in 1990, and resumed with the service the fol-lowing year. GSMevolved from a European standard to being over operational inmore than 100 countries around the world. After a span of over four years, there

were over one million subscribers worldwide, having had a gigantic expansion ofover 50 million subscribers in the next 3 years.

GSM provides compatibility withISDNservices, and bearer signalling, teleserviceand supplementary services, with telephony being the heart of all the services,using digital encoding and transmission of speech.

The telephony services use the capabilities of a bearer service to transport data,which defines the resource capabilities required for the call. Voice calls are thebasic services which are supported with Full-rate speech with 13kbps along withemergency calls.

Short messaging services allows subscribers to send and receive text messages onthe GSM handset. Provided above the bearer and teleservices are the supplemen-tary services, offering number identification, call forwarding services, call barring,call hold, call waiting and conference services.

External systems in the GSM network like the Voice Mail Service (VMS) pro-vide facility for subscribers to leave their message in the recipients mailbox. Thisgives the subscriber more control to manage their inflow of calls, and user absence.Voice mail systems are usually made compatible with GSM, UMTS, and CDMA

networks.

Signalling System 7 (SS7) is a set of telephony signalling protocols(messages) whichare used to setup most of the worlds public switched telephone network telephonecalls. SS7is mainly used to set up, supervise and tear down telephone calls. It isalso employed for Short Message Service (SMS), number translation services, localnumber portability, and other market services. SS7 is the core signalling backbone

2


13/68

of telephony networks around the world, used by a variety of networks includingGSM,ISDN,Public Switch Telephone Network (PSTN), Intelligent Networking,etc.

The following figure (Fig1.1) presents an overview of a GSM Network and its con-nection toISDNand Plain Old Telephony Systems (POTS) throughSS7signallingbearer. The details onGSMandSS7are given in chaper 2.

Figure 1.1: SS7 and GSM Network. [1]

The standardization forum The 3rd Generation Partnership Project (3GPP) hasspecified the GSM while the standardization forum The ITU Telecommunica-tion Standardization Sector (ITU-T) has specified the ISDN User Part (ISUP)call control protocol. Both of these standards rely on the use of Time DivisionMultiplexing (TDM) as a media bearer andSS7as signalling bearer, where bothbearer require use of very expensive telecom-specific hardware. A cheaper optionwould be to always use Real-time Transport Protocol (RTP) as media bearer and

3


14/68

Internet Protocol (IP) as signalling bearer towards the handset in GSMand onlyuseTDMas media bearer andSS7as signalling bearer toward theVMS.

Thus, it would be interesting to investigate the possibility to implement the callcontrol part of a Voice Mail (VM) call forwarding service in an existing GSMcallservice environment usingRTPas media bearer andIPas signalling bearer towardthe GSM handset and using TDM as media bearer and ISUP/SS7 as signallingbearer towards theVMSapplication server.

To run SS7 protocols over IP, one can use MTP Level3 User Adaptation Layer(M3UA) adaptation [14], which was studied during the Project CS 2011 coursein Uppsala University, and used to to develop the GSM Call Service. GSM CallServiceprovides a vendor independent, low cost, IP based solution, for calls, sub-

scriber management and additionalGSMservices.

The existing GSM Call Serviceenvironment is provided by Uppsala UniversitysComputer Science project course 2011 including an existing GSM Home Loca-tion Register (HLR) provided by Mobile Arts where SS7 shall be used as sig-nalling bearer between the Mobile-service Switching Centre (MSC)/Visitor Loca-tion Register (VLR) and the Home Location Register (HLR). The VMS applica-tion server is also provided by Mobile Arts.

4


15/68

1.2 Motivation

Since BothGSMandISUPspecify signalling and media bearers that rely on ex-

pensive telecom hardware, there is a increasing need for cheaper alternatives thatcan be used as bearers for both signalling and media. This has a cost advantageif traditionalSS7links are replaced byIPconnections.

The motivation for the thesis is to find ways to develop frameworks, that can enableGSMto be used under academic environments, and for creating test frameworks totest existing GSM systems using ISUP/IPas signalling bearer, and RTP as mediabearer instead of expensive telecom-specific hardware. The thesis also attempts toadd the body of knowledge to the ongoing research on M3UAsystems.

5


16/68

1.3 Purposes And Goals

The goal of this thesis work is to investigate the possibility of creating the call

control parts ofVMCall forwarding service, in an existing GSM call service en-vironment. It also contributes to the existing body of knowledge of MTP Level3User Adaptation Layer about how to integrate both pure SS7 and M3UAcompo-nents.

The goal of the thesis is also to add a new feature to the existing GSM Call Ser-vice, supporting call forwarding, call deflection, transcoding, and external ISUPhandling. This includes making the existing GSM Call Service to be more realworld specific, where it can be applied as a testing framework

The thesis work will be co-ordinated with another concurrent thesis work thataims to handle the media control part of theVMservice, thus handling the me-dia bearer differences(codecs and transmission rates), betweenTDMused as thebearer towards theVMSandRTPused as the bearer towards theGSMhandset.The thesis work requires close co-operation with the system design at Mobile Arts.

The thesis serves particularly as a test framework, for testing the existing VMSapplication service in Mobile Arts Stockholm.

6


17/68

1.4 Thesis Structure

The rest of the thesis is organized in the following manner.

Chapter 2 describes GSM overview and the different protocols in the SS7 network.

Chapter 3 describes the call control use cases, the system capabilities for a callcontrol, and the media control integration necessary for the system to function.

Chapter 4 describes the design of the GSM VMS system

Chapter 5 describes the system implementation

Chapter 6 discusses and concludes the thesis work

Chapter 7 describes the possible future work associated with this research

7


18/68

Chapter 2

GSM Overview andSS7Protocols

8


19/68

TheGSMoverview is presented for readers to get a understanding ofGSMsys-tems their interworking and the different protocols involved. The SS7overview ispresented to describe in brief the different SS7protocols and their interworking.

2.1 GSM Overview

GSMNetwork is a digital cellular network offering a number of services like call,SMS , fax, voicemail, and other supplementary services, with higher capacity andwith optimal allocation of the radio spectrum.

TheGSMnetwork is structured into different entities like the Core Network (CN),and the Access Network (AN). The CN, handles the core switching services, and

mobility management. The AN interfaces with the mobile stations and the CN.

The functionalities of GSM network is specified by the call and the location pro-cedures that are available in the CN, which list and categorize the different typesof calls and location based services that are available in GSMnetwork.

GSM Network has different interfaces between its different elements. The interfacesare provided for facilitating information exchange, and for providing compatibilityfor different network elements from different manufacturers.

Figure2.1shows a GSM system composed of Mobile Stations (presented in 2.1.1),

an Access Network (presented in2.1.1), and a Core Network (presented in 2.1.2).

9


20/68

Figure 2.1: GSM Overview. [2]

2.1.1 Access Network

The access network as the name states is for providing access to the mobile net-work. The access network handles the traffic and signalling between a mobile phoneand Network Switching Subsystem (NSS)(also known as theCN). It also managesallocation of radio channels, paging, transmission, reception and transcoding ofspeech channels.

The access network which is also called the Base Station Subsystem (BSS) consistsof Base Transceiver Station (BTS) and Base Station Controller (BSC).

TheBSCcontrols a group ofBTSes. TheBTSis the base station which provideswireless communciation between mobile phones and the core network. TheBTSis placed in the center of the cell, and its transmitting power affects the size of thecell. The BTS provides encoding, mutiplexing, modulating, and feeding the RFsignals to the antenna. It also performs transcoding and rate adaptation .

10


21/68

The BSC manages the radio resources for the BTS, it is the link between themobile station and the core network. TheBSC handles the resources needed byassigning and releasing the frequencies that are required by a Mobile Station (MS).

The elements in the access network can be tracked to a Public Land MobileNetwork (PLMN). A PLMN is a network identified by a Mobile Country Code(MCC) and a Mobile Network Code (MNC) which are managed and authorizedby a managing entity with a purpose of providing telecommunication services. Allthe identifiable collection of devices and software that are used in the PLMN iscategorized as theMS.

AnMSconsists of two important parts a Mobile Equipment (ME) and a SubscriberIdentity Module (SIM). MEcontains devices for transmission, reception, proto-

col handling and user interfaces. TheSIMis a smart card containing the profileinformation of the user, users contacts, and other information. TheSIMis pro-vided to be detachable and can sometimes be reused with the handsets providedby different operators.

To provide anonymous(private) identification for subscribers in the GSM network,during call routing or roaming,GSMuses two unique identifiers. International Mo-bile Subscriber Identity (IMSI) is used as a 64 bit identifier, and is sent originallyfrom the mobile phone to theGSMnetwork. To increase security, and to preventeavesdropping and tracking, Temporary Mobile Subscriber Identity (TMSI) is used

as the identifier whenever anIMSIis required.

The subscribers mobile number is called as the Mobile Subscriber Integrated Ser-vices Digital Network Number (MSISDN). TheMSISDNis the public identity ofa subscriber, this is the number you get to share it with your contacts as yourcontact(mobile) number. TheMSISDNwith theIMSIare the two numbers usedfor identifying a subscriber in the GSMnetwork.

2.1.2 Core Network

The core network performs call switching, routing and mobility management func-tions like roaming, and location based services. The essential elements of the corenetwork are MSC, HLR, and VLR.

TheMSCis a digital switching center conducting normal switch tasks and manag-ing the network it performs the delivery service and is the main routing entity intheCN. EachMSCusually control severalBSCs, it works through the interfaces

11


22/68

A and E, for setting up calls and managing subscribers. TheMSCis in charge ofall the signalling required for setting up, maintaing, tearing down connections inaccordance withSS7protocols.

The mobile originating call is handled by the Visiting Mobile-service SwitchingCentre (V-MSC), this is the landing module for the incoming calls. The calls whichare towards the terminating subscriber(recipient) are handled by the TerminatingMobile-service Switching Centre (T-MSC). The gateway routing, call routing de-cision logic are handled by the Gateway Mobile-service Switching Centre (G-MSC).

To store all the subscriber information in theGSMnetwork, service control pointslike theHLRare used. HLRis the central subscriber database storing all subscriberinformation, call forwarding information, service information, and subscriber lo-

cation areas. HLR provides the subscriber information, and the required autho-rization checks during the setup of the call. The HLRuses the Mobile ApplicationPart (MAP) protocol to exchange information with the communicating entities.

To reduce the load of the HLRand to help provide a location based storage, theVLRis used. VLRis used to lookup subscriber information, and call forwardinginformation. TheVLRusually contains the subscribers associated with region theMSCserves. Subscribers move in and out of a region during roaming, theVLRupdates the subscribers who roam into the region managed by the MSCin whichtheVLRis associated.

Call setup procedures in the GSMfollow a set of protocols for how calls shouldbe handled in a GSM network. Call Procedures are involved in Originating, Gate-wayandTerminating calls. TheOriginatingcall procedures are for handling callsthat originate from the network where the switch(MSC) is associated with. TheGatewaycall procedures are for handling calls passing through the gateway MSC,and the Terminatingprocedures for handling calls that terminate(or end), in thenetwork associated with the switch(MSC).

In particular(for case in Figure 2.1), the V-MSCis responsible for the handlingof call setup protocols likeISUP,BSSmanagement protocols like BSSMAP, anddirect transfer protocols like DTAP. The V-MSC receives the initial call setuprequest, with the various call setup parameters, the type of request, and the re-sources required. The V-MSC performs various subscriber and network statuschecks. The VLRwhich contains the details of the subscriber, decides whetherthe call can proceed. The V-MSC uses ISUP/IP signalling bearer to route thecurrent call toG-MSC, through a transit module.

12


23/68

The G-MSC handles the gateway functions, It determines the routing and thetransit logic of the call. It routes the incoming call through a transit module after

the HLR routing checks. TheHLR performs the required authorization checks,and tries to validate the call. TheHLRalso looks up the roaming number of thecalled party to complete the call.

To handle calls terminating(or incoming), theT-MSCmodule plays the role. TheT-MSCnotifies the subscriber of the incoming call, sets up the resources requiredfor the call, handles allocation of radio resources required for the terminating sub-scriber to accept the completion of the incoming call [18].

Transit Module

The routing of the messages between the different MSCmodules is done by thetransit module. The transit module performs the number analysis, and deter-mines the transit route of the call. The Transit module is also expected to handleISUP/SS7requests to route to externalSS7Networks [18].

2.1.3 Location Procedures

The location procedures module handle the registering and deregistering of sub-scribers to a network. The location information is stored in theVLRand theHLR.

TheVLRandHLR exchange information using theMAPprotocol [18].

2.1.4 Interfaces

Figure 2.2: Signalling protocol stack over A and E Interface

13


24/68

GSM provides theAbis interface for setting up and managing radio links. RadioSignalling Link (RSL) is used over the Abis interface between theBTSand theBSC. The interface located between the MSC and the BSS is called the A in-

terface, The A interface supports muliple application parts like the Base StationSystem Management Application Sub-part (BSSMAP) and the Direct TransferApplication Part (DTAP).

The interface between theVLRand theMSC is called the B interface. All sig-nalling with theVLRis done over the B interface using theMAPprotocol [5]TheVLRis interrogated by the MSCduring the call setup and the location handlingprocedures. Supplementary services are also handled and setup through the Binterface. [3,4]

The interface located between theHLRand theG-MSCis called the C interface.The routing information, and the location updates are transferred through the Cinterface during the call setup. The interface located between the VLRand theHLRis called the D interface, there is a exchange of location and subscriber man-agement information using the D interface.

TheMSCcommunicates with an another MSCusing the E interface. TheISUPprotocol is used to communicate over the E interface.

14


25/68

2.2 Signalling System 7 Protocols Overview

Figure 2.3: SS7 and SIGTRAN protocol stack

SS7 is a set of telephony protocols which are used in the majority of the PSTNnetworks to setup, teardown telephone calls. TheSS7protocol stack for cellular-specific services consists of Signalling Connection Control Part (SCCP), MessageTranfer Parts, and also a Stream Control Transmission Protocol (SCTP) transportmechanicsm. The entire suite of protocols associated with SS7is called SignallingTransport (SIGTRAN).

Message Transfer Part (MTP) is used for reliable communication in the SS7. Italso takes care of messages being non-duplicated and delivered in sequence be-tween the different communication entities in theSS7.

MTP has three levels, the lowest level defines the characteristics of the digitalsignalling link, with physical interfaces (E1, T1, DS-1, V.35). MTP Level 2provides end to end delivery with features like flow control, and validatation of

15


26/68

message sequences. MTP Level 3 provides message routing between the varioussignalling points in theSS7network. MTPuses a routing label for message rout-ing, the routing labels are Originating Point Code (OPC), and the Destination

Point Code (DPC).

SCCPis used to provide both connection oriented and connectionless network ser-vices in anSS7network. SCCPalso acts like a transport layer for TransmissionCapability Application Part (TCAP) services. All the non-circuit related infor-mation that needed to be exchanged are done using the TCAP protocol. Thishappens between the various signalling points in the SS7network. TCAPis de-livered usingSCCP connectionless service. TCAPmessages are contained withinthe SCCP portion of an Message Signalling Unit (MSU). A TCAP message iscomprised of a transaction portion and a component portion.

16


27/68


28/68

Calling Party

CIC

The parameters for call forwarding are

Redirecting Information

Called Number

Calling Number

Forwarding Number

Redirection count

Generic Number

Original Called Number

Cause Indicator

Redirection number contains the forwarding subscribersMSISDN,the called num-ber is theMSISDNwhere it is being forwarded to, the redirection count has thenumber of times a particular call is being forwarded.

TheISUPaccess handler maps the ISUP IAM message to theISUPsetup request

and sends to theVMShandler through the SS7 stack.

Call Proceed Indication

In the GSM Call Service, the call proceed is notified by two ISUP messages [6],

ISUP ACM

ISUP CPG

ISUP ACM is the address completion message sent by the GSM call service to

both the originating and the termination BSCs to setup the alerting(ringing) inthe mobile subscribers phone.

ISUP CPGIs the call progress message.

18


29/68

CIC Allocation

The allocation ofCICto individual circuits is determined by bilateral agreement

in accordance with applicable predetermined rules [15].

The 5 least significant bits of a CICrepresents the timeslot assigned to the com-munication path, and the four spare bits are for CIC extension.

Call Confirm

In theGSM call service, the call confirm is notified by ISUP ANM Message, whichis the ISUP answer message.

This is the phase where the alerting stops, indicating that the terminating sub-

scriber has answered the call, this is also the phase where the media is setupbetween the calling and the called party [6].

In the VMS, the call confirmation is notified by ISUP setup confirm message.This is when the VMS starts playing the welcome prompt, and starts recordingthe voice mail.

Call Release

The call is released using ISUP release and ISUP release complete, ISUP release

contains the cause, which indicates the reason for the release.

2.2.3 Mobile Application Part (MAP)

Communication between theG-MSCand theHLR, and between theVLRand theHLRis done based on theMAPprotocol.

TheHLRis a Service Control Point (SCP) in the SS7 network, configured to han-dleMAPmessages from theVLRand theG-MSC.

In the B interface, theMAP/IPis used, which needs to be mapped to MAP/SS7.

MAP messages are used for supplementary service handling, for setting up thesubscriber supplementary services configuration like call forwarding handling, ac-tivating, deactivating, provisioning and erasing basic services for a subscriber.

MAP messages also play a role in Routing, Location handling, Retrieving infor-mation for handling incoming and outgoing calls, the information specifies how

19


30/68


31/68

2.3 GSMCall Service

GSM call servicedeveloped during the course Project CS 2011[19], will be en-

hanced and integrated with Mobile Arts (MA)VMS.[18].

GSM call serviceprovides anMSCswitch functionality for voice calls withRTPas media bearer, andISUPoverIPas signalling bearer.

GSM call service does not support supplementary service functionalities, bearercapability for European-carrier 1 (E1)/TDM links, and SS7 signalling messageslike (ISUP, MAP, TCAP), which are required for VMS control over E1/TDMlinks.

Note thatISUPinGSMCall Service is provided through Erlang messaging only.

21


32/68

Chapter 3

GSM Voice Mail Service and itsCall Control

22


33/68


34/68

(CFU) supplementary service to forward all incoming calls for the specifiedbasic service(s)[11,12].

Call Forwarding BusyThe served mobile subscriber can use the Call Forwarding Busy (CFB)supplementary service, to forward incoming calls if the mobile is deter-mined Network Determined User Busy (NDUB) or User Determined UserBusy (UDUB) for the specified basic service(s). [11,12]

Call Forwarding On No ReplyThe served mobile subscriber can use the Call Forwarding No Reply (CFNRy)supplementary service, to forward incoming calls if the call is not answered

within the period defined by the no reply condition timer for the specifiedbasic service(s). [11]

Call Forwarding On Not ReachableThe served mobile subscriber can use the Call Forwarding Not Reachable(CFNRc) supplementary service to forward incoming calls if the mobile sub-scriber is not reachable. [11]

Call Forwarding Multiple Hops

The system may support scenarios where call forwarding happens betweenmultiple subscribers defined in multiple number of hops.

VMS ServicesGSM Call ServiceVMSintegration should support deposit and retrieval ofvoice mail messages

Dual Tone Multi-frequency (DTMF) services should be supported to enableVMScommunication

DTMFservices may support configuring VMSsubscriber options like sub-

scriber type, service keys, white listing, black listing, subscriber information,fax number, greeting messages, avatar ..etc

DTMF services may support configuring VMS subscriber profile optionsof setting Electronic Mail (E-Mail), Multimedia Messaging Service (MMS),SMS,and fax notification options.

24


35/68

Call Forwarding Handling [12]

Registration

Subscriber can register the forwarded to number, and the information as towhether all calls or all calls of a specific basic service should be forwarded.

ErasureErase a previous registration

The subscriber can specifically erase a previous registration with anappropriate control procedure.

The subscriber can register information for a particular supplementaryservice using another directory number.

The network administrator can withdraw a supplementary service.

ActivationSubscriber can be allowed activation to all subscribed basic service groupsagainst which a supplementary service code is registered. Service shall besubscribed and registered.

DeactivationSubscriber can deactivate to a previous activation, and register informationfor a Supplementary Service (SS)-code by overriding, or deactivate by with-drawal.

InterrogationSubscriber can obtain information about the data stored in the PLMN, in-formation such asSS-status, the associated forwarded-to number.

25


36/68

3.2 System Capabilities

The following are the call control features from a system perspective

V-MSC FeaturesV-MSCshould be able to handleDTAPCall Forwardinghandling messagesand map it to correspondingMAPmessages in theVLRforCFU,CFNRc,CFNRy,andCFB.

TheV-MSCshall also provide support for DTMF signalling messages, CICallocation and deallocation.

G-MSC FeaturesThe G-MSC should be able to provide an external MAPhandler for map

incoming and map outgoing requests.This is where the signalling bearer dif-ferences between MAP/SS7 and MAP/IP are handled.

G-MSCshould also provide support for call forwarding notification messages.[12]

Terminating Mobile-service Switching Centre FeaturesT-MSCshould provide support for handling external ISUP through ISUPaccess handler, andDTMFsignalling support.

ISUPAccess HandlerISUPaccess handler should be able to use theSS7Tieto stack forISUP/SS7handling, and should handleCICprovisioning.

It also should provide means to convert ISUP/IP to ISUP/SS7 and viceversa. The signalling bearer differences betweenISUP/IPandISUP/SS7arehandled by this module.

VLR RequirementsVLRshould handleCFB using the Mobile Additional Function MAF008[7]

authorizations examination, where authorization routines for CFBis speci-fied.

TheVLRshould handleCFNRyusing Mobile Additional Function MAF009[7]authorizations examination, where authorization routines forCFNRyis spec-ified.

26


37/68

VLRshould handle CFNRcusing Mobile Additional Function MAF010 [7]which is the examination ofCFNRcwhen either the mobile subscriber is notreachable in theVLR, or when there is no paging response or when there is

a radio congestion.

Home Location Register RequirementsHLRshould handle the following call forwarding decision cases: CFU, andCFNRc(when the mobile subscriber is deregistered or purged in the HLRor not reachable in theVLR). HLRshould also implement the mobile addi-tional functions MAF007[7], MAF010(subscriber purged from HLR).

HLRshould support the registration, erasure, activation, deactivation, and

interrogation of the call forwarding services.

HLRshould store information related to call forwarding. The basic servicegroup code, forwarded-to number, notifications to the subscriber, and thevalue of the SS-codesuch as the Provisioning, Registration, Activation, andtheHLR induction states.

27


38/68


39/68

Chapter 4

Design

29


40/68

30


41/68

4.1 Architecture

Figure 4.1: System Architecture

31


42/68

The Mobile User Service (MUS) module in the Mobile Switching Centre handlesthe mobile user services like mobile originating calls, mobile terminating calls, androuting calls through the gateway module.

The application platform in theMSCconsists of a connection service, which pro-vides virtual connections(switching), for MUS modules that require access to thetermination. The MUS modules use the connection service to create the con-nection setup for a call. The connection service instructs the Media GatewayController (MGC) to prepare the MG to setup and teardown terminations re-quired for a call.

Termination is a source or a sink for one or more stream of information [13], and acontext is formed by an association between a collection of terminations. A termi-

nation is required for abstracting out the information about a information stream.For example a termination could either represent a RTPtraffic(having audio withcodec EFR), or traffic fromE1/TDM(having audio with codec A-law).

The communication betweenMGandMGCis done using the megaco protocol[13].TheMG has termination access agents, which manage the terminations, and han-dles the megaco termination requests, like add, subtract, and modify.

The add request adds a termination(say T1), by adding a RTP termination onthe BSC side, and an another subsequent add request will add a E1/TDM termi-

nation(say T2) on theMSCside, now the two terminations form a context. Thesubtract request removes a termination from a associated context. The termina-tion is removed when a circuit is no longer required . The modify request modifiesthe termination properties, to include more stream source/sink, or to remove ex-isting ones. thus the connection service abstracts out these information, providingonly the details of the circuit to theMUSmodules.

The external HLR is provided in the SS7 network, which stores the subscriber in-formation, while theVLR is a part of theMSCnode . The Transit Module (TM)handles the transit of all the messages in the MSCto each of the worker process.

Introducing E1/TDM access agents to work alongside RTP access allows the VMS,BSC, and the regular non Call Forwarding (CF) calls to work without any change.Having a transcoding client eliminates the need of transcoding when the codecsfrom BSC are the same, with respect to non CFcalls.

TheISUPaccess handler, provides external ISUPaccess towards theVMS. The

32


43/68

VMSuses aGTHhardware, which are connected to the telephone network via E1or T1 links (2 or 1.5Mbit/s) and are controlled over ethernet.

Having a External ISUP agent allows a modular design, and to connect to the SS7network only when required for external calls, this is helpful for nonSS7traffic.TheISUPaccess handler, is designed to work like the rest of the call workers, likemobile originating, mobile terminating, and gateway.

The transit module is extended to handle both the SS7and nonSS7traffic, thetraffic to theVMSis designated to route towards the external ISUP, instead of theterminating worker. This allows the VMS call to follow call control sequences thatis similar to a regular call, but differ only with regard to termination. The callstoVMSterminate in the isup access handler, and is sent through theSS7network.

The architecture follows a mix of the M3UA layer, and the SS7 network, withcomponents to handle differences and provide compatibility. The architecture alsoborrows a great deal of the design from how the GSM call serviceis designed, andis extended to provide compatibility.

33


44/68

4.2 Components

Since the implementation will try to enhance the already existing GSM Call Ser-

vice, the design focuses on what new components will be added to GSM CallServiceand what existing components will be changed.

MUSwill be required to handle call forwarding and call handling traffic using co-ordinator processes, so that it doesnt break the existing design. The co-ordinatorprocess will be required to handle all supplementary services provided by GSM,which can be enhanced in future if it is required for GSMVMSto support moresupplementary services.

The VLR component is required to handle MAP requests, from the HLR, and

MSC so there is a need for map handlers, GSM Call Service does not providemap handlers, but only simulates map messaging. TheVLRcomponent is also re-quired to handle authorizations for subscription checks, and call forwarding checks.

MAPhandlers will be used by three components, namely theVLR, theMSCandtheHLRto communicate with one another. The design should focus on havinga generic map handler that can also serve component specific custom messages ifrequired.

Finally theTMrequires externalISUPhandling, here external refers to theISUPmessages that uses MTP for transmission in the SS7 network. This is enhanc-ing GSM Call Serviceto handle ISUP/SS7 traffic, and integrating it in the SS7network.

34


45/68

4.2.1 Mobile User Service

Figure 4.2: Mobility User Service components

35


46/68

TheMUShas modules which handle the call originating, gateway, and terminatingfunctionalities of a call. This will suffice for a regular call where the scenario forforwarding never happens. However to support VMSoperations the design has to

be extended to handle cases when a call can be forwarded.

Imagine a scenario where a terminating call is not completed either because theuser is busy or there is network congestion. In either case the MUSsimply doesnthave the functionality to forward the call to another subscriber.

Support for call forwarding can be added without much effort, since theGSM CallServicealready provides a routing abstraction through theTM. The functionalitycan be added in the TMto route forwarded messages, and to keep track of thenumber of hops.

This design will suffice if the traffic is always in the area controlled by theMSC,butreal world scenarios require traffic to be routed to external gateways and network.Hence theTMshould support externalISUPmessages handling, and transit. Thisis realized through the external ISUPhandler in the TM. Detailed informationabout theTMwill be covered in section4.2.4.

There is also a need for taking user preferences into account, when providing sup-plementary services. The mobile subscribers(or users) require handlingof supple-mentary services, like registering, unregistering. A co-ordinator process is added in

theMUSto providehandlingof supplementary services. A concurrent thesis workuses the co-ordinator process to handle supplementary services like UnstructuredSupplementary Service Data (USSD).

The supplementary services handling messages are sent asDTAPmessages. reg-isterSS, eraseSS, activateSS, deactivateSS, interrogateSS for registering, erasing,activating, deactivating, and interrogating the supplementary services.

The behaviour of the co-ordinator process for every message is specified here.

Register SS MSC message is received as a DTAP message, and sent as a

MAPmessage to theVLR without checking the contents of the service tobe registered to.

Erase SS MSC message is received as aDTAPmessage, and sent as a MAP ERASE SSmessage to theVLR.

Activate SS MSC message is received as a DTAP message, and sent as aMAP Activate SS message to theVLR.

36


47/68

Deactivate SS MSC message is received as a DTAPmessage, and sent as aMAP Deactivate SS message to theVLR.

Interrogate SS MSCTransfer the message to theVLRwith MAP Interrogate SS request withoutchecking the contents.

4.2.2 VLR

TheVLRin theGSM Call Servicedoes not handleMAPmessages, The B interface(between VLR and MSC), does not requireMAPmessages, as they are closely in-tegrated, and communication can be done using language specific message passing.

The call forwarding authorizations for VLR fall under different categories likeNDUB, UDUB,CFNRc, andCFNRy.

NDUBis when theVLR determines that the user is busy, and cannot be reached,this happens when thePAGErequest sent by theVLRto contact the mobile sub-scriber fails.

UDUBis when theVLR determines that the user is busy, and cannot be reached,this happens when the user receives the call, and decides to reject it.

CFNRchappens when there is congestion, or when the subscriber has detached

from the VLR andCFNRyis when the subscriber never answers the call.

For each of these scenarios, the VLRchecks whether a CFoption has been sub-scribed by the user and is enabled by the operator, theVLRthen performs a seriesof tasks to enable theISUPmessage to carry sufficientCFinformation.

The Mobile Additional Function (MAF) are a series of functional checks performedby theVLR(and theHLR), to determine whether a call can be forwarded. If thecheck is successful theVLR populates the forwarding number, the forwarded-tonumber, the forwarding hop count, and routes the message.

TheVLRprovides aMAPhandler to communicate with the externalHLR, and toprovide map handling, Every subscriber handling request is handled in theVLRtohandle a request to register, erase, activate, deactivate, and interrogate[7, p. 617].

For the supplementary services theVLRshall store the service state informationreceived from theHLR. This is theSSstatus for every subscriber.

37


48/68

Provisioning StateWhether the particularSShas been provisioned by the network operator.

Registration StateWhether the user has registered to the particular SS.

Activation StateWhether the particularSShas been activated.

4.2.3 MAPHandlers

MAPhandlers are provided for use byVLR, andMUS to establishMAP commu-nication withHLR. MAPuses theTCAPprotocol and is designed to have sessionsvery similar to aTCAPsession.

AMAPsession starts with theOPENrequest, and ends with the CLOSE request,while aTCAPsession starts with a BEGINand ends with ENDrequest [8,7].

To separate connections between originating and termination requests, the designemphasizes, a MAP outand a MAP in handler. TheMAPout handler is for anyoutgoing map session, initiated by a map user. MAP user is one of VLR, HLR,

38


49/68

or the MUS. The MAP inhandler is for any incoming map session accepted by amap user. The MAP message that operate over the B, C, and D interfaces can beclassified into one of the categories, as either a MAP in or a MAP out handler.

This greatly simplies the design for handling different MAP messages.

4.2.4 Transit Module

VMSrequires the use of tones and annoucements, to communicate with the callingsubscriber about the status of the call, and the necessary actions that are requiredto complete the voice mail.

TMis enhanced to send tones, and announcements, in case of busy, congestion,

alerting etc. This is done by having a mapping between the ISUP cause(codes),and the various tones that need to be announced . Tones also include special in-formation tones due to numbering plan error, congestion tone, and other customtones in the future.

TMsends tone using the connection service, theTMseizes a virtual connection(asa service user) to send custom tones when a call is ongoing. The message is sentwith parameters specifying the virtual switch, the virtual port, and the tone id.

TMalso handles the routing of externalISUPto the externalISUPhandler. The

external ISUPhandler is managed by the TM.

The design focuses on having the external ISUP handler communicate with theTietoSS7stack, to receive the ISUP/SS7 messages.

4.2.5 Connection Service

The Connection Service (CS) should be enhanced to provide support for tones(announcementsandDTMF). TheMUSworker or theTMspecifies the termination id, the virtualswitch id, and the virtual port.

TheCS, instructs the megaco client to send a megaco modify request forDTMFand tone sending.

39


50/68


51/68

4.3.2 VLRInterface

The VLR uses the map handler to initiate any outgoing map session with theHLR

or theMUS. The MAP session with the HLR is sent asMAPover SS7[7,p. 272],and the map session with the MUS is sent as MAPover IP.

4.3.3 HLRInterface

GSM Call Serviceuses aHLRas a MUS component, the GSM VMSwill use theHLR provided by Mobile Arts.

This HLR is an external HLR containing the data of the subscribers of MobileArts; interfacing with the real worldHLRwould require the use ofMAP handlers.

TheMUSand theVLRuses the map handler to communicate with theHLR,thisfollows the same pattern as specified in the section4.3.1.

4.3.4 MUSInterface

MUS interface with VLR and TM will be re-used from GSM call service, theinterfacing with HLR will be enhanced with MAP handlers as specified in thesection4.3.1.

4.3.5 Connection Server Interface

Connection service in theGSM Call Servicewill be enhanced to provide services totheMUS modules to send tones and announcements. TheMUSmodules requestaserviceuser privelege from the connection service, to send theDTMFtones andannouncements.

4.3.6 ISUPAccess Handler TietoISUPstack

Tieto SS7 signalling stack is used by Mobile Arts for SS7 communication, the in-

terface betweenISUPaccess handler and TietoISUPstack is to setup, maintain,and teardown, ISUP connections as required.

ISUP connection is setup by binding to the Tieto stack, using the ISUP BINDmessage, ISUP IAM is received by the ISUP access handler when there is a in-coming call. TheISUP IAM is sent as ISUP SETUP REQ to the Tieto Stack,with important parameters like calling party number, called party number, and

41


52/68

the redirecting number.

The termination side, confirms the call using ISUP PROCEED request, this is

usually a VMS which sends the message if the call has been forwarded; with thereceipt of the proceed message, the connection is established. ISUP also allowscircuits to be reserved and unreserved.

To teardown a ISUP connection, the ISUP access handler sends the ISUP RE-LEASEwith the corresponding release code, the release codes are useful in an-nouncements and DTMF signals.

4.3.7 Transit Module ISUP access handler

The transit module interfaces with the isup access handler to start and stop it. Italso converts certain ISUP parameters like ISUP CIC, ISUP calling party address,and ISUP called party address used internally in GSM Call Service, to the formatrequired by ISUP access handler.

42


53/68

4.4 Handling Bearer Differences

The real challenge in getting the system to work, in other words to send a M3UA

traffic to the SS7 network and back, is to handle the difference in the protocol.

4.4.1 ISUP Mapping

ISUPaccess handler providesISUPCIChandling. It also maps the primitiveISUPmessage types toISUPsetup requests that should be sent to the Tieto SS7/ISUPstack. The following table specifies theISUPmapping.

Mapping

Call Setup Stage

ISUP IAM isup setup reqISUP ACMISUP CPG isup proceed reqISUP ANM isup setup resp

Call Connected Stage

ISUP CPG isup progress indISUP CPG isup progress req

Release Initiated By MSC

ISUP REL isup release indISUP RLC isup release resp

Release Initiated By VMS

ISUP REL isup release reqISUP RLC isup release conf

CICis chosen and sent in theISUPIAMmessage to theISUPaccess handler, theisup access handler maps the ISUP IAMrequest to ISUP setup req, where theISUPhead contains the timeslot and the span taken from theCIC.

TheVMSdeposit or retrieve action is determined if the roaming number is present.If the roaming number is absent it corresponds to a retrieve action, if the roamingnumber is present it is deposit.

43


54/68


55/68

Chapter 5

Implementation And Test

45


56/68

The following chapter describes the implementation methodology, the environmentsetup, and the different levels of implementation groups; with each group listingthe different levels of required effort. The implementation also gives a big picture

of the design objectives in every phase and their expected outcome.

5.1 Methodology

The methodology adopted for implementation was a customized mix of Scrumand Waterfall. Scrum is a agile software development which is interactive andincremental, while Waterfall model, is a sequential design process, starting fromrequirements, design, implementation, followed by maintenance.

The requirement gathering phase for the thesis required the Waterfall model tounderstand the standards and specification, and listing out the important require-ments for the thesis. The Scrummodel was customized to be more like an evolu-tionary model, to fit a team size of two.

The Scrummodel was more useful during the implementation, to release incre-mental working features, and to get quick feedback from the company.

5.2 Environment Setup

The environment consisted of BSC, MSC, HLR, VMS, and Tieto SS7 nodes; TheVMS required setup and configuration to use the tones and required services.

Use of nanoBTS requires a license requirement, and the environment setup re-quired some planning to install the GSM Call Service, in the SS7 network.

The challenge was in enabling VMSto bind with the SS7 stack to use the ISUPservice, and binding the MUS module of the GSM Call Serviceto use theISUP,andMAPservices provided by TietoISUPstack.

The hardest problem was in configuring the Tieto SS7 stack, as it required detailedunderstanding of SS7, and SIGTRAN gateways. Since this was done in close co-operation with Mobile Arts, we received assistance in setting up the Tieto SS7stack as required.

46


57/68

5.3 Implementation Groups

The implementation was based on the existing GSM Call Service design. To en-

hance the already available GSM Call Service, by categorising the requirementsinto three groups.

The first group were the modules that were present in GSM Call Service, whichcould be reused as-is.

TCP/IP ServerThe module receives the DTAP and BSSMAP messages from the BSC sentover a TCP connection. It could be reused as-is, as the GSM VMS used thesame design structure as followed by the GSM Call Service to connect theANto theCN.

VLR call handlerVLR Incoming Call Handler (VLR ICH), is responsibile for VLR decisioningfor incoming calls, and VLR Outgoing Call Handler (VLR OCH) is respon-sible for VLR decisioning for outgoing calls, Since the GSM VMS is requiredto support regular calls and there wont be any change in the way a nonCFcall will be supported, these modules can exist as-is.

Tieto SS7The Tieto SS7 stack provided by Mobile Arts will be reused as-is without

any changes.The second group were the modules that were present in the GSM Call Service,which could be used with some enhancements.

MUSThe MUS required changes to call originating, call terminating and the gate-way modules to handle support for call forwarding scenarios.

TMThe transit module, required changes to handle ISUP access handler, andexternal ISUP routing.

VLRThe VLR required changes to handle map handlers, and the VLR decisioningcases used for call forwarding.

The third group were the list of modules that were to be newly added

47


58/68

MSC Co-ordinatorSince GSM Call Servicedid not provide support supplementary services,there was no requirement for a co-ordinator process. In GSM VMS a co-

ordinator process is required to support, supplementary services provisioningand handling.

Map handlerMAP handler is a new module, which can provide protocol abstraction overGSM Call Servicemap handling modules and SS7 map users(like VLR, HLR)that deal with MAP traffic.

5.4 Design Phases

The first design phase consisted of designing and implementing the requirements,in a series of iterations. The first phase was planned to setup the existing systemand run it in the SS7 environment. While the second phase consisted of writingthe ISUP call control parts, to integrate it with the VMS. Once the integrationwas done the third phase was to integrate the call control with the media controlprovided by the concurrent thesis.

Phase 1

The objective ofPhase 1 was to get the existing system(GSM Call Service) inte-

grated and running with the Mobile Arts environment. This included implement-ingISUPhandlers, and co-ordinator processes to communicate with SS7 protocols.The objective was also to enhance the existing GSM Call Serviceto function withcall forwarding scenarios.

The implementation goal was focussed on keeping theCFscenarios easy to test,and avoided complex multiple call forwarding hops; since the original goal of thethesis was to try out the possibilities of integration of ISUP over IP and ISUP overSS7(including MAP over IP and MAP over SS7).

The implementation goal also focussed on keeping the supervision structure pro-vided by Erlang/OTP simple, and easy to test. Stability of the system, andrequirement of different tones and annoucements for the VMS were moderatelyprioritized.

The output of thePhase 1 was a system, where theMUSmodules, can send tones,and announcements by using theCSas a service user.

48


59/68

Phase 2

The objective ofPhase 2 was to implement the ISUPaccess handler, which can

be controlled by theTM, the objective also was to enhanceTMto handle externalISUP. The final goal was to send a ISUP message from GSM Call Service acrosstheSS7network(to bind and unbind) and back.

The output ofPhase 2 was enabling ISUP communication, with external ISUPhandling and routing by theTM.

Phase 3

The Mobile Equipment sends and receives audio with the codec EFR, and VMSsends and receives audio with codec A-law. The concurrent thesis, dealt with

transcoding, and rate adaptation between the two codecs. Phase 3of the projectdealt with early integration of GSM Call Service with external ISUP handling,and the transcoder.

The output of Phase 3 was a partially functioning GSM VMS, capable of sup-porting non concurrent calls for deposit and retrieval of voices messages from theVMS.

Phase 4

Phase 4 dealt with making the system more useable for testing the VMS service.It also dealt with addingDTMFtones and announcements to enable subscribers toselect their services. This was partially completed, as the project goal was alreadyrealized with the completion of deposit and withdrawal of messages from theVMS.

5.5 Testing

The original testing objective was to reuse the test cases that came along withGSM Call Service, it included complete system and unit-testing using Erlang re-bar.

As the thesis objective was not to deliver a stable working system, system testswere not prioritized. Testing was done to verify call control use cases, which in-cludedCFU, CFB,CFNRc,CFNRy.

CFUandCFBwere verified by having a subscribers list, whose IMSIwas config-ured in theHLRto always forward to the subscribers voicemail. This was done

49


60/68

by manual testing and didnt require any test cases.

CFNRyandCFNRcwere tested, by simulating network congestions and subscriber

absence, enabling the call to reach the subscribers voice mailbox, when call for-warding was enabled.

Main focus of testing were the integration of call control and media control mod-ules. The following were covered during integration testing.

CSSince the MUS modules maintain states for every call, the connection toCSshould be stable and provide correct virtual switching and virtual ports

access(for circuit switching) for theMUSmodules, when a call is forwarded. CIC transmission

Since the CIC conveyed the ciruits used in a call, it was to be effectivelyconveyed to the media control modules. The terminations used in the accessagents, should have a CIC mapping, the tests were to ensure, the mappingwas proper, and each call had a valid CIC.

50


61/68

Chapter 6

Discussions & Conclusions

51


62/68

Traditional telephony networks, have the advantage of being extremely reliable,but also expensive. The converge networks(SS7 over IP) specified by the SIG-TRAN family of protocols (SCTP, M3UA) brings with it the advantages of de-

creased cost of infrastructure, and improved ease of management. The followingare the highlights of the advantages provided by using convergence networks.

6.1 Features

SS7 messages transported over IP networks, adopts common transport protocols,and adaptation modules to provides features like flow control, identification ofvoice circuits, error detection, retransmission, security, and congestion avoidanceetc. Size restrictions posed in the SS7 network, are no longer a problem in the

IP networks. VMS TDM Call Control provides these features by the use of SIG-TRAN(M3UA) protocols.

6.2 Performance

The standard (ITU) specifies the performance requirements, and response times ofthe application. For example ITU specifies the end-to-end call setup delay cannotexceed 10 to 20 seconds after the initial ISUP IAM. VMS TDM Call Control, isdesigned to satisfy user expectations and ITU standards for performance.

6.3 Security

SS7 messages transported over a private internet are relatively safe, and securitymeasures can be deemed as necessary by the operator, but for SS7 over IP trans-ported over public networks, the use of security measures is mandatory. Securityover IP is provided by the use of IPSEC, which provides authentication, integrity,confidentiality, and availablility. VMS TDM Call Control usesSIGTRANfamilyof protocols (SCTP, M2UA, M3UA), and hence meets high security expectations.

6.4 CostThe standardization forum 3gpp has specified GSM, while ITU-T specifies ISUPcall control protocol, relying on the expensive telecom specificTDM.The research work finds its areas where cheaper alternatives are required for expen-sive telecom hardwares. It implicitly also provides theGSM call servicewhich canbe used in a academic environment, with a nanoGSM-picocell and openBSC, with

52


63/68

a call forwarding options and as a placeholder for other supplementary services.This enables cost saving and provides GSM features without the use of expensivetelecom hardwares.

6.5 Conclusions

The work done on the thesis can be classified into the following areas.

Surveying the 3GPP specifications for call control related to GSM Call For-warding, CIC handling, and bearer differences in ISUP and MAP(TCAP)

Enhancing the GSM Call Service to handleSIGTRANfamily of protocols,

and provide voice mail call forwarding service

Integrating the GSM VMS TDM Call Control with GSM VMS Media Con-trol, to provide support for voice traffic

Implementing the working system in Erlang/OTP, and integrating it to workwith existing GSM components in Mobile Arts

Testing the retrieval and deposit of voice mail messages.

The research work adds to the existing body of knowledge of whatM3UAprovides.The results of the study indicate that the goal of the thesis of investigating thepossibilities of creating the call control parts of a VM Call Forwarding Service inan existing GSM Call Service environment was achieved.

53


64/68

Chapter 7

Future Work

54


65/68

The integration ofGSM VMS TDM Call Control in GSM Call Service, providesopportunities for enhancements and future work. The future work in in two cate-gories namely GSM signalling, and integrating more GSM service/components.

The future work associated with signalling are CF handling, CF deflection, CCBS,and Camel, and the ones associated with integration are supplementary serviceslike CCBS, Voice Group Call Service, etc.

CF Handling

Call Forwarding handling of mobile subscriber, includes registration, erasure,withdrawal, provisioning, activation and deactivation of supplementary ser-vices for a basic group.

MSC can be extended, with the CFhandling procedures, it also affects themodules, VLRand theHLR.

Call Deflection

Call deflection is covered in [9], it is a subset of the supplementary serviceprovided by GSM. It is almost similar to call forwarding, but differs a bit inthe call controls aspects.

VLR Integration

An actual VLR in theSS7network can be integrated with the MSC, thereare handlers in theMSCto handle the SS7 MAP traffic from the VLR.

CCBS

Call completion of busy subscriber as a result of CCBS blocking can beimplemented as aCFuse case. This allows the caller to be alerted when thecalled party has become available, and the previous call had failed to thecalled party.

Transcoder Codecs

This is the media control part ofGSM call service, but also affects the call

control, when different codecs are used, the transcoder can be extended tohandle multiple codecs.

Voice Group Call Service

This is one of the advanced speech call items, where multiple subscribers cantalk to each other, this probably wouldnt be a near future work, but can beconsidered for extending the current framework.

55


66/68

The MG can be extended to support topology descriptor, where multipleterminations can form a topology this allows the feature for a voice call,where streams of audio from multiple termination can be part of a topology.

Camel Phase1/Phase2 Support

Customized Applications for Mobile network Enhanced Logic was introducedfor easing roaming and billing purposes, it also replaced Intelligent Net-work Application Part, providing greater mobility management, Camel isdivided in phases, Customized Applications for Mobile network EnhancedLogic (CAMEL) phase 2 supports, call forwarding, call redirection, the MSCcan extended to supportCAMEL.

56


67/68

Bibliography

[1] SS7andGSMnetwork overview. http://www.gl.com/maps-isup.html.

[2] Privateline GSM Nokia webpage. http://www.privateline.com/PCS/GSMNokia.html.

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

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

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

[6] The 3rd Generation Partnership Project. Basic call handling. http://3gpp.org/ftp/Specs/html-info/23018.htm, 12 2009. V9.0.0.

[7] The 3rd Generation Partnership Project. Mobile application part(map)specification. www.3gpp.org/ftp/Specs/html-info/29002.htm, Dec 2009.V9.0.0.

[8] The 3rd Generation Partnership Project. Signalling interworking for sup-plementary services. www.3gpp.org/ftp/Specs/html-info/29011.htm, Dec2011. V11.0.0.

[9] The 3rd Generation Partnership Project. Call deflection(cd) supplementaryservices stage 2. http://3gpp.org/ftp/Specs/html-info/23072.htm, Dec2012. V9.0.0.

[10] The 3rd Generation Partnership Project. Call deflection(cd) supplementaryservices stage 3. http://3gpp.org/ftp/Specs/html-info/24072.htm, Dec2012. V9.0.0.

57
http://www.gl.com/maps-isup.htmlhttp://www.privateline.com/PCS/GSMNokia.htmlhttp://www.privateline.com/PCS/GSMNokia.htmlhttp://www.privateline.com/PCS/GSMNokia.htmlhttp://www.3gpp.org/ftp/Specs/archive/23_series/23.002/23002-700.ziphttp://www.3gpp.org/ftp/Specs/archive/23_series/23.002/23002-700.ziphttp://www.3gpp.org/ftp/Specs/archive/23_series/23.018/23018-700.ziphttp://www.3gpp.org/ftp/Specs/archive/23_series/23.018/23018-700.ziphttp://www.3gpp.org/ftp/Specs/archive/29_series/29.002/29002-700.ziphttp://www.3gpp.org/ftp/Specs/archive/29_series/29.002/29002-700.ziphttp://3gpp.org/ftp/Specs/html-info/23018.htmhttp://3gpp.org/ftp/Specs/html-info/23018.htmhttp://www.3gpp.org/ftp/Specs/html-info/29002.htmhttp://www.3gpp.org/ftp/Specs/html-info/29011.htmhttp://3gpp.org/ftp/Specs/html-info/23072.htmhttp://3gpp.org/ftp/Specs/html-info/23072.htmhttp://3gpp.org/ftp/Specs/html-info/24072.htmhttp://3gpp.org/ftp/Specs/html-info/24072.htmhttp://3gpp.org/ftp/Specs/html-info/24072.htmhttp://3gpp.org/ftp/Specs/html-info/23072.htmhttp://www.3gpp.org/ftp/Specs/html-info/29011.htmhttp://www.3gpp.org/ftp/Specs/html-info/29002.htmhttp://3gpp.org/ftp/Specs/html-info/23018.htmhttp://3gpp.org/ftp/Specs/html-info/23018.htmhttp://www.3gpp.org/ftp/Specs/archive/29_series/29.002/29002-700.ziphttp://www.3gpp.org/ftp/Specs/archive/29_series/29.002/29002-700.ziphttp://www.3gpp.org/ftp/Specs/archive/23_series/23.018/23018-700.ziphttp://www.3gpp.org/ftp/Specs/archive/23_series/23.018/23018-700.ziphttp://www.3gpp.org/ftp/Specs/archive/23_series/23.002/23002-700.ziphttp://www.3gpp.org/ftp/Specs/archive/23_series/23.002/23002-700.ziphttp://www.privateline.com/PCS/GSMNokia.htmlhttp://www.privateline.com/PCS/GSMNokia.htmlhttp://www.gl.com/maps-isup.html


68/68

[11] The 3rd Generation Partnership Project. Call forwarding(cf) supplementaryservices stage 2. http://3gpp.org/ftp/Specs/html-info/23082.htm, Dec2012. V9.0.0.

[12] The 3rd Generation Partnership Project. Call forwarding(cf) supplementaryservices stage 3. http://3gpp.org/ftp/Specs/html-info/24082.htm, Dec2012. V9.0.0.

[13] Ericsson AB. Megaco/H.248 Users Guide. http://www.erlang.org/documentation/doc-5.4.12/lib/megaco-3.2.3/doc/html/part_frame.

html, 2011.

[14] IETF. Signalling system 7, message transfer part 3, user adaptation layer.http://tools.ietf.org/html/rfc4666, september 2002.

[15] ITU-T. Q.764. http://www.itu.int/rec/T-REC-Q.764-199912-I, 1999.Signalling System No. 7 ISDN user part formats and codes.

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

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

[18] Uppsala University projectCS 2011. Gsm call service. http://www.it.uu.se/edu/course/homepage/projektDV/ht11/MAproductreport.FINAL.pdf,Feb 2012.

[19] Team Mobile Arts Project CS 2011. Course report GSM Call Service, 2012.
http://3gpp.org/ftp/Specs/html-info/23082.htmhttp://3gpp.org/ftp/Specs/html-info/23082.htmhttp://3gpp.org/ftp/Specs/html-info/24082.htmhttp://3gpp.org/ftp/Specs/html-info/24082.htmhttp://www.erlang.org/documentation/doc-5.4.12/lib/megaco-3.2.3/doc/html/part_frame.htmlhttp://www.erlang.org/documentation/doc-5.4.12/lib/megaco-3.2.3/doc/html/part_frame.htmlhttp://www.erlang.org/documentation/doc-5.4.12/lib/megaco-3.2.3/doc/html/part_frame.htmlhttp://tools.ietf.org/html/rfc4666http://www.itu.int/rec/T-REC-Q.764-199912-Ihttp://www.itu.int/rec/T-REC-Q.764-199912-Ihttp://www.itu.int/rec/T-REC-Q.764-199912-Ihttp://www.itu.int/rec/T-REC-Q.764-199912-Ihttp://www.itu.int/rec/T-REC-H.248.1-200509-Ihttp://www.it.uu.se/edu/course/homepage/projektDV/ht11/MAproductreport.FINAL.pdfhttp://www.it.uu.se/edu/course/homepage/projektDV/ht11/MAproductreport.FINAL.pdfhttp://www.it.uu.se/edu/course/homepage/projektDV/ht11/MAproductreport.FINAL.pdfhttp://www.it.uu.se/edu/course/homepage/projektDV/ht11/MAproductreport.FINAL.pdfhttp://www.itu.int/rec/T-REC-H.248.1-200509-Ihttp://www.itu.int/rec/T-REC-Q.764-199912-Ihttp://www.itu.int/rec/T-REC-Q.764-199912-Ihttp://tools.ietf.org/html/rfc4666http://www.erlang.org/documentation/doc-5.4.12/lib/megaco-3.2.3/doc/html/part_frame.htmlhttp://www.erlang.org/documentation/doc-5.4.12/lib/megaco-3.2.3/doc/html/part_frame.htmlhttp://www.erlang.org/documentation/doc-5.4.12/lib/megaco-3.2.3/doc/html/part_frame.htmlhttp://3gpp.org/ftp/Specs/html-info/24082.htmhttp://3gpp.org/ftp/Specs/html-info/23082.htm

Value Added Services in GSM Network

Documents

Transcript of Value Added Services in GSM Network