IT 13 025

Examensarbete 30 hpMars 2013

Home Location Register (HLR) dedicated for Short Message Service (SMS)

Niklas RönnblomJohan Vikman

Institutionen för informationsteknologiDepartment of Information Technology

Teknisk- naturvetenskaplig fakultet UTH-enheten Besöksadress: Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0 Postadress: Box 536 751 21 Uppsala Telefon: 018 – 471 30 03 Telefax: 018 – 471 30 00 Hemsida: http://www.teknat.uu.se/student

Abstract

Home Location Register (HLR) dedicated for ShortMessage Service (SMS)

Niklas Rönnblom and Johan Vikman

In telecommunication a Home Location Register (HLR) is used for keeping track ofsubscriber data for a multitude of services, including Circuit Switched (CS) calls, ShortMessage Service (SMS), and more.To support all functions, about 50 different complicated operations must besupported. This requires large sets of resources, both in time to implement and incapacity when in use.However, there are applications, for example vending machines, for which SMS is theonly service needed to be supported. The goal of this thesis is to implement an HLRprototype, to explore the real-time characteristics of a subset of the HLR databaseoperations required to support SMS only. The prototype that we build and test,adheres to the standards specified by 3GPP. It is also much easier to configure andmaintain than a conventional HLR, because it only supports one function. Mostimplementation was done using Erlang, a concurrent soft real-time programminglanguage widely used in telecoms.

Tryckt av: Reprocentralen ITC

Sponsor: Mobile ArtsIT 13 025Examinator: Olle ErikssonÄmnesgranskare: Olle GällmoHandledare: Lars Kari

SammanfattningInom telekom används en Home Location Register (HLR) för att registreraabonnent-data gällande flertalet tjänster, inklusive krestkopplade samtal,SMS m.fl.

Eftersom många olika tjänster måste stödjas blir implementationen avHLR-databasen omfattande och därmed väldigt dyr, exempelvis måste ca50 olika och ganska komplicerade databasoperationer hanteras.

Däremot finns tillämningsområden, t.ex. läskautomater, för vilka SMSär den enda tjänst som behöver stödjas.

Målet med denna uppsats är att implementera en HLR-prototyp för attutforska realtidsegenskaperna hos en delmängd av databasoperationerna förHLR som krävs för att stödja enbart SMS. Prototypen vi utvecklat ochtestat följer standarden specificerad av 3GPP. Den är även mycket enklareatt konfigurera och underhålla än en konventionell HLR. Nästan all imple-mentation är gjord i Erlang, ett programmeringsspråk som är väl lämpatför system där flera processer samverkar och språket är ofta använt inomtelekom.

1

2

Contents1 Introduction 15

1.1 Intro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.2 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . 151.3 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.3.1 Research phase . . . . . . . . . . . . . . . . . . . . . . 161.3.2 Design phase . . . . . . . . . . . . . . . . . . . . . . . 161.3.3 Implementation phase . . . . . . . . . . . . . . . . . . 161.3.4 Validation phase . . . . . . . . . . . . . . . . . . . . . 17

1.4 3gpp and standards . . . . . . . . . . . . . . . . . . . . . . . . 171.5 Related Works . . . . . . . . . . . . . . . . . . . . . . . . . . 171.6 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2 Background 182.1 Cellular Networks . . . . . . . . . . . . . . . . . . . . . . . . . 182.2 SS7 Network . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2.1 Network Components . . . . . . . . . . . . . . . . . . 202.2.2 Interfaces and Protocols . . . . . . . . . . . . . . . . . 22

2.3 SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.3.1 SMS delivery Example . . . . . . . . . . . . . . . . . . 24

2.4 Home Location Register (HLR) . . . . . . . . . . . . . . . . . 252.5 Erlang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.5.1 Concurrency & Distribution . . . . . . . . . . . . . . . 252.5.2 OTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.6 Mnesia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.7 CouchDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.7.1 Replication . . . . . . . . . . . . . . . . . . . . . . . . 282.7.2 Multi-Version-Concurrency-Control . . . . . . . . . . . 282.7.3 Potential drawbacks . . . . . . . . . . . . . . . . . . . 29

3 Design 293.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2 Application Design . . . . . . . . . . . . . . . . . . . . . . . . 303.3 Database Design . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3.1 Subscriber data . . . . . . . . . . . . . . . . . . . . . . 303.3.2 System Data . . . . . . . . . . . . . . . . . . . . . . . 303.3.3 Design criterias . . . . . . . . . . . . . . . . . . . . . . 31

3.4 Subscriber data . . . . . . . . . . . . . . . . . . . . . . . . . . 313.4.1 imsi_lookup . . . . . . . . . . . . . . . . . . . . . . . 313.4.2 subscriber . . . . . . . . . . . . . . . . . . . . . . . . . 333.4.3 temporary_data . . . . . . . . . . . . . . . . . . . . . 333.4.4 roaming_data . . . . . . . . . . . . . . . . . . . . . . 343.4.5 MWI and MWD . . . . . . . . . . . . . . . . . . . . . 34

3

3.4.6 lcs_routing_info . . . . . . . . . . . . . . . . . . . . . 343.4.7 camel . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.4.8 lcs_profile . . . . . . . . . . . . . . . . . . . . . . . . . 353.4.9 odb_profile . . . . . . . . . . . . . . . . . . . . . . . . 363.4.10 ss_registration_data . . . . . . . . . . . . . . . . . . . 373.4.11 ss_profile . . . . . . . . . . . . . . . . . . . . . . . . . 373.4.12 authentification_data . . . . . . . . . . . . . . . . . . 38

4 Implementation 384.1 supervision tree . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.1.1 sms_hlr_sup . . . . . . . . . . . . . . . . . . . . . . . 384.1.2 hlr_sup . . . . . . . . . . . . . . . . . . . . . . . . . . 384.1.3 tcap_sup . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.2.1 MAP Interfaces . . . . . . . . . . . . . . . . . . . . . . 404.2.2 TCAP Interfaces . . . . . . . . . . . . . . . . . . . . . 404.2.3 Internal Interfaces . . . . . . . . . . . . . . . . . . . . 40

4.3 Database Implementation . . . . . . . . . . . . . . . . . . . . 404.4 CouchDB Considerations . . . . . . . . . . . . . . . . . . . . 414.5 MAP Operations . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.5.1 Network initiated MAP procedures . . . . . . . . . . . 434.5.2 OAM initiated MAP procedures . . . . . . . . . . . . 474.5.3 OAM initiated HLR procedures . . . . . . . . . . . . . 48

5 Evaluation 485.1 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6 Discussions and Conclusions 516.1 Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.1.1 SS7 Stack . . . . . . . . . . . . . . . . . . . . . . . . . 516.1.2 MTG . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.2 Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . . . 516.3 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526.4 Transaction problem . . . . . . . . . . . . . . . . . . . . . . . 526.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

A Appendix A Acronyms 53

B Appendix A Server setups 56B.1 mtg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56B.2 hlr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4

C Appendix B Setting up HLR on RedHat XX 56C.1 configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

C.1.1 ss7.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . 56C.1.2 topology.cfg . . . . . . . . . . . . . . . . . . . . . . . . 57C.1.3 hlr.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . . 57C.1.4 smsctrl_rules.cfg . . . . . . . . . . . . . . . . . . . . . 57C.1.5 map.cfg . . . . . . . . . . . . . . . . . . . . . . . . . . 58

D Appendix C Setting up MTG on SunOS 5.9 58

E Appendix D Notes on Building 59

F Appendix E Notes on Mnesia 59F.0.6 create_table . . . . . . . . . . . . . . . . . . . . . . . 59

G Appendix F Statistics 61G.1 mtg_statistics:collect/0 . . . . . . . . . . . . . . . . . . . . . 61G.2 mtg_statistics:lu_stats/0 . . . . . . . . . . . . . . . . . . . . 61G.3 mtg_statistics:reset/0 . . . . . . . . . . . . . . . . . . . . . . 61G.4 mtg_statistics:collect_and_report/0 . . . . . . . . . . . . . . 61

5

6

1 IntroductionMaster’s Thesis at UUSupervisor: Lars KariRewiever: Olle GällmoDocument written in LATEX

1.1 IntroTo enable the services that are provided by mobile phone networks, a wholeset of network elements are defined by various standards (see 1.4). Someelements are nodes responsible for charging the subscribers based on theirpayment plans, other for assigning parts of the radio bandwidth to the con-nection between phone and radio masts, some for forwarding short messagesbetween subscribers and so on, the list is long (how the network is built isbriefly introduced in 2.2).

One of these nodes, the Home Location Register or HLR, is responsiblefor keeping track of the subscriber data, with data such as phone number,call forwarding information and, among other things, the physical locationof the mobile phone. You can read more about this node in section 2.2.1.

For a regular mobile phone, many of these services can be very useful andmany subscribers are using many of them, but for some applications thereis no need to use all of the services. Consider, for example, soda-vendingmachines, which are situated throughout flight terminals, schools and publicspaces. Once deployed, they will not move around, so there is no need toupdate the location of them, they will never make calls but some of themare capable of sending text messages to their suppliers saying they need tobe refilled or emptied. They have no need for the capabilities of a full scaleHLR implementation with services such as calls. For applications like these,being able to send SMS (see 2.3) is enough.

This is a scenario in which a lightweight HLR capable of SMS would beuseful. This thesis will explore how to design, how to implement and howto test such a HLR.

1.2 Research QuestionsThe aim is to implement a fully working HLR-prototype that can be:

1. used as real-world applications in industry

2. configured and maintained in a simple an easy way (compared to aconventional HLR)

The implementation is done in the programming language Erlang andusing the database that is delivered with Erlang, Mnesia. For more info see

7

section 2.5 and [1]. Mnesia is known to have problems with performancedegradation when the database grows in size. Mnesia consists of a frontendwith a user API and a backend using dets (an disk-based key-value store, alsoa part of Erlang). Our objective is to compare and contrast runtime statisticsfrom running the HLR with Erlangs database Mnesia and a modified versionrunning another backend.

1.3 MethodologyDuring this project we have used several standard software engineering prac-tices including research, design, implementation and validation. In this sec-tion we outline how each practice was done.

1.3.1 Research phase

The research phase mostly consisted of reading and understanding sev-eral 3GPP specifications, related to subscriber data and the various HLR-supported operations. Much of this work consisted of separating and dis-tinguishing relevant parameters and operations that we need to include inour implementation. The operations are specified as part of [3] and theparameters for the subscriber data in [4].

1.3.2 Design phase

We designed the database tables for subscriber data. These were separatedas much as possible based on different criterias. One criteria we use istime-aspect of the data-fields stored, i.e. whether the data is permanentor temporary. Another aspect is security, e.g. an administrator accessingthe database should not be able to see all the data values for a particularsubscriber. And finally there is disk-access issues, if the tables become toolarge we will suffer from prolonged disc reads when we try to access someparticular data-field for a subscriber. These criteria depends on the fact thatwhen performing a read-operation in Mnesia, you read the entire record inthe table, there is no way to read a specific data-field. More about the actualdesign and the decisions involved in this stage can be found in section 3

1.3.3 Implementation phase

The implementation phase had two bigger tasks to complete, the first wasto implement the design and the second included writing a new backend forMnesia, to see if we could eliminate Mnesias weaknesses. The Mnesia back-end is implemented using dets tables, so exchanging the backend involveschanging the source code of dets so it invokes another database backend.The backend we chose here is CouchDB, details can be found in section 4.

8

1.3.4 Validation phase

The validation was conducted by comparing the results of multiple tries ofadding subscribers to the HLR, with the different backends. The results aredetailed sections 5 and 6

1.4 3gpp and standards3gpp is an organization which develops standards for telecommunicationsystems, much like IETF for Internet. 3gpp were created late 1998 by agroup of separate telecommunications organizations, which earlier developedtheir own standards. The purpose of the organization is to develop andmaintain technical specifications and reports for telecommunication systems,which everyone can use freely.

Because of the changing nature of telecommunication, with new stan-dards and services created and old ones discarded, 3gpp “freezes” specifi-cations in “releases”. Therefore one has to decide for a specific release forwhich the HLR has to comply. The goal is to implement for a reasonablynew, and in all stages frozen release and there was two options, release 7 andrelease 8. Release 7 was frozen in stage 3 during the year 2007 (stage 1 and2 before that) and has had some time to be implemented fairly widespread.Release 8 was frozen in all stages during 2008 and has not had as much timeto be tested as release 7. Therefore we chose release 7.

The main 3gpp specifications used in this thesis are [3], [4], [5], [6], [7]and [8].

1.5 Related WorksHome Location Registers are a basic part of the GSM network and thereare many implementations in daily use today1.

Cardell [9] compares the performance of CouchDB and Tokyo Cabinetwith Mnesia. In his thesis he exchanges the backend at a different level usingMnesiaEx. MnesiaEx is an extended version of Mnesia that enables users touse modules (other than ets or dets) that implement a database backend.

There is extensive number of papers on Erlang, for example [10]. Anddiscussing testing using Erlang and telecom availability problems [12]

1.6 Thesis OutlineThis thesis will add to the earlier work, with taking an alternate route toextend the Mnesia backend by carefully customizing it.

Section 2 gives the reader an insight into the telecom network and theErlang programming language.

1At http://www.openss7.org there is a (stalled) project to develop a MAP-compliant

HLR with GPRS support.

9

Section 3 explains on a high level the design of the HLR.Section 4 regards implementation details.Section 5 deals with the evaluation of the tests and also presents the

results from the testing 5.2.Section 6 contains the discussions, conclusions and future work.

2 Background2.1 Cellular NetworksThere are many ways to setup a telecom network and throughout historythere have been many versions of networks that have been, is in and isplanned to be taken into use. One of these networks is the GSM network 2,for which the HLR is implemented. The GSM network is a cellular networkused for communication. It is called cellular because the geographical areaof operation is divided into cells. Each cell is served by one or more basestation, which is a transceiver (both receiver and transmitter) for radiosignals. The Figure 1 shows a simplified view of the cells.

Figure 1: Cellular network

When discussing Cellular Networks, the originating and terminating partof a procedure or transaction are often used. The originating part, or end,is the end that initiates the procedure/transaction and the terminating side

2http://en.wikipedia.org/wiki/GSM

10

is the one that is the ultimate recipient of said transaction or procedure.Sometimes the originating end is called A and the terminating B.

The GSM network can be split by function into three logical parts, theBase Station Subsystem (BSS), the Network SubSystem (NSS) and the Op-erations Support Subsystem (OSS), as in Figure 2.

Figure 2: The general architecture of GSM

BSS The BSS deals with the radio part of the network, that means receivingand transmitting signal to and from User Entities (UEs), e.g. mobilephones.

NSS This is where the major work in the GSM network is done and alsowhere our HLR is situated. The GSM network can connect to othertypes of networks, this is done here.

OSS Last we have the OSS, this is basically an interface from the opera-tors to the different units of the GSM network. This might includeupdating the HLR database, changing routing in the MSC and so on.

11

2.2 SS7 NetworkThe SS7 network [15] is a collection of protocols which are used in telecom-munication. SS7 is short for Signaling System 7.

2.2.1 Network Components

The SS7 network consist of nodes which are responsible for different func-tions. Some of these nodes can be found in Figure 2, but there are also somemore nodes used in this thesis that are not shown in this figure. The nodesare identified by Point Codes (PC) and can be divided into three groups:

• SSP - Service Switching Point is a voice switch with SS7 functionality.Can originate and terminate messages, but not transfer.

• SCP - Service Control Point is a node which often queries a databaseand/or provides logic in the SS7 network.

• STP - Signal Transfer Points, responsible for the transfer of SS7 mes-sages b/w other SS7 nodes, much like a router in the IPA network.STP:s only route/transfer messages.

Mobile Station Mobile Stations (MS) are the units that are used to con-nect to the network. These can be handsets, laptops or really anyphysical device with ability to connect to the network. The MS has anIMEI number to uniquely identify the hardware. Each subscriber hasan IMSI to uniquely identify, the IMSI is usually stored in a SIM-cardon the device. Due to security reasons the IMSI is not sent in protocolmessages if it can be avoided, instead a temporary number, TMSI, isused. The number which is used when calling or sending SMS to theMS is called MSISDN, this number can be used internationally. TheMSs connect to the BSS in Figure 2.

BTS and BSC These are the two major parts of the BSS. BTS stands forBase Transceiver Stations and BSC for Base Station Centrals. TheBTS’s is the entry point to the network from the subscribers point ofview, the radio transceiver we introduced in the section about cellularnetworks above. They can be placed on radio towers, on top of build-ings, in buildings and even on specific floors, depending on the size ofcell. The BSC keeps track of which BTS the UE is using and whichBTS’s that is close to it, so that if the UE moves into another cell, itcan switch to the next BTS. The BTS connects the BSS to the NSS.

MSC and SGSN The MSC, short for Message Switching Centre, is a veryimportant part of the GSM network. It is the node that connects theNSS and OSS together. It acts as a service router within the network

12

and also connects the GSM network to other types of networks, e.g. thepublic switched telephone network (PSTN), the old telephone network.The SGSN, Serving GPRS Support Node, is the MSC of the GPRSnetwork. It has the same functionality as the MSC, but deals withpacket-switched data.

HLR The HLR contains the information and data of the subscriber. In theHLR, checks are made to see if the subscriber is online/offline, if thereis some kind of barring activated, which may stop the subscriber fromusing the GSM service. Another important function in the HLR isto hold information about which VLR the subscriber is using so thatlocation management can be utilized.Each HLR is responsible for a series of numbers, the MSCs knowswhich HLR each subscriber is related to. The HLR knows which VLRthe subscriber is currently related to.Because of the HLRs importance in this thesis we will explain it inmore detail in chapter 2.4.

VLR The VLR is a unit which, like the HLR, keeps subscriber information.But unlike the HLR, which holds information for a subset of all theoperator’s subscribers, the VLR holds location information for theoperator’s subscribers in the geographical areas it is responsible for.The VLR is updated when the subscribers move around and switchesBSC. Compare this to the HLR which is updated when the subscriberchanges VLR, keeping track of the same subset of subscribers, thissubset only changed by operator control.

AuC The AuC is used by the HLR to authenticate the subscribers to pre-vent abuse of the network and to protect subscribers The AuC is some-times co-located with the HLR, in the case of the SMS_HLR, the AuCis part of the same node.

SMSC This node is responsible for sending and receiving short messages,the text messages that are commonly called “SMS”. The SMSC mightstore text messages if the terminating subscriber is offline.

GMSC This node is responsible for routing calls in the network. The SMS-GSMC is responsible for routing Short Messages in the network.

GMLC The GMLC is a node used with positioning services to figure outwhere a subscriber is. Depending on subscriber data, the GMLC maycontact the HLR to get further information used in positioning or getan old location estimate directly from the HLR.

13

2.2.2 Interfaces and Protocols

The protocols in the SS7 stack is designed to provide a reliable means ofcommunicating, this means that all messages are to be delivered. The SS7protocol stack can be described in four levels, note that what is called “lev-els” in the SS7 stack is not the same as “layers” in the OSI model.

From bottom to top these are:

• MTP Level 1 (Physical Layer)

• MTP Level 2 (Data Link Layer)

• MTP Level 3 (Network Layer)

• Level 4 Application Layer

MTP 1 through 3 are sometimes bunched together to simply MTP. Theseprovide reliable transfer of circuit-related signaling, in units referred to asSignal Units (SU), between nodes in the SS7 network. The nodes are ad-dressed through point codes (PC) and every message has both an originatingPC (OPC) and destination PC (DPC).

At the top we have the application layer. The transport layer is generallyconsidered to be a part of the application layer. The application layer consistof a lot of protocols, different depending on the application. We use SCCP,TCAP and MAP, for SMS and HLR-related messaging.

SCCP is short for Signaling Connection Control Part and is closest toMTP level 3 in the SS7 stack. SCCP encapsulates TCAP and has address-ing information stored used for sending messages between subsystems (alsoknown as applications). SCCP supports addressing on three formats:

• Point Code (PC), which are used to identify the SP.

• Subsystem Number (SSN), used to identify the application on thenode.

• Global Title (GT), can be used to identify both services and phones,MSISDNs are often GTs.

To route to the correct service you need both PC and SSN, but when theprocedure is initiated, a GT is all that is given (you enter a GT when youplace a call for instances). GTs are always a telephone number but the exactformat of it can vary. The method to get the correct GT+SSN combinationbased on the GT is called Global Title Translation, this translation is usuallyonly done on a prefix of the GT, if you place an international call you will berouted to an node dealing with the international calls based on the countrycode for instance.

14

SubSystem SSNHLR 6VLR 7MSC 8AuC 10

Table 1: Subsystem SSNs

The SSN are static depending on the type of node, in table 1 we showsome of the SSNs used in SS7. SSNs range from 0-255. SCCP providesboth connectionless and connection-oriented messaging and use segmenta-tion/reassembly to divide and join messages that are big.

TCAP is short for Transaction Capabilities Application Part and is usedfor communication between subsystems at the top level in the SS7 stack.TCAP manages the communications between the subsystems and can joinmany messages into one logical transaction. TCAP can handle many con-current transactions between subsystems and maintains transaction IDs toset them apart. Since we are using SS7 over IP we use SCTP. SCTP isshort for Stream Constrol Transmission Protocol and is used as a transportlayer protocol. It was developed by the SigTran group when they foundthat the existing IP-transport protocols was not able to fulfill the reliabilitydemands for telecoms. SCTP can be used in any IP network. MTP Level 3User Adaption layer was developed by SigTran. In figure 3 M3UA is shownin context, it enables SCTP.

Finally we have MAP, which stands for Mobile Application Part. MAPenables the application nodes in the GSM network to communicate witheach other. MAP plays a vital part in this thesis. See section 4.5 for moreinformation on how we used MAP to build the HLR. There are other pro-tocols in the SS7 stack such as DTAP, BSS-MAP, TUP and ISUP. They areused for procedures such as call handling and will thus not be used here.

2.3 SMSSMS is a service which enables sending and receiving of application layertext messages in the network. The messages cannot be longer than 160characters, in many countries the encoding of the characters leads to evenshorter messages (for instance messages encoded in Urdu (Pakistan) can notbe longer than 70 characters). To deal with this constraint, longer messagescan be segmented into many smaller. The service can be used by operatorswho wish to inform their subscribers of temporary campaigns or offers. Themain use for the service is between subscribers who wish to communicate,but it can also be used between different application level nodes. For SMSto work there is a number of signaling messages sent between many differentnodes to get the message to the recipient. The HLR is situated roughly in

15

Figure 3: SCTP and M3UA

the middle of this, the other nodes queries the HLR for information aboutwhere the ME is, if the subscribers is barred or not and so on.

2.3.1 SMS delivery Example

To illustrate how the GSM network and the HLR works we will show howan SMS is received and propagated on the terminating end. This is alsoshown in figure 4.

The terminating side is more interesting since the originating subscriberslocation is known and does not need to do a lookup to find out which MSC touse. The figure shows the message in transit, it has finished the originatingpart of the procedure and arrived at a SMS-SC, an SMS Service Centre.This in turn hands over the SMS to the SMS-GMSC, which can identifywhich HLR to contact by use of the MSISDN. The HLR, in turn, knowswhich MSC the terminating subscriber currently is connected to and if it isavailable for short messages. The HLR also holds information whether thesubscriber is allowed to receive messages, it might be barred due to unpaidbills or a plan that does not allow messages. In this example, the subscriberis available and no barring is in place. Therefore the HLR returns the MSCaddress to the SMS-GMSC which forwards the message using an forwardSMoperation to the MSC. The MSC then forwards the SM to the subscriber

16

(ME A in the figure) and sends a response back to the GMSC which in turnresponds to the SMS-SC. The SMS-SC now knows that the message wasreceived and can remove the stored SM. If there were a problem along theway the SMS-SC can try again later.

Figure 4: MT-SMS procedure, showing the last part where the sms is deliv-ered to Mobile Equipment (on the right

2.4 Home Location Register (HLR)When an MSC wants to know where to send a message for a subscriber itquestions the HLR about the location of the subscriber, which replies with aVLR-address to which the MSC forwards the message. This is illustrated infigure 5. The figure shows a subscriber moving between two cells, generatingtraffic in the network. This starts what is called a location update procedure,which is described in more detail later, for now it is enough to say that thelocation information about the subscriber is updated.

2.5 ErlangErlang is a functional programming language that Ericsson began develop-ment of during the mid 1980s, see [11]. The purpose was to fit specific needsthat Ericsson had for their Telecom systems. The telecom industry neededa language which could meet up to the five nines availability demand. Thismeans that a telecom node should be available 99.999% of the time, always,off time for updating is not allowed. It should also scale well and haveacceptable performance.

2.5.1 Concurrency & Distribution

One of Erlangs major features is the virtual machine (VM) on top of whichthe programs are run. The VM has its own process scheduler separated from

17

Figure 5: Mobile Equipment moving between cells, prompting location up-date procedure

the operating system (OS) scheduler. The Erlang processes are smaller thanregular OS processes and does not require as much resources as OS pro-cesses. The processes has their own memory which is not shared betweenprocesses. If some information needs to be shared between processes, theinformation is copied and sent between them using interprocess communica-tion, making each holding its own copy of the information. Without havingany shared memory there is no need for memory locks and thus no memorydeadlocks. Interprocess communication is done by sending asynchronousmessages between the processes. These messages are collected in an inboxthat is associated with each process, the processes can choose to ignorethe messages or pick the messages that its interested in. The Erlang VMsupports transparently sending messages between different Erlang systems,which are also called nodes. The transparency means that there should beno difference between sending messages to processes on the same computerand over network to some other computer, however network latency usuallyimpairs the performance when using external nodes. There is also differentways to use external programs in the node, we will later use “Port Pro-grams”, where binary messages are sent between the the port program andthe Erlang node.

2.5.2 OTP

Erlang comes with a framework called Online Telecom Platform (OTP)which is used to develop the concurrent and fault-tolerant systems thatErlang is known for. OTP is a set of code libraries written in Erlang. Apartfrom providing the programmers with programs it also defines somethingcalled behaviors (similar to design patterns) which helps programmers to

18

build their systems in a good way. The behaviors are frameworks whichare used to develop concurrent and fault-tolerant systems. One importantconcept is the supervisor behavior. The supervisor is a process which job isto monitor other processes and restart them if necessary. Many supervisorcan be linked together in a supervision tree, as in figure 6, the root is oftenreferred to as the top supervisor.

Figure 6: A typical supervision tree, the boxes rep-resent supervisors and the circles workers, sourcehttp://www.erlang.org/doc/design_principles/des_princ.html.

2.6 MnesiaMnesia is Erlangs built-in relational database management system. It istightly integrated with Erlang, both written in Erlang and shipped withErlang. It was developed alongside Erlang to be a database fit for telecom,sharing many of its features, such as fault-tolerance and reliability. Mnesiasupport transactions and complex queries as well as fast key-value lookups.Since its implemented using Erlang there is no data mismatch between Mne-sia and its programming language, which makes it easier for programmersin the sense that they do not have to convert datatypes between the two.Schemas in Mnesia can be updated whilst running the system, which helpsfulfill the five nines availability demands. The schemas can even be redis-tributed between nodes while writing to the tables.

19

2.7 CouchDBCouchDB3 is a non-relational open source database which was developed byDamien Katz, now maintained by Apache Software Foundation. CouchDBstarted out written in C++, but was later rewritten in Erlang when thenice features of Erlang was discovered. CouchDB has a builtin web serverwhich is used to communicate with the database. It stores its records usingJSON4, uses Javascript to present data and a HTTP Rest to interface thedatabase. CouchDB features:

• RESTful API

• Multi-Version-Concurrency-Control

• User defined views, using map-reduce

• Multi Master replication model

2.7.1 Replication

CouchDB has a replication model in which it supports synchronization frommultiple replicas on different nodes. This means that you can take copies ofthe db, store it on different machines, do some work on each machine andstill be able to synchronize it later. With more and more work been donebeing mobile (on phones, netbooks, laptops) this is a feature which makesCouchDB very interesting.

2.7.2 Multi-Version-Concurrency-Control

CouchDB calls its stored entities documents. CouchDB keeps by default1000 revisions of a document before it starts to remove old revisions, youcan either manually remove revisions or configure the database keep a lowernumber of revision. Keeping the number of document revision on the defaultsetting, means that each revision of a document is stored, when you insertnew data the old data is kept alongside. To be able to access the correctdata, CouchDB uses unique document revision IDs. These IDs are veryimportant as they are also used for handling concurrent changes to thedatabase. Because of this system with multiple revisions, there is no needfor a locking system. The locking system is redundant since because thereis no need to edit data, instead of doing an edit a new version is insteadcreated. If two writes are done simultaneously, both writes will have uniqueIDs and the latest ID set as the current.

3http://couchdb.apache.org/

4http://www.json.org/

20

2.7.3 Potential drawbacks

CouchDB uses views to present data and these views need to be computed,the team behind CouchDB chose to defer the building of the views until thefirst query, which means that the first query will take longer time than laterqueries. If the documents are updated the views will not be refreshed untilthe next query which means that potentially each query might be precededwith a build of a view. CouchDB handles documents in JSON format, it isnot very good with binaries, however you can store binaries as attachments(which you can have any number of). CouchDBs RESTful API means thateach query needs to be packed in a HTTP request sent to the CouchDB webserver, even if the request is sent to a local webserver it adds overhead toeach query, why we expect the CouchDB approach to be slower. CouchDBsaves versions of all objects, meaning that if an object is stored and laterupdated, the original version is still kept, but the updated object is thecurrent object. There is limited use of this information for our application,why we want to remove all old versions. This is done by a feature calledcompaction, which unfortunately needs to be done manually in our version.Later versions of CouchDB have automatic compaction. The problem mightbe helped by lowering the number of kept revisions from the default of 1000versions to 1 version.

3 Design3.1 OverviewThe design phase was partly intermingled with the implementation phase,an initial design was made and then later revised during the implementationas the understanding of the problems increased. The Application design waspretty straightforward, the major part of the HLR is the database handling,thus the design of the tables is more important to get right. The require-ments we had was very broad, so the design phase involved examining theserequirements:

• Handle all MAP-operations related to SMS

• Easy configuration

• AuC capabilities

• No support for GPRS

We started out with what we felt was a minimal design with the intentto let it evolve during the implementation phase. GPRS was left out, butif time permitted would have been added, to begin with the GPRS datareceived was just ignored and not sent out.

21

3.2 Application DesignWe set out to implement the application for Linux, using a proprietarySS7 stack from Tieto Enator and then the HLR application on top of this.The SS7 stack communicates with the HLR application via an Erlang portprogram.

3.3 Database DesignSince the HLR/AuC shall indicate that the SMS services is available to thesubscribed user, a database storing subscriber data must be mainained. Thedata includes subscriber specific data and subscriber profile data commonfor many subscribers.

3.3.1 Subscriber data

The term subscriber data is used to designate all information associatedwith a subscription which is required for service provisions, identification,authentication, routing, sms handling, and operation and maintenance pur-poses.

Some subscriber data are referred to as permanent subscriber data, i.e.they can only be changed by administration means. Data that is sharedbetween subscribers is called profile data, this can only be changed by ad-ministrators.

There is also temporary subscriber data, which may change as a resultof normal operation of the system, e.g. location updates or other changesby the subscriber.

3.3.2 System Data

Apart from subscriber data, there are also tables holding system data, in-cluding information about which servers that are allowed to connect to thesystem. The HLR/AUC can store the following static system level data:

1. List of supported HLR Numbers, each with:

(a) HLR ID List

2. List of supported VLR Numbers, each with:

(a) LMU Identity

3. List of supported SC Addresses

4. List of supported SCF Addresses

5. List of supported MLC Numbers

22

3.3.3 Design criterias

In the design phase we designed the database tables used to store the sub-scriber and profile data, as well as system data. The tables were separatedand structured based on different criterias. One criteria was the temporalnature of the data, whether the data is changed by an administrator or up-dated as a result of a common operation. Another aspect is sequrity, forinstance all administrators accessing the database should not be able to seeall the data for a particular subscriber. Finally there is disk-access issues; ifthe records in the tables becomes to large we will suffer from IO-overheadswhen we try to access a particular data-field for a subscriber. This is dueto the fact that read/write-operations in Mnesia can only access an entirerecord in a table, there is no way to do individual field updates or lookups.

An important task before beginning implementing, was to pick out asubset of the subscriber data needed to support SMS services on top ofthe basic required services, including some other non-basic services, such asCAMEL support for SMS [13], Operator Determined Barring (ODB) andLocation Services (LCS). Some of the data are mandatory to all services,while other are operation dependent. Others end up in a gray zone wherethe support could be useful, yet functionally it will work without it. Arather large such restriction we did was to not support any GPRS relatedfunctionality, such as SMS over SGSN. Supporting GPRS would require alarger implementation and is not strictly needed for the scope of this thesis.

3.4 Subscriber dataSubscriber data is the collection of data that specifies the subscription ofa subscriber, this includes all information about subscribed services, iden-tification, barring information and authentication data. The specificationGSM 03.08 [2] specifies what subscriber data an HLR should keep. For anHLR which only support SMS, we could choose a subset of the parameterslisted. In the table 2 the specified parameters and their type, temporary(T) or permanent (P), as well if they are selected (YES or NO) is listed.The parameters that are not selected are mostly used for calling, which theSMS_HLR does not support.

3.4.1 imsi_lookup

The IMSI is the key in many of the tables, but in some MAP-operationthere is no IMSI provided only MSISDN. The imsi_lookup, Table 3, is usedto lookup the imsi of a subscriber when only the MSISDN is given in aMAP-operation.

23

Parameter Type SelectedIMSI P YESMSISDN P YESLMSI T YESMobile Station Category P NOAuthentication Key P YESRAND/SRES and Kc T YESMSRN T YESVLR Number T YESMSC Number T YESRoaming Restriction T YESProvision of Bearer Service P YESProvision of Teleservice P YESBC Allocation P NOSubscription Restriction P YESProvision of suppl. services P YESCUG interlock code P NOCUG index P NOPer call basis subscription P NONotification to calling party P NOUser-to-user signalling service ind. P NOCUG facility P NOPreferential CUG facility P NOBarring incoming calls within CUG P NOBarring outgoing calls within CUG P NOMaximum number of conferees P NOControl of barring services P NOForwarded-to number T NORegistration status T NONo reply condition timer T NOCall barring password T NOActivation Status T YESCheck Suppl. Services flag T YESAccess priority class P YESMessages Waiting Data T YES

Table 2: This table shows the parameters defined in [2], the ones marked“YES” are used by the SMS_HLR

24

msisdn E.164 addressimsi imsi

Table 3: Table making a link between imsi and msisdn

3.4.2 subscriber

The main table is called “subscriber”, Table 4, where most of the user infor-mation is stored. To keep the size of the subscriber table down, the hlr keepsprofiles for common ss, odb, lcs and camel settings. This means that whena service is applied, modified or removed (either via an administrator orsubscriber action), a different profile is selected. During runtime this meansthat the table only holds a reference to another table, instead of holdingthe complete description of the setting, this saves size during lookups butcreates a dependancy to another table.

imsi imsimsisdn E.164 ISDN addressteleserviceList a list 5

accessRestriction_Data list, valid elements are’utranNotAllowed’ and ’geranNotAllowed’subscriber_status true or false, defaults to truenetwork_access_mode ’only_MSC’lcs_profile_id integer referring to an entry in the lcs_profile tableodb_profile_id integer referring to an entry in the odb_profile tabless_profile_id integer referring to an entry in the ss_profile_id tablecamel_profile_id integer referring to an entry in the camel_profile_table

Table 4: Subscriber table

3.4.3 temporary_data

When the HLR restarts after a failure it sets the check_ss_indication forall subscribers, later when the HLR gets an update location request for themarked subscriber, the HLR sends a check forward indication to the VLRthat sent the update location request. This data is stored in the table called“temporary_data” and is shown in Table 5

imsi imsicheck_ss_indication true or falsems_purged_for_non_gprs true or false

Table 5: Temporary data

25

3.4.4 roaming_data

The roaming_data Table 6 handles information regarded to roaming. Itkeeps the address of the VLR and MSC. It also keeps track of the LMSI ifone has been assigned.

imsi imsivlr E.164 ISDN addressmsc E.164 ISDN addresslmsi E.164 ISDN address

Table 6: Table for roaming data

3.4.5 MWI and MWD

If a subscriber cannot receive an SMS, the reason for this is kept in theMessage Waiting Indicator or MWI for short, Table 7. Here you can findinformation about if a subscriber has a message waiting and the reason towhy the subscriber has been unable to receive the message

The last element in the MWI is the MWD. The MWD keeps a list ofservice centers that has tried to reach the subscriber, it also keeps track ofwhich ISDN-address, that they should send an alert when the subscriberattaches/memory is available. This MSISDN is called the MSISDN-Alert.

imsi imsimnrf true or false, defaults to falsemnrr_msc integer, reason for absence, only two options are valid, 0 and 1 6

mcef true or false, defaults to falsemwd mwd-record

Table 7: The Message Waiting Indicator

3.4.6 lcs_routing_info

The lcs_routing_info Table 8 holds information needed for the locationbased services. For LCS to work, the HLR must specify MSC- and GMLC-address, as well as location capabilities for the UE (among other things if ithas support for assisted GPS positioning) and also if LCS over CS networksis supported by the phone (cs_LCS_NotSupportedByUE).

3.4.7 camel

Camel is short for Customised Applications for Mobile network EnhancedLogic and is specified in [14], in short it enables the operators to enable or

26

imsi imsinetwork_node_number E.164 ISDN Addresss of the MSCsupported_LCS_capability integer, 0 to 5v_GMLC_address IP address of V-GMLC for MSCcs_LCS_NotSupportedByUE true or false, defaults to false

Table 8:

disable the subscribers’ ability to receive and send SMS for the subscribers.The camel-data is found in Table 9. The data defines for what and wherein the call-flow a camel service can be supported, by the VLR (o-csi,d-csi etc). There is also information about what phase of CAMEL that theVLR supports (there is a number of versions of CAMEL, called phases, inwhich different CAMEL services are defined, for SMS phases 3 and 4 areneeded). Because only SMS is supported, there is also place to store aCAMEL capacity for mo-sms and mt-sms, negotiated between the networkand the handset. This table is referenced by the subscriber table.

imsi imsivlr_offeredCamel4CSIs a list with allowed values :

’o-csi’, ’d-csi’, ’vt-csi’, ’t-csi’,’mt-sms-csi’ ’mg-csi’and ’psi-enhancements’

vlr_supportedCamelPhases [N,...] 1 =< N =< 4mo_sms_csi_VLR_NegotiatedCamelCapHandling undefined or 3mt_sms_csi_VLR_NegotiatedCamelCapHandling undefined or 4

Table 9: CAMEL subscription information

3.4.8 lcs_profile

The lcs_profile table in Table 10 defines profiles for use with location basedservices, this table is referenced by the subscriber table. Each profile holdsa list of GMLC numbers from which a location request for an specific ME isallowed (this procedure is shortened MTLR) , it also holds the IP-addressof the GMLC in the subscribers home network.

id integergmlc_numbers list of E.164 Addressesh_GMLC_address IP address of H-GMLC

Table 10: The table holding the lcs profile

27

3.4.9 odb_profile

Table 11 shows how the Operator Determined Barring (ODB) profiles aredefined. The table is referenced by the subscriber table. The table informa-tion is changed by administrators.

id integerodb_general_data see belowodb_plmn_specific_data list, valid entries : ’plmn-

SpecificBarringType1’,’plmn-SpecificBarringType2’,’plmn-SpecificBarringType3’,’plmn-SpecificBarringType4’

Table 11: Table showing the Operator Determined Barring (ODB))

odb_general_data is a list of the failry self explanatory atoms:

• allOG-CallsBarred

• internationalOGCallsBarred

• internationalOGCallsNotToHPLMN-CountryBarred

• interzonalOGCallsBarred

• interzonalOGCallsNotToHPLMN-CountryBarred

• interzonalOGCallsAndInternationalOGCallsNotToHPLMN-CountryBarred

• allIC-CallsBarred

• roamingOutsidePLMNIC-CallsBarred

• roamingOutsidePLMNICountryIC-CallsBarred

• roamingOutsidePLMN-Barred

• roamingOutsidePLMN-CountryBarred

• premiumRateInformationOGCallsBarred

• premiumRateEntertainementOGCallsBarred

• premiumRateInformationOGCallsAndEntertainementOGCallsBarred

• ss-AccessBarred

For example: [’ss-AccessBarred’, ’roamingOutsidePLMN-Barred’].

28

3.4.10 ss_registration_data

The ss_registration_data table in 12 contains information the supplemen-tary services (SS) defined for the subscriber. The table is referenced by thesubscriber table. There is one table per subscriber and it contains a pass-word, for changing the services, the number of failed attempts of supplyingthe password and whether the subscriber is blocked from changing the SS.

imsi imsiregistration_passwd DES encypted binarywrong_passwd_attempts_count N = 0..2, where N is the num-

ber of times there has beenincorrect passwords, N > 2means blocked.

blocked true or false

Table 12: The ss_registration_data table

3.4.11 ss_profile

The ss_profile table in 13 keeps profiles for supplementary services, thistable is referenced by the subscriber table. The ss_subscription_optionpart is a record containing:

• ss_Code, which is an integer 0 =< N =< 255

• barring_condition, a list of programs

• control_of_barring_services, defines whether the subscriber can usea passwd or if it is only the administrator that can change the SS

The table also holds information about call barring for different SS’s,

• ss_Code, an integer pointing out a specific SS

• callBarringFeatureList, contains the state of the call barring service.

The state of the call barring service is in turn held in a record whichshows which basic service it is applicable for and whether it is enabled ornot.

id integerss_subscription_options defining the SS

call_barring_lst defines the call barring for the SS

Table 13: The ss_profile table

29

provisioning_state provisioned | not_provisionedregistration_state registered | erased | not_applicableactivation_state not_active | active_and_operative | active_and_quiescent

hlr_induction_state induced | not_induced

Table 14: Supplementary Status table

id integermo_sms_CSI mo_sms_csimt_sms_CSI mt_sms_csi

Table 15: The camel_profile table

3.4.12 authentification_data

The auhtentification_data, found in Table 16 holds data used by the AuCfunction to authenticate users. Apart from a shared secret, the auhtentifi-cation_data also holds information about the latest used challenge. Thechallenge can be reused a configurable amount of times, why this informa-tion needs to be stored.

imsi imsiki 128 bit binary key

challenges list of challenge information

Table 16: Authentication data table

4 Implementation4.1 supervision tree4.1.1 sms_hlr_sup

The main supervisor of the SMS HLR starts one worker and two supervisorprocesses. The worker is named sms_hlr_helper and holds configurationparameters which can be updated from a configuration file during runtime.The supervisor processes are hlr_sup and tcap_sup.

4.1.2 hlr_sup

hlr_sup starts and supervises a timeout handler, which keeps track of time-outs for location updates and mwd. When a location update is received atimer is started by this handler, when time runs out it deletes the roaming-,camel- and lcs routing data for the subscriber. When the mwd timer runsout, it removes the information about notification to service centers.

30

Figure 7: The process tree, source: the picture was generated by the Erlangappmon application.

4.1.3 tcap_sup

Tcap_sup starts a tcap instance supervisor which makes sure there is aconnection to the SS7 stack through an external TCAP server. When theTCAP server gets a MAP request it starts a MAP handler for this, theMAP handler is a finite state machine (gen_fsm) named map_dialog. Themap_dialog checks the syntax of the MAP request and runs it through afilter. The filter checks if the sender is allowed to send any or specific MAPrequests to the HLR or not. One can also limit the allowed MSISDN numberseries. Whether the sender, request-type, etc is allowed or not is configurablein runtime.

31

4.2 Interfaces4.2.1 MAP Interfaces

The HLR has three MAP interfaces.

• MSC-MAP

• VLR-MAP

• GMLC-MAP

In each interface there can be both incoming and outgoing requests, e.g.the HLR can either act as a server and receive requests, or act as a clientand send requests. MAP is defined in the 3GPP standards using ASN.1notation with basic encoding rules, we used the Erlang OTP ASN1 supportto create modules to encode and decode MAP.

4.2.2 TCAP Interfaces

The tcap connection is taken care by a configurable set of supervisedgen_servers. The gen_servers run an external Erlang process in the formof a C-executable (named tcap_server) which is used to connect to the SS7-stack.

There are two parts to the tcap interface, tcap_manager which keepstrack of registered tcap handlers. The tcap handlers are supervised bytcap_sup, which can restart the handlers if they crash. The number andparameters used when starting each tcap handler can be configured.

4.2.3 Internal Interfaces

Internally we have an interface between map_dialog and the hlr_fsm. Whentcap has a new incoming map-request an internal seizure request is generatedand sent to the HLR_FSM. If there is an available hlr_fsm process, theHLR_FSM replies with a response including the pid for the sms_hlr process.This enables the TCAP process to forward the MAP request as describedin 4.1.3.

4.3 Database ImplementationTo interface with the database there are two modules, hlr_api andhlr_oam_api which takes care of reading and writing to the database. Sincethe db-change made is transparent the modules are the same regardlesswhether using Mnesia or CouchDB.

When using CouchDB instead of Mnesia the dets calls to are changed tocalls to ecouch. To enable this, dets starts a module called db_server, whichin turn handles the connection to ecouch. Dets uses db_server for accessing

32

the database, and db_server uses ecouch to access the database. The use ofdb_server will make it easier to change to other databases in future work.

4.4 CouchDB ConsiderationsBecause there is no automatic compaction of the CouchDB database andthe CouchDB keeps 1000 revisions the database would grow for each up-date eventually running out of disk space. By manually compacting of thedatabases, the problem could be removed temporary (shrinking a 600 MBtable to a 4MB table), but this is not usable in a production system. Soinstead of keeping all revisions, we chose to configure the database to keeponly one revision for each object. Each time a new transaction is started anets-table for the transaction is created, unfortunately the transaction tookso much time that the maximum number of ets-tables were created andnew transactions were discarded. To fix this problem, we changed to using”dirty” mnesia operations, without transactions. These operations are nor-mally faster than operations with transactions, but scarifies the atomicityand isolation that comes with using transactions.

4.5 MAP OperationsAn HLR taking care of SMS has to take care of a lot of different scenariosinvolving different MAP operations and procedures. MAP operations aredivided into five different categories:

1. Mobility Management, keeping track of where the subscriber is.

2. Operation and Maintenance, operator operations to maintain sub-scribers and SS7 nodes. Also tracing.

3. Call Handling, taking care of calls.

4. Supplementary Services, operations for subscribing and maintainingsupplementary services.

5. Short Message Service, all operations concerning SMS.

6. Location Service Management Services

For each group the operations we implemented were:

1. Mobility Management

• MAP update Location

• MAP cancel Location

• MAP send Identification

33

• MAP purge MS

• MAP Send Authentication Info

• MAP Authentication Failure Report

• MAP Insert Subscriber Data

• MAP Delete Subscriber Data

• MAP Reset

• MAP Forward Check SS Indication

• MAP Restore Data

• MAP Any Time Interrogation

• MAP Provide Subscriber Info

2. Operation And Maintenance

• MAP Send ISSI

3. Call HandlingSince the HLR does not support calls, no operations from this groupwere implemented.

4. Supplementary ServicesSupplementary services is a standardized set of extensions used whencalling, i.e. caller id, call forwarding. These extensions are used withcalls, therefore no operations from this group were implemented

5. Short Message Service

• MAP Send Routing Info For SM

• MAP Report SM Delivery Status

• MAP Ready For SM

• MAP Alert Service Centre

• MAP Inform Service Centre

6. Location Service Management Services

• MAP Send Routing Info for LACS Service

• MAP Provide Subscriber Location Service

34

4.5.1 Network initiated MAP procedures

MAP Update Location (UL) procedure

The HLR supports Update Location (UL) procedure defined in [3]. TheHLR can optionally log UL Timestamp, IMSI and IMEI SV for MSC. Forthe first UL received for the subscriber from a VLR and no Skip SubscriberData Update for MSC is indicated, the HLR:

1. Sends Insert Subscriber Data (ISD) without including Network accessmode to the VLR

2. Receives the ISD Response

3. If the HLR stored an old VLR address for the subscriber, the HLR:

a Sends Cancel Location (CL) including LMSI, if stored, and Can-cellation Type indicating Update, to this old VLR

b Receives CL Response from this old VLR

If the Check SS Indication is set for the subscriber, the HLR:

1. Sends Send Forward Check SS Indication to the VLR.

2. Resets Check SS Indication for the subscriber.

The HLR then:

1. Sends UL Response to the VLR.

2. Restarts the Location Update timer for the subscriber.

If successful UL Response is indicated, the HLR removes Absent Subscriber(MNRF) and MS Not Reachable via MSC Reason (MNRRMSC) for theprovided IMSI, and initiates the sending of Alert SC procedure for the IMSIas MWD subscriber, as described in section 2.9.9.

MAP Purge MS (PMS) procedure

The HLR supports Purge MS (PMS) procedure defined in reference [3]. Ifthe received PMS includes the same VLR Number as stored for the sub-scriber in HLR, the HLR includes Freeze TMSI in the PMS Response.

35

MAP Restore Data (RD) procedure

When the HLR receives Restore Data (RD) from a VLR, the HLR checks ifthe subscriber is known and if the subscriber is known:

1 Sends Insert Subscriber Data (ISD) including Network access mode tothe VLR

2 Receives the ISD Response

The HLR then:

1. Sends RD Response to the VLR including MS Not Reachable Flag ifthe MS Not Reachable flag was set for the subscriber in the HLR

MAP Send Authentication Info (SAI) procedure

In this case the SMS_HLR acts as a AUC. When the AUC receives SendAuthentication Info (SAI), the AUC only accepts VLR as Requesting NodeType. The AUC also ignores the Immediate Response Preferred Indicator.The AUC analyzes the most significant digits in the IMSI to select theserved HPLMN. The authentication triplets/quintuplets are generated onper served HPLMN in the AUC using operator defined authentication andkey generating algorithms (A3/A8) and functions (f0, f1, f1*, f2, f3, f4, f5 andf5*) per served HPLMN. We chose to use the specified functions in the 3gppspecifications (milenage), if the operator wants to change he needs to specifythem in erlang modules and configure the system to use this module. TheAUC uses Requesting PLMN ID, if received, to select the served VPLMN.The AUC returns an empty response if authentication triplets/quintupletsare not available.

MAP Authentication Failure Report (AFR) procedure

When the AUC receives Authentication Failure Report (AFR), the AUCcan optionally log Timestamp and all AFR received parameters (CallingGT, IMSI, Failure Cause, Reattempt, Access Type, Rand, VLR Number).

MAP Send Routing Info for SM (SRISM) procedure

One of the most important operations for HLR, making sure that the routinginformation for SMSs is handled correctly, a big operation.

When the HLR receives Send Routing Info for SM (SRISM), the HLRignores any included GPRS parameters. The HLR checks the provided re-questing party and can return an error message containing “Facility NotSupported” if the requesting party is not allowed to request routing infor-mation. If the subscriber is marked as available, i.e. does have enoughmemory to receive messages and is not absent, or if the subscriber is not

36

marked as available but the request for routing info included an sm-RP-PRI, and the subscriber’s real IMSI, LMSI and MSC Number is stored asRoaming Data, the HLR returns a positive response including this RoamingData.

In such case an MSISDNAlert is stored for the MSISDN, the responseis also preceded by the HLR sending an InformSC including the MSISDN-Alert. If an MWD is stored for the MWD subscriber, the HLR then restartsthe MWD timer for the MWD subscriber.

If the MWD, for either the MSISDN or MSISDNAlert, indicates an ab-sent subscriber or a subscriber out of memory, and no smRPPRI was in-cluded in the request, or there is no roaming data for the subscriber, theHLR includes the given SCaddress in the MWD List of SCaddresses, if notalready included. The purpose is to be able to contact the SC later whenthe subscriber is reachable again.

If there were no MWD data for the MWD subscriber, the HLR createsthe MWD storing Absent Subscriber and MS Not Reachable via MSC Rea-son as applicable. The HLR then restarts the MWD timer for the MWDsubscriber. The HLR then sends an InformSC including Absent Subscriber,MS Memory Capacity Exceeded and MS Not Reachable via MSC Reasonas stored, and MSISDNAlert if stored. The HLR then returns a negativeresponse indicating Absent Subscriber.

MAP Report SM Delivery Status (RSMDS) procedure

When receiving the request, the HLR runs the filter function and checks thereceived SCAddress, and returns Facility Not Supported if the SC-Addressis not ok. If unsuccessful SMDelivery Outcome is indicated, the HLR up-dates the MWD for the MSISDNAlert, if stored for the MSISDN or theMSISDN if not stored, ith Absent Subscriber (MNRF) or MS Memory Ca-pacity Exceeded (MCEF) as provided, MS Not Reachable via MSC Reason(MNRRMSC) as provided, and includes the given SCaddress in the MWDList of SCaddresses, if not already included. The HLR then restarts theMWD timer for the MWD subscriber. If an MSISDNAlert is stored for theMSISDN, the HLR also includes the MSISDNAlert as Stored MSISDN in theresponse. If successful SMDelivery Outcome is indicated, the HLR removesAbsent Subscriber (MNRF), MS Memory Capacity Exceeded (MCEF) andMS Not Reachable via MSC Reason (MNRRMSC) in the MWD for theMSISDNAlert, if stored for the MSISDN or the MSISDN if not stored, andinitiates the sending of Alert SC procedure for the MWD subscriber, asdescribed in section 4.5.1.

37

MAP Ready for SM (RSM) procedure

When the HLR receives Ready for SM (RSM), the HLR ignores all GPRS-related parameters (Alert Reason Indicator) and IMSrelated parameters(Additional Alert Reason Indicator).The HLR updates the MWD for theIMSI with Absent Subscriber (MNRF) or MS Memory Capacity Exceeded(MCEF) as provided by Alert Reason, and removes MS Not Reachablevia MSC Reason (MNRRMSC) if the provided Alert Reason indicates MSPresent.The HLR then initiates the sending of Alert SC procedure for theMWD subscriber, as described in section 4.5.1.

MAP Sending of Alert SC (ASC) procedure

If the stored MWD does not indicate Absent Subscriber (MNRF) or MSMemory Capacity Exceeded (MCEF), the HLR sends Alert SC to all MWDstored SCaddresses for the MWD subscriber. In such case, at successfulAlert SC response, the SCaddress instance is removed from the MWD datafor the MWD subscriber. If a successful Alert SC response is then receivedfor all stored SCaddresses, the HLR removes the MWD data for the MWDsubscriber and stops the MWD timer for the MWD subscriber.

MAP Send IMSI (SI) procedure

When the HLR receives Send IMSI (SI), the HLR lookups the IMSI storedfor the MSISDN received in the request, if it finds an IMSI it includes it inthe response otherwise it indicates failure to find the subscriber.

MAP Any Time Interrogation (ATI) procedure

When the HLR receives Any Time Interrogation (ATI), the HLR can screenthe received gsmSCFAddress and return ATI Not Allowed if not configuredto be allowed. All CSdomain specific information can be requested.

The HLR then:

1. Sends Provide Subscriber Information (PSI) to the stored VLR address

2. Receives PSI Response

3. Sends ATI Response including all PSI Response provided info

MAP Send Routing Info for LCS (SRILCS) procedure

When the HLR receives Send Routing Info for LCS (SRILCS), the HLRcan screen the received MLC Number and return Unauthorized requestingnetwork if not allowed. If the HLR stored subscriber data indicates CS LCSNot Supported by UE, the HLR returns Facility Not Supported. The HLR

38

can only return the subscribers real IMSI or MSISDN, LMSI, MSC Number(as Network NodeNumber), Supported LCS Capability Sets for MSC, H-GMLC Address and VGMLC Address, if stored.

4.5.2 OAM initiated MAP procedures

OAM Cancel Location (CL) procedure at attached subscriber

The HLR can send Cancel Location (CL) to an attached subscriber includingLMSI, if stored, and Cancellation Type indicating Subscription Withdrawalto the VLR stored at:

A Operator withdrawal of a subscription

B Operator ordered/enforced Location Update

The HLR then receives CL Response and acknowledges this to the operator.

OAM Insert Subscriber Data (ISD) procedure at attached sub-scriber

The HLR can send Insert Subscriber Data (ISD) to an attached subscriberwithout including Network access mode when:

1. The operator has applied, changed or removed Operator DeterminedBarring.

2. The operator has changed the subscription of one or more supplemen-tary services, basic services or data of a subscriber (however not atwithdrawal of a Basic or Supplementary service, when the DSD pro-cedure below is used instead).

The HLR then receives ISD Response and acknowledges this to the operator.

OAM Delete Subscriber Data (DSD) procedure at attached sub-scriber

The HLR can send Delete Subscriber Data (DSD) to an attached subscriberat:

1. Operator withdrawal of one or more supplementary services or basicservices (however not in case of erasure or deactivation of supplemen-tary services, when an Insert Subscriber Data is initiated instead).

The HLR then receives DSD Response and acknowledges this to the opera-tor.

39

OAM Reset (RT) procedure

After an HLR restart, the HLR can send a Reset to each of its configuredlists of VLR Addresses to indicate that an HLR failure has occurred. OneReset is sent for each combination of configured VLR Address and configuredVLR Number. Each Reset includes the HLR ID List as configured for theincluded VLR Number. After an HLR restart, the HLR sets Send ForwardCheck SS Indication for each subscriber.

4.5.3 OAM initiated HLR procedures

OAM expiry of Update Location (UL) timer procedure

At expiry of Location Update timer for an MSISDN, the HLR removes theRoaming Data for the MSISDN.

OAM expiry of MWD timer for MSISDN procedure

At expiry of MWD timer for an MSISDN, the HLR removes the MWD Datafor the MSISDN.

5 Evaluation5.1 TestingTo test two virtual machines were used, one with the HLR installed and theother with a traffic generator, MTG, installed. Both nodes used a propri-etary SS7 stack configured for SS7 over IP. Both database backends weretested separately, exchanging the backend in the HLR node between thetests. The same SS7 and HLR configuration were used for both backendvariants. The MTG is configured to have dual roles, acting as both VLRand MSC during the testing. The MTG replies with a hard-coded responsewhen the HLR queries it. For the performance test, we decided to go for lotsof location updates, simulating many users changing positions. The MTGgenerated lots of Update Location procedures (ULs) which it sent to theSMS-HLR. The ULs are made from a list of “programs”, each “program”describes one UL procedure, with the minimum required data hardcoded.When a UL is initiated a MAP-Location-Update request is sent from theMTG to the HLR. The MTG keeps track of the starting time in a table.When the HLR receives the UL request it makes a set of lookups in thedatabase in order to retrieve enough subscriber data to make a MAP-Insert-Subscriber-Data (ISD). The MTG receives the ISD and then replies with ahardcoded ISD-response. Upon receiving the ISD-response, the HLR endsthe UL procedure with sending a MAP-Update-Location response to theMTG. When the MTG receives the the UL-response it notes the end time

40

and saves an entry in the table with starting and stopping time. This datais then used in creating statistics.

Figure 8: This figure shows the Update Location test. Source: generated athttp://www.websequencediagrams.com

This round, described in Figure 8 from traffic generator to HLR andback to traffic generator, counts as one successful traffic case. If there wasan error for one “program”, an error counter is incremented. For each testboth start- and end time, as well as the result from the HLR is stored.

5.2 ResultsIn the first test we added 5000 subscribers and timed the time it took toadd them in microseconds using an erlang function:

timer:tc(subscriber_util,populate_db,[]).

41

For Mnesia it took an average of 33707642.2 microseconds (337.08 sec-onds) to add these 5000 subscribers to the db.

For couch_db we got a much higher average and a rising time.

Figure 9: Time to populate the DB with 5000 subscribers

The average on these ten runs is 709967453.3 microseconds (709.97seconds). So Mnesia is faster by a factor of 2. Even when we usecouchdbs compaction, which we need to apply on the ss_registration_data-, temporary_data-, lcs_routing_info-, subscriber-, roaming_data-, mwi-, authentification- and imsi_lookup tables, we get similar response times(707.5 seconds). The second test we did was to run a high number of loca-tion updates from the sms_mtg node to the sms_hlr node. We configuredthe sms_mtg to send 500 location updates, the first test with the ordinarymnesia database could not be compared to the tests with the couchdb back-end since the erlang transactions management broke down. The databasetransactions started to take too long time so that the HLR started to dropthe application transactions. To solve this we decided to skip the mnesiatransaction manager and use dirty operations like discussed earlier in section4.4. As explained earlier we could not get any results from these tests.

42

6 Discussions and ConclusionsThe results we got from test one shows that our implementation with theCouchDB backend performs very bad against Mnesia. Also we could notprovoke any fatal Mnesia failures, instead it was CouchDB that over timehad If the results from the CouchDB tests had been close the results ofMnesia, there might have been more value in actually continuing testing, butwhen the initial tests showed this bad performance in comparison, somethingdrastic would have to be done to improve the results. When we removed thetransaction handling from the CouchDB we probably sped up the process abit. An interesting test is to see if the transaction-less version of CouchDBcould be faster. We did not however have time to test this. We did fulfillour goal of making a working HLR and this HLR has been used in otherprojects since.

6.1 Problems6.1.1 SS7 Stack

In the beginning of the project we used a beta version of a SS7 stack, whichwas hard to configure and prone to errors. Troubleshooting errors and tryingdifferent configurations took a lot of valuable time we could have spenttesting and implementing. In the end of the project we got the option tochange stack to an official release which we decided to do. The new stackwas easier to configure, troubleshoot and use, but featured a little differentinterface which took a little time to get right. All in all the decision tochange stack was beneficial since it proved a lot more stable when runningtests.

6.1.2 MTG

Mobile Arts provided us with a prototype for a traffic generator. The trafficgenerator was extended with support for all operations that were neededin our tests. For the load-tests that we wrote there is an open-source loadtester which is called Tsung, earlier known as Tsunami. Tsung is primarilyused for load-testing web-services but there is an easy way to write plugins.The plugins can be written in Erlang making it a good match for us.

6.2 Lessons LearnedThis section deals with lessons learned from running the prototype(s). Weshould have used a final version of the SS7 stack from the start, the purposeof the thesis was not to evaluate SS7 stacks but ended up partly doing so.

43

6.3 Future workThere are more databases to try out, in our preliminary work we looked atPostGRESQL7 which is a fast and widely used database, we hoped to beable to implement a backend for this too, but we ran out of time and decidedto leave this for future work instead. Apart from CouchDB there have beenmany advances among the non-relational databases, the latest years moredatabases have emerged. Amazon released a paper [16] on Dynamo, whichis a technology Amazon use to get a scalable, flexible key-value storage withhigh-availability features. Apart from Dynamo, there is also Cassandra8,MongoDB9 and Riak10 (which was inspired by the paper on Dynamo). Thereare more MAP-operations to implement, this means more work on boththe MTG and the HLR. The MAP-protocol has evolved during some timeand there are three different versions. When a MAP-dialogue is starteda common version should be decided on through protocol. However, wechose to only support the newest version when possible, otherwise we choosethe highest possible version (almost always version 3). The team behindCouchDB will release an Erlang-API in the future which would bypass thecurrent slow HTTP-interface 11. A version of the sms_hlr was also usedby the project CS course on Uppsala University in the fall semester 2010,the students implemented an SMS capable MSC and implemented a smallmobile network capable of SMS. There are plans to extend that version ofthe sms_hlr so that it support calls.

6.4 Transaction problemDuring the development of the couchdb version of the sms_hlr a problemappeared with the Mnesia transaction handling. Each time a new trans-action is made using mnesia, an ets table named mnesia_trans_store iscreated, this is used to store information about the transaction. When thetransaction ends, the ets table is removed, this should be a very quick op-eration. But when using CouchDB for a backend, the transactions take somuch more time to complete that the number of created ets-tables hit themaximum limit for number of current ets-tables in the system. When thelimit is hit, new ets-tables cannot be created so the transactions started tofail. We could either speed up the transactions or remove transactions all-together. We decided to remove the transactions and use dirty-operationsinstead, this was the quickest way to move forward.

7http://www.postgresql.org/

8http://cassandra.apache.org/

9http://www.mongodb.org/

10http://basho.com/riak/

11http://wiki.apache.org/couchdb/Frequently_asked_questions#i_can_has_no_http

2009–11–22

44

6.5 SummarySince CouchDB keeps revisions of everything and needs to compacted byhand and the data in SS7 is often changed and old data is usually of nointerest, CouchDB makes a poor match for telecom. We did not experiencethe well-known dets-bug while we tested. So we do not know if the Couch-flavored Mnesia suffers from the same problem or if it is unrelated. Lookingat the aims and objectives we set out to achieve, we can see that:

1. A version of the sms_hlr was used in a real-world application, namelyby the students at Uppsala University.

2. CouchDB is a bad match for telecom.

A Appendix A AcronymsAUC Authentication Centre, serves to authenticate each SIM card that at-

tempts to connect to the GSM core network. This step has to becompleted before the HLR is contacted. An encryption key is alsogenerated to encrypt all wireless communication. Acceptable Cell cellthat the UE may camp on to make emergency calls. It must satisfycertain conditions.

AuC - Authentification Centre.

BSC - Base Station Controller

BSS - Base Station Subsystem

BTS - Base Transceiver Station

EIR - Equipment Identity Register, contains information about all validmobile equipment in the network.

GGSN - Gateway GPRS Support Node

GMLC - Gateway Mobile Location Centre

GMSC - Gateway MSC, most interfaces deals with this one. All call, sms gothrough here.

GPRS - General Packet Radio Service

HLR - Home Location Register

HPLMN - Home Public Land Mobile Network

45

Handoff - The process of transferring an ongoing call or data session from onechannel to another. For example when a phone moves from one cellto another and a call is transferred between cells to avoid terminationof call.

IMEI - International Mobile Equipment Identity, check each MEs IMEI with*#06#

IMSI - International Mobile Subscriber Identity, the SIM card ID.

MCEF - Mobile-Station-Memory-Capacity-Exceeded-Flag - MCEF

MNRF - Mobile-station-not-reachable-flag - MNRF

MNRG - Mobile-station-Not-Reachable-for-GPRS - MNRG

MNRR-MSC - Mobile-Noot-Reachable-via-theMSC-Reason - MNRR-MSC

MNRR-SGSN - Mobile-Not-Reachable-via-the-SGSN-Reason - MNRR-SGSN

MS - Mobile Station

MSC - Mobile Switching Centre

MSC Message Switching Center

MSISDN - Mobile Subscriber International Subscriber

MSRN - Mobile Station Roaming Number used to route an incoming call.

MTG - Map Traffic Generator

MTP = Message Transfer Part

MWD - Messages Waiting DAta

MWI = Message Waiting Indication

NSS - Network and Switching Subsystems

OSS - Operations Support Subsystem

PC - Point code, like an IP-adress. Each SP has a unique PC. Inter-national network nodes use a 14-bit PC, except for North Americaand China which use an incompatible 24-bit PC, and Japan whichuses a 16-bit PC. International and National PCs are not compatibleand are only valid within the different networks. 3-level hierarchy,NETWORK:CLUSTER:MEMBER NUMBER. Each level has a 8-bitnumber, between 0 and 255.

PDP - Packet Data Protocol

46

PDU - Protocol Data Unit

PLMN - Public Land Mobile Network.

SC - Service Center

SGSN - Serving GPRS Support Node is a main component in the GPRSnetwork. Performs the same functions as the MSC for voice traffic.SGSN and MSC are often co-located. The SGSN is connected tothe BSC. The SGSN is the service AP to the GPRS network for themobile user .Serving GPRS Support Node, responsible for deliveringdata packtes from and to the mobile stations within its geographicalservice area.

SIM - Subscriber Identity Module

SM MO - Short Message Mobile Originated

SM MT - Short Message Mobile Terminated

SMSC - Short message service centre, supports sending and reception textmessages.

SMS - Short Message Transfer Service

SP - Signaling Point, Network node, building blocks of the SS7 network.SPs can be of different types, STP, SCP and SSP.

SSN - Sub-System Number

SSP - Service Switching Point is a voice switch with SS7 functionality. Canoriginate and terminate messages, but not transfer

STP - Signal Transfer Points, resposible for the transfer of SS7 messagesb/w other SS7 nodes, much like a router in the IP network. STP:sonly route/transfer messages.

TMSI - Temporary Mobile Subscriber Identity, used for giving MEs tempo-rary ids, used for roaming (when VLRs are used). Used as a substituefor the IMSI to limit the number of times the IMSI is broadcastedover the open air interface. These are issued during the location up-date procedure.

TMSI - Temporary Mobile Subscriber Identity, used for giving MEs tempo-rary ids, used for roaming (when VLRs are used). Used as a substituefor the IMSI to limit the number of times the IMSI is broadcastedover the open air interface. These are issued during the location up-date procedure.

47

TPDU - Transfer protocol data unit

UE - User Equipment

UNRI - UE‘-’Not‘-’Reachable‘-’for‘-’IP - UNRI

UNRR - UE‘-’Not‘-’Reachable‘-’Reason - UNRR

VLR - Visitor Location Register, DB in a mobile comm network associatedto a MSC. Contains the exact location of all mobile subscribers cur-rently present in the service area of the MSC. This information is usedto route the calls to the right base station. The entry is deleted whenthe user leaves the service area.

VMS - Voicemails system records and stores voicemails

B Appendix A Server setupsWe used two servers.

B.1 mtgSun Microsystems sun4u Netra t1 1 UltraSPARC-IIi 440MHz cpu 512 MBRAM 1 x 18 GB 10000 rpm hdd - SCSI

B.2 hlrSun Fire X4150 2 Quad-Core Intel Xeon 2.63 GHz cpu 32 DDR2 SDRAM- ECC 667 MHz (PC2-5300) 4 x 146 GB 10000 rpm hdds - Serial AttachedSCSI (SAS)

C Appendix B Setting up HLR on RedHat XXC.1 configurationC.1.1 ss7.cfg

You need to change

• tcap_gt both hostname

• tcap_ssn

• tcap_incoming

• tcap_instances

48

%%HLR :tcap_gt (xjobbhlr * * *) = {4, "9146172411444"}

tcap_ssn (xjobbmtg * * *) = 8tcap_ssn (xjobbhlr * * *) = 6

% The module to handle incoming TCAP dialogues,% needs to be specified for each nodetcap_incoming (xjobbmtg * * *) = mtg_map_dialog_intcap_incoming (xjobbhlr * * *) = map_dialog_in

tcap_instances = [#tcap_instance{be_instance = 1,user_id = 40,min_dialog_id = 1,max_dialog_id = 100000}]

C.1.2 topology.cfg

change host to whatever your hostname is:

host(’latrappe’) = #{host_node_types=[#{type=sms_hlr,name=sms_hlr,use_mnesia=true,distributed_mnesia=false}],

install=#{hostname=’’latrappe’’}}

C.1.3 hlr.cfg

You need to change the mtg and vlr numbers in the hlr.cfg so that theymatch with the ss7 configuration.

mtg_number = #map_address{address = ‘‘9149172477777’’}vlr_number = #map_address{address = ‘‘9146172411333’’}

C.1.4 smsctrl_rules.cfg

You need to change the path to the smsctrl_rules.cfg

smsctrl_default_cfg (latrappe * * *) =‘‘/hlr_fe/macallan/map/priv/smsctrl_rules.cfg’’

49

C.1.5 map.cfg

You might want to change the default cryptographic function (A1/A5 func-tions). Default is:

crypto_mod = hlr_apicrypto_fun = milenage

You might need to change the two number mccs and known mccs.

two_number_mccs = [‘‘240’’, ‘‘242’’, ‘‘260’’]known_mccs = [‘‘240’’, ‘‘242’’, ‘‘260’’]

D Appendix C Setting up MTG on SunOS 5.9Since our hardware options were limited we decided to setup our MTG onInstalling Erlang on old servers can be somewhat of a hassle, hopefully thisdocumentation can ease the progress.

We use autoconf for compiling our binaries and automake complainedthat /usr/bin/local/autom4te was of the wrong version, but what this reallymeant is that Perl was to old. The fix was to change the binary path at thefirst line of automake from

#!/usr/bin/cc4/perl

to

#!/usr/bin/perl.

For automake we had to install M4 using the usual “configure -make - make install” Soft links for erl and erlc installing odbc,download from http://www.unixodbc.org/ Once again, use “config-ure - make - make install”. installing libncurses, GNU, fromhttp://www.gnu.org/software/ncurses/ Once again, use “configure - make -make install”. When all dependencies was fixed, we installed Erlang using

./configure--prefix=/opt/MA/otp/R12B-5 and then ‘‘make - make install’’.

To compile the product:

cd \$(MA\_ROOT)makecd \$(MA\_MACALLAN)\/configmakecd \$(MA\_COMMON)makecd \$(MA\_EXTERNAL)

50

\#at the following make problems might appear so be warymakecd \$(MA\_MACALLAN)make sms\_mtg

E Appendix D Notes on BuildingWhen building for linux, use SS7_API=linux_hd_1, this builds an bi-nary named oam_server, make a link to it called mgmt_server (move anymgmt_server binary out of the way). crypto_srv build might fail dueto linking of a shared binary to a static archive, link it manually to thelibcrypto.so in /usr/lib/

F Appendix E Notes on MnesiaThis appendix is a collection of notes of how Mnesia works.

F.0.6 create_table

The schema is a regular disc_only_copy table, stored in couchdb. Whenbuilding the sms_hlr the hlr_api module creates tables on all configurednodes (by default only one node). The tables have different types:

authentification_fun disc_copies

camel_profile disc_copies

lcs_profile disc_copies

ss_profile disc_copies

odb_profile disc_copies

supported_hlr_numbers disc_copies

supported_mlc_numbers disc_copies

supported_sc_adresses disc_copies

supported_scf_adresses disc_copies

supported_vlr_numbers disc_copies

all others disc_only_copies

51

The tables with disc_copies will get a copy in the <pre-fix>/<prod>/data/db/<prod>/ directory The other ones aredisc_only_copies and will have a couch-db table. When mne-sia:create_table/2 is called mnesia_schema:create_table/1 is called.The name of the table is added to the property list as name, Name.Mnesia_schema sets a write-lock (mnesia_locker keeps track of locks) onthe table and ensures the schema is writeable. After this mnesia_schemacreates a cstructto hold all the information about the table that should bewritten. The cstruct is filled in with the information from the kv-list givenas an argument to create_table (or if only the name is given, a kv-listholding only name, Name).

#cstruct{name = Name,ram_copies = Rc,disc_copies = Dc,disc_only_copies = Doc,type = Type,index = Ix2,snmp = Snmp,load_order = LoadOrder,access_mode = AccessMode,local_content = LC,record_name = RecName,attributes = Attrs,user_properties = lists:sort(UserProps),frag_properties = lists:sort(Frag),cookie = Cookie,version = Version}

If there are any fragment properties given while creating the table, thecstruct is expanded with fragment properties by the mnesia_frag module(expand_cstruct(CStruct)). Then each fragment is created as a separatetable. The sms_hlr does not use any fragmented tables, so next step takenby the mnesia_schema module is to create the actual table. First it checksthat mnesia is still up and running (I think). Then it checks if the tablealready exists, if so it aborts. Next step is to verify that the node-optionsare alright (disc_only_copies at thos nodes, ram_copies on those etc) andthen that the cstruct options are legal. When everything looks ok, mne-sia_schema make sure all nodes that should be running is running andgets a write lock on all nodes (again mnesia_locker). It then creates a listof operations containing one operation, create_table. The operation is a3-tuple, 1st element op, 2nd create_table and 3rd is the cstruct in a listformat, where each parameter in the record is stated as a kv-tuple. [op,create_table, cs2list(Cs)]. This operation is then inserted into an ets table,using a macro defined mnesia.hrl, ?ets_insert(Store, Head).

52

G Appendix F StatisticsThe statistics are collected from the MTG node. The MTG node saves thetime when the operation is sent from the MTG and

G.1 mtg_statistics:collect/0This functon collects the saved statistics by

G.2 mtg_statistics:lu_stats/0This function returns a propertylist with

num_LU The number of LU operations sent since last reset.

exec_time_seconds The combined time of execution.

lu_per_second The rate of which the LU operations was sent.

lu_instances

avg_tps_per_instance

error_rate

G.3 mtg_statistics:reset/0This function resets the statistics, returns ok.

G.4 mtg_statistics:collect_and_report/0This function collects the statistics and returns the same way as lu_stats/0.mtg_lu_generator will create a #mtg_lu_log record for each traffic case.It will store the record in an ets-table held by a mtg_lu_log gen-server. Youcan get this data via mtg_lu_log:get_ts_list/0 which will return a tupleN,TS,Time Where N is the number of log-entries, TS is a list of StartTS,StopTS and Time is a list time takens (i.e. StopTS-StartTS). You can usethis to make graphs and compare running times.

References[1] Armstrong, J. (2007) Programming Erlang. Raleigh:The Pragmatic Pro-

grammers.

[2] ETSI, Recommendation GSM 03.08 Organization of subscriber Data, re-lease 92.

53

[3] 3GPP Technical Specification 29.002, 3rd Generation PartnershipProject; Technical Specification Group Core Network and Terminals;Mobile Application Part (MAP) specification , release 7.

[4] 3GPP Technical Specification 23.008, 3rd Generation PartnershipProject; Technical Specification Group Core Network and Terminals; Or-ganization of subscriber data , release 7.

[5] 3GPP Technical Report 21.905, 3rd Generation Partnership Project;Technical Specification Group Services and System Aspects; Vocabularyfor 3GPP Specifications, release 7.

[6] 3GPP TS 23.040 3rd Generation Partnership Project; Technical Specifi-cation Group Core Network and Terminals; Technical realization of theShort Message Service (SMS), release 7.

[7] 3GPP Technical Specification 3rd Generation Partnership Project; Tech-nical Specification Group Services and System Aspects; 3G Security;Specification of the MILENAGE Algorithm Set: An example algorithmset for the 3GPP authentication and key generation functions f1, f1*, f2,f3, f4, f5 and f5*; Document 2: Algorithm Specification, release 7.

[8] 3GPP Technical Specification 3rd Generation Partnership Project; Tech-nical Specification Group Core Network and Terminals; Numbering, ad-dressing and identification, release 7.

[9] Cardell, R. (2009) Evaluation and Testing of Erlang Database BackendsUppsala:Department of Information Technology, thesis report IT 09 057.

[10] Armstrong, J. (2003) Concurrency Oriented Programming in Erlang.

[11] Armstrong, J. (2007). History of Erlang, in HOPL III: Proceedings ofthe third ACM SIGPLAN conference on History of programming lan-guages, ISBN 978-1-59593-766-7.

[12] Wiger,U., Ask,G. and Boortz, K. (2002) World-class product certifica-tion using erlang, in Proceedings of the 2002 ACM SIGPLAN workshopon Erlang, ACM Press.

[13] 3GPP, Technical Specification 3rd Generation Partnership Project;Technical Specification Group Core Network and Terminals; CustomisedApplications for Mobile network Enhanced Logic (CAMEL) Phase 4;Stage 2, release 7.

[14] 3GPP, 3rd Generation Partnership Project; Technical SpecificationGroup Services and System Aspects; Customised Applications for Mo-bile network Enhanced Logic (CAMEL); Service description; Stage 1,release 7.

54

[15] Dryburgh, L. and Hewett, J. (2004). Signaling System No. 7 (SS7/C7):Protocol, Architecture, and Services. Indianapolis:Cisco Systems

[16] DeCandia, Hastorun, Jampani, Kakulapati, Lakshman, Pilchin, Siva-subramanian, Vosshall and Vogels Dynamo: Amazon’s Highly AvailableKey-value Store, 2007.

55