IT 13 025
Examensarbete 30 hp
Mars 2013
Home Location Register (HLR)
dedicated for Short Message Service
(SMS)
Niklas Rönnblom
Johan Vikman
Institutionen för informationsteknologi
Department of Information Technology
Abstract
Home Location Register (HLR) dedicated for Short
Message Service (SMS)
Niklas Rönnblom and Johan Vikman
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
In telecommunication a Home Location Register (HLR) is used for keeping track of
subscriber data for a multitude of services, including Circuit Switched (CS) calls, Short
Message Service (SMS), and more.
To support all functions, about 50 different complicated operations must be
supported. This requires large sets of resources, both in time to implement and in
capacity when in use.
However, there are applications, for example vending machines, for which SMS is the
only service needed to be supported. The goal of this thesis is to implement an HLR
prototype, to explore the real-time characteristics of a subset of the HLR database
operations 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 and
maintain than a conventional HLR, because it only supports one function. Most
implementation was done using Erlang, a concurrent soft real-time programming
language widely used in telecoms.
Handledare: Lars Kari
Ämnesgranskare: Olle Gällmo
Examinator: Olle Eriksson
IT 13 025
Sponsor: Mobile Arts
Tryckt av: Reprocentralen ITC
Sammanfattning
Inom telekom används en Home Location Register (HLR) för att registrera
abonnent-data gällande flertalet tjänster, inklusive krestkopplade samtal,
SMS m.fl.
Eftersom många olika tjänster måste stödjas blir implementationen av
HLR-databasen omfattande och därmed väldigt dyr, exempelvis måste ca
50 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 att
utforska realtidsegenskaperna hos en delmängd av databasoperationerna för
HLR som krävs för att stödja enbart SMS. Prototypen vi utvecklat och
testat följer standarden specificerad av 3GPP. Den är även mycket enklare
att konfigurera och underhålla än en konventionell HLR. Nästan all implementation är gjord i Erlang, ett programmeringsspråk som är väl lämpat
för system där flera processer samverkar och språket är ofta använt inom
telekom.
1
2
Contents
1 Introduction
1.1 Intro . . . . . . . . . . . . . .
1.2 Research Questions . . . . . .
1.3 Methodology . . . . . . . . .
1.3.1 Research phase . . . .
1.3.2 Design phase . . . . .
1.3.3 Implementation phase
1.3.4 Validation phase . . .
1.4 3gpp and standards . . . . . .
1.5 Related Works . . . . . . . .
1.6 Thesis Outline . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
15
15
15
16
16
16
16
17
17
17
17
2 Background
2.1 Cellular Networks . . . . . . . . . . . . . .
2.2 SS7 Network . . . . . . . . . . . . . . . .
2.2.1 Network Components . . . . . . .
2.2.2 Interfaces and Protocols . . . . . .
2.3 SMS . . . . . . . . . . . . . . . . . . . . .
2.3.1 SMS delivery Example . . . . . . .
2.4 Home Location Register (HLR) . . . . . .
2.5 Erlang . . . . . . . . . . . . . . . . . . . .
2.5.1 Concurrency & Distribution . . . .
2.5.2 OTP . . . . . . . . . . . . . . . . .
2.6 Mnesia . . . . . . . . . . . . . . . . . . . .
2.7 CouchDB . . . . . . . . . . . . . . . . . .
2.7.1 Replication . . . . . . . . . . . . .
2.7.2 Multi-Version-Concurrency-Control
2.7.3 Potential drawbacks . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18
18
20
20
22
23
24
25
25
25
26
27
28
28
28
29
3 Design
3.1 Overview . . . . . . . .
3.2 Application Design . . .
3.3 Database Design . . . .
3.3.1 Subscriber data .
3.3.2 System Data . .
3.3.3 Design criterias .
3.4 Subscriber data . . . . .
3.4.1 imsi_lookup . .
3.4.2 subscriber . . . .
3.4.3 temporary_data
3.4.4 roaming_data .
3.4.5 MWI and MWD
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
29
30
30
30
30
31
31
31
33
33
34
34
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3.4.6
3.4.7
3.4.8
3.4.9
3.4.10
3.4.11
3.4.12
lcs_routing_info . . .
camel . . . . . . . . .
lcs_profile . . . . . . .
odb_profile . . . . . .
ss_registration_data .
ss_profile . . . . . . .
authentification_data
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 Implementation
4.1 supervision tree . . . . . . . . . . . . . . .
4.1.1 sms_hlr_sup . . . . . . . . . . . .
4.1.2 hlr_sup . . . . . . . . . . . . . . .
4.1.3 tcap_sup . . . . . . . . . . . . . .
4.2 Interfaces . . . . . . . . . . . . . . . . . .
4.2.1 MAP Interfaces . . . . . . . . . . .
4.2.2 TCAP Interfaces . . . . . . . . . .
4.2.3 Internal Interfaces . . . . . . . . .
4.3 Database Implementation . . . . . . . . .
4.4 CouchDB Considerations . . . . . . . . .
4.5 MAP Operations . . . . . . . . . . . . . .
4.5.1 Network initiated MAP procedures
4.5.2 OAM initiated MAP procedures .
4.5.3 OAM initiated HLR procedures . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
34
34
35
36
37
37
38
.
.
.
.
.
.
.
.
.
.
.
.
.
.
38
38
38
38
39
40
40
40
40
40
41
41
43
47
48
5 Evaluation
48
5.1 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6 Discussions and Conclusions
6.1 Problems . . . . . . . . . .
6.1.1 SS7 Stack . . . . . .
6.1.2 MTG . . . . . . . .
6.2 Lessons Learned . . . . . .
6.3 Future work . . . . . . . . .
6.4 Transaction problem . . . .
6.5 Summary . . . . . . . . . .
.
.
.
.
.
.
.
A Appendix A Acronyms
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
51
51
51
51
51
52
52
53
53
B Appendix A Server setups
56
B.1 mtg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
B.2 hlr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4
C Appendix B Setting up HLR
C.1 configuration . . . . . . . .
C.1.1 ss7.cfg . . . . . . . .
C.1.2 topology.cfg . . . . .
C.1.3 hlr.cfg . . . . . . . .
C.1.4 smsctrl_rules.cfg . .
C.1.5 map.cfg . . . . . . .
on
. .
. .
. .
. .
. .
. .
RedHat XX
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
56
56
56
57
57
57
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
59
F.0.6 create_table . . . . . . . . . . . . . . . . . . . . . . . 59
G Appendix F Statistics
G.1 mtg_statistics:collect/0 . . . . . . .
G.2 mtg_statistics:lu_stats/0 . . . . . .
G.3 mtg_statistics:reset/0 . . . . . . . .
G.4 mtg_statistics:collect_and_report/0
5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
61
61
61
61
61
6
1
Introduction
Master’s Thesis at UU
Supervisor: Lars Kari
Rewiever: Olle Gällmo
Document written in LATEX
1.1
Intro
To enable the services that are provided by mobile phone networks, a whole
set of network elements are defined by various standards (see 1.4). Some
elements are nodes responsible for charging the subscribers based on their
payment plans, other for assigning parts of the radio bandwidth to the connection between phone and radio masts, some for forwarding short messages
between subscribers and so on, the list is long (how the network is built is
briefly introduced in 2.2).
One of these nodes, the Home Location Register or HLR, is responsible
for keeping track of the subscriber data, with data such as phone number,
call forwarding information and, among other things, the physical location
of 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 and
many subscribers are using many of them, but for some applications there
is no need to use all of the services. Consider, for example, soda-vending
machines, which are situated throughout flight terminals, schools and public
spaces. Once deployed, they will not move around, so there is no need to
update the location of them, they will never make calls but some of them
are capable of sending text messages to their suppliers saying they need to
be refilled or emptied. They have no need for the capabilities of a full scale
HLR 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 be
useful. This thesis will explore how to design, how to implement and how
to test such a HLR.
1.2
Research Questions
The 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 a
conventional HLR)
The implementation is done in the programming language Erlang and
using 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 performance
degradation when the database grows in size. Mnesia consists of a frontend
with a user API and a backend using dets (an disk-based key-value store, also
a part of Erlang). Our objective is to compare and contrast runtime statistics
from running the HLR with Erlangs database Mnesia and a modified version
running another backend.
1.3
Methodology
During this project we have used several standard software engineering practices including research, design, implementation and validation. In this section we outline how each practice was done.
1.3.1
Research phase
The research phase mostly consisted of reading and understanding several 3GPP specifications, related to subscriber data and the various HLRsupported operations. Much of this work consisted of separating and distinguishing relevant parameters and operations that we need to include in
our implementation. The operations are specified as part of [3] and the
parameters for the subscriber data in [4].
1.3.2
Design phase
We designed the database tables for subscriber data. These were separated
as much as possible based on different criterias. One criteria we use is
time-aspect of the data-fields stored, i.e. whether the data is permanent
or temporary. Another aspect is security, e.g. an administrator accessing
the database should not be able to see all the data values for a particular
subscriber. And finally there is disk-access issues, if the tables become too
large we will suffer from prolonged disc reads when we try to access some
particular data-field for a subscriber. These criteria depends on the fact that
when performing a read-operation in Mnesia, you read the entire record in
the table, there is no way to read a specific data-field. More about the actual
design 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 was
to implement the design and the second included writing a new backend for
Mnesia, to see if we could eliminate Mnesias weaknesses. The Mnesia backend is implemented using dets tables, so exchanging the backend involves
changing 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 of
adding subscribers to the HLR, with the different backends. The results are
detailed sections 5 and 6
1.4
3gpp and standards
3gpp is an organization which develops standards for telecommunication
systems, much like IETF for Internet. 3gpp were created late 1998 by a
group of separate telecommunications organizations, which earlier developed
their own standards. The purpose of the organization is to develop and
maintain technical specifications and reports for telecommunication systems,
which everyone can use freely.
Because of the changing nature of telecommunication, with new standards and services created and old ones discarded, 3gpp “freezes” specifications in “releases”. Therefore one has to decide for a specific release for
which the HLR has to comply. The goal is to implement for a reasonably
new, and in all stages frozen release and there was two options, release 7 and
release 8. Release 7 was frozen in stage 3 during the year 2007 (stage 1 and
2 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 time
to 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 Works
Home Location Registers are a basic part of the GSM network and there
are many implementations in daily use today1 .
Cardell [9] compares the performance of CouchDB and Tokyo Cabinet
with Mnesia. In his thesis he exchanges the backend at a different level using
MnesiaEx. MnesiaEx is an extended version of Mnesia that enables users to
use modules (other than ets or dets) that implement a database backend.
There is extensive number of papers on Erlang, for example [10]. And
discussing testing using Erlang and telecom availability problems [12]
1.6
Thesis Outline
This thesis will add to the earlier work, with taking an alternate route to
extend the Mnesia backend by carefully customizing it.
Section 2 gives the reader an insight into the telecom network and the
Erlang programming language.
1
At 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
Background
2.1
Cellular Networks
There are many ways to setup a telecom network and throughout history
there have been many versions of networks that have been, is in and is
planned 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 network
used for communication. It is called cellular because the geographical area
of operation is divided into cells. Each cell is served by one or more base
station, which is a transceiver (both receiver and transmitter) for radio
signals. The Figure 1 shows a simplified view of the cells.
Figure 1: Cellular network
When discussing Cellular Networks, the originating and terminating part
of a procedure or transaction are often used. The originating part, or end,
is the end that initiates the procedure/transaction and the terminating side
2
http://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, the
Base Station Subsystem (BSS), the Network SubSystem (NSS) and the Operations 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 receiving
and transmitting signal to and from User Entities (UEs), e.g. mobile
phones.
NSS This is where the major work in the GSM network is done and also
where our HLR is situated. The GSM network can connect to other
types of networks, this is done here.
OSS Last we have the OSS, this is basically an interface from the operators to the different units of the GSM network. This might include
updating the HLR database, changing routing in the MSC and so on.
11
2.2
SS7 Network
The SS7 network [15] is a collection of protocols which are used in telecommunication. SS7 is short for Signaling System 7.
2.2.1
Network Components
The SS7 network consist of nodes which are responsible for different functions. Some of these nodes can be found in Figure 2, but there are also some
more nodes used in this thesis that are not shown in this figure. The nodes
are 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 database
and/or provides logic in the SS7 network.
• STP - Signal Transfer Points, responsible for the transfer of SS7 messages 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 connect to the network. These can be handsets, laptops or really any
physical device with ability to connect to the network. The MS has an
IMEI number to uniquely identify the hardware. Each subscriber has
an IMSI to uniquely identify, the IMSI is usually stored in a SIM-card
on the device. Due to security reasons the IMSI is not sent in protocol
messages if it can be avoided, instead a temporary number, TMSI, is
used. The number which is used when calling or sending SMS to the
MS is called MSISDN, this number can be used internationally. The
MSs connect to the BSS in Figure 2.
BTS and BSC These are the two major parts of the BSS. BTS stands for
Base Transceiver Stations and BSC for Base Station Centrals. The
BTS’s is the entry point to the network from the subscribers point of
view, the radio transceiver we introduced in the section about cellular
networks above. They can be placed on radio towers, on top of buildings, in buildings and even on specific floors, depending on the size of
cell. The BSC keeps track of which BTS the UE is using and which
BTS’s that is close to it, so that if the UE moves into another cell, it
can 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 very
important part of the GSM network. It is the node that connects the
NSS 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. the
public switched telephone network (PSTN), the old telephone network.
The SGSN, Serving GPRS Support Node, is the MSC of the GPRS
network. It has the same functionality as the MSC, but deals with
packet-switched data.
HLR The HLR contains the information and data of the subscriber. In the
HLR, checks are made to see if the subscriber is online/offline, if there
is some kind of barring activated, which may stop the subscriber from
using the GSM service. Another important function in the HLR is
to hold information about which VLR the subscriber is using so that
location management can be utilized.
Each HLR is responsible for a series of numbers, the MSCs knows
which HLR each subscriber is related to. The HLR knows which VLR
the subscriber is currently related to.
Because of the HLRs importance in this thesis we will explain it in
more 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 the
operator’s subscribers, the VLR holds location information for the
operator’s subscribers in the geographical areas it is responsible for.
The VLR is updated when the subscribers move around and switches
BSC. Compare this to the HLR which is updated when the subscriber
changes VLR, keeping track of the same subset of subscribers, this
subset only changed by operator control.
AuC The AuC is used by the HLR to authenticate the subscribers to prevent abuse of the network and to protect subscribers The AuC is sometimes co-located with the HLR, in the case of the SMS_HLR, the AuC
is 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 might
store text messages if the terminating subscriber is offline.
GMSC This node is responsible for routing calls in the network. The SMSGSMC is responsible for routing Short Messages in the network.
GMLC The GMLC is a node used with positioning services to figure out
where a subscriber is. Depending on subscriber data, the GMLC may
contact the HLR to get further information used in positioning or get
an 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 of
communicating, this means that all messages are to be delivered. The SS7
protocol stack can be described in four levels, note that what is called “levels” 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. These
provide reliable transfer of circuit-related signaling, in units referred to as
Signal Units (SU), between nodes in the SS7 network. The nodes are addressed through point codes (PC) and every message has both an originating
PC (OPC) and destination PC (DPC).
At the top we have the application layer. The transport layer is generally
considered to be a part of the application layer. The application layer consist
of 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 to
MTP level 3 in the SS7 stack. SCCP encapsulates TCAP and has addressing information stored used for sending messages between subsystems (also
known 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 the
node.
• 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 the
procedure is initiated, a GT is all that is given (you enter a GT when you
place a call for instances). GTs are always a telephone number but the exact
format of it can vary. The method to get the correct GT+SSN combination
based on the GT is called Global Title Translation, this translation is usually
only done on a prefix of the GT, if you place an international call you will be
routed to an node dealing with the international calls based on the country
code for instance.
14
SubSystem
HLR
VLR
MSC
AuC
SSN
6
7
8
10
Table 1: Subsystem SSNs
The SSN are static depending on the type of node, in table 1 we show
some of the SSNs used in SS7. SSNs range from 0-255. SCCP provides
both connectionless and connection-oriented messaging and use segmentation/reassembly to divide and join messages that are big.
TCAP is short for Transaction Capabilities Application Part and is used
for communication between subsystems at the top level in the SS7 stack.
TCAP manages the communications between the subsystems and can join
many messages into one logical transaction. TCAP can handle many concurrent transactions between subsystems and maintains transaction IDs to
set them apart. Since we are using SS7 over IP we use SCTP. SCTP is
short for Stream Constrol Transmission Protocol and is used as a transport
layer protocol. It was developed by the SigTran group when they found
that the existing IP-transport protocols was not able to fulfill the reliability
demands for telecoms. SCTP can be used in any IP network. MTP Level 3
User Adaption layer was developed by SigTran. In figure 3 M3UA is shown
in context, it enables SCTP.
Finally we have MAP, which stands for Mobile Application Part. MAP
enables the application nodes in the GSM network to communicate with
each other. MAP plays a vital part in this thesis. See section 4.5 for more
information on how we used MAP to build the HLR. There are other protocols in the SS7 stack such as DTAP, BSS-MAP, TUP and ISUP. They are
used for procedures such as call handling and will thus not be used here.
2.3
SMS
SMS is a service which enables sending and receiving of application layer
text messages in the network. The messages cannot be longer than 160
characters, in many countries the encoding of the characters leads to even
shorter messages (for instance messages encoded in Urdu (Pakistan) can not
be longer than 70 characters). To deal with this constraint, longer messages
can be segmented into many smaller. The service can be used by operators
who wish to inform their subscribers of temporary campaigns or offers. The
main use for the service is between subscribers who wish to communicate,
but it can also be used between different application level nodes. For SMS
to work there is a number of signaling messages sent between many different
nodes 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 about
where 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 how
an SMS is received and propagated on the terminating end. This is also
shown in figure 4.
The terminating side is more interesting since the originating subscribers
location is known and does not need to do a lookup to find out which MSC to
use. The figure shows the message in transit, it has finished the originating
part 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 identify
which HLR to contact by use of the MSISDN. The HLR, in turn, knows
which MSC the terminating subscriber currently is connected to and if it is
available for short messages. The HLR also holds information whether the
subscriber is allowed to receive messages, it might be barred due to unpaid
bills or a plan that does not allow messages. In this example, the subscriber
is available and no barring is in place. Therefore the HLR returns the MSC
address to the SMS-GMSC which forwards the message using an forwardSM
operation 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 turn
responds to the SMS-SC. The SMS-SC now knows that the message was
received and can remove the stored SM. If there were a problem along the
way the SMS-SC can try again later.
Figure 4: MT-SMS procedure, showing the last part where the sms is delivered 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 it
questions the HLR about the location of the subscriber, which replies with a
VLR-address to which the MSC forwards the message. This is illustrated in
figure 5. The figure shows a subscriber moving between two cells, generating
traffic 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 the
location information about the subscriber is updated.
2.5
Erlang
Erlang is a functional programming language that Ericsson began development of during the mid 1980s, see [11]. The purpose was to fit specific needs
that Ericsson had for their Telecom systems. The telecom industry needed
a language which could meet up to the five nines availability demand. This
means 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 have
acceptable performance.
2.5.1
Concurrency & Distribution
One of Erlangs major features is the virtual machine (VM) on top of which
the programs are run. The VM has its own process scheduler separated from
17
Figure 5: Mobile Equipment moving between cells, prompting location update procedure
the operating system (OS) scheduler. The Erlang processes are smaller than
regular OS processes and does not require as much resources as OS processes. The processes has their own memory which is not shared between
processes. If some information needs to be shared between processes, the
information is copied and sent between them using interprocess communication, making each holding its own copy of the information. Without having
any shared memory there is no need for memory locks and thus no memory
deadlocks. Interprocess communication is done by sending asynchronous
messages between the processes. These messages are collected in an inbox
that is associated with each process, the processes can choose to ignore
the messages or pick the messages that its interested in. The Erlang VM
supports transparently sending messages between different Erlang systems,
which are also called nodes. The transparency means that there should be
no difference between sending messages to processes on the same computer
and over network to some other computer, however network latency usually
impairs the performance when using external nodes. There is also different
ways to use external programs in the node, we will later use “Port Programs”, where binary messages are sent between the the port program and
the 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 that
Erlang is known for. OTP is a set of code libraries written in Erlang. Apart
from providing the programmers with programs it also defines something
called behaviors (similar to design patterns) which helps programmers to
18
build their systems in a good way. The behaviors are frameworks which
are used to develop concurrent and fault-tolerant systems. One important
concept is the supervisor behavior. The supervisor is a process which job is
to monitor other processes and restart them if necessary. Many supervisor
can be linked together in a supervision tree, as in figure 6, the root is often
referred to as the top supervisor.
Figure 6:
A typical supervision tree,
the boxes represent
supervisors
and
the
circles
workers,
source
http://www.erlang.org/doc/design_principles/des_princ.html.
2.6
Mnesia
Mnesia is Erlangs built-in relational database management system. It is
tightly integrated with Erlang, both written in Erlang and shipped with
Erlang. It was developed alongside Erlang to be a database fit for telecom,
sharing many of its features, such as fault-tolerance and reliability. Mnesia
support transactions and complex queries as well as fast key-value lookups.
Since its implemented using Erlang there is no data mismatch between Mnesia and its programming language, which makes it easier for programmers
in the sense that they do not have to convert datatypes between the two.
Schemas in Mnesia can be updated whilst running the system, which helps
fulfill the five nines availability demands. The schemas can even be redistributed between nodes while writing to the tables.
19
2.7
CouchDB
CouchDB3 is a non-relational open source database which was developed by
Damien Katz, now maintained by Apache Software Foundation. CouchDB
started out written in C++, but was later rewritten in Erlang when the
nice features of Erlang was discovered. CouchDB has a builtin web server
which is used to communicate with the database. It stores its records using
JSON4 , uses Javascript to present data and a HTTP Rest to interface the
database. 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 from
multiple replicas on different nodes. This means that you can take copies of
the db, store it on different machines, do some work on each machine and
still be able to synchronize it later. With more and more work been done
being mobile (on phones, netbooks, laptops) this is a feature which makes
CouchDB very interesting.
2.7.2
Multi-Version-Concurrency-Control
CouchDB calls its stored entities documents. CouchDB keeps by default
1000 revisions of a document before it starts to remove old revisions, you
can either manually remove revisions or configure the database keep a lower
number of revision. Keeping the number of document revision on the default
setting, means that each revision of a document is stored, when you insert
new data the old data is kept alongside. To be able to access the correct
data, CouchDB uses unique document revision IDs. These IDs are very
important as they are also used for handling concurrent changes to the
database. Because of this system with multiple revisions, there is no need
for a locking system. The locking system is redundant since because there
is no need to edit data, instead of doing an edit a new version is instead
created. If two writes are done simultaneously, both writes will have unique
IDs and the latest ID set as the current.
3
4
http://couchdb.apache.org/
http://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 the
first query, which means that the first query will take longer time than later
queries. If the documents are updated the views will not be refreshed until
the next query which means that potentially each query might be preceded
with a build of a view. CouchDB handles documents in JSON format, it is
not very good with binaries, however you can store binaries as attachments
(which you can have any number of). CouchDBs RESTful API means that
each query needs to be packed in a HTTP request sent to the CouchDB web
server, even if the request is sent to a local webserver it adds overhead to
each query, why we expect the CouchDB approach to be slower. CouchDB
saves versions of all objects, meaning that if an object is stored and later
updated, the original version is still kept, but the updated object is the
current 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 called
compaction, which unfortunately needs to be done manually in our version.
Later versions of CouchDB have automatic compaction. The problem might
be helped by lowering the number of kept revisions from the default of 1000
versions to 1 version.
3
Design
3.1
Overview
The design phase was partly intermingled with the implementation phase,
an initial design was made and then later revised during the implementation
as the understanding of the problems increased. The Application design was
pretty straightforward, the major part of the HLR is the database handling,
thus the design of the tables is more important to get right. The requirements we had was very broad, so the design phase involved examining these
requirements:
• 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 intent
to let it evolve during the implementation phase. GPRS was left out, but
if time permitted would have been added, to begin with the GPRS data
received was just ignored and not sent out.
21
3.2
Application Design
We set out to implement the application for Linux, using a proprietary
SS7 stack from Tieto Enator and then the HLR application on top of this.
The SS7 stack communicates with the HLR application via an Erlang port
program.
3.3
Database Design
Since the HLR/AuC shall indicate that the SMS services is available to the
subscribed user, a database storing subscriber data must be mainained. The
data includes subscriber specific data and subscriber profile data common
for many subscribers.
3.3.1
Subscriber data
The term subscriber data is used to designate all information associated
with a subscription which is required for service provisions, identification,
authentication, routing, sms handling, and operation and maintenance purposes.
Some subscriber data are referred to as permanent subscriber data, i.e.
they can only be changed by administration means. Data that is shared
between subscribers is called profile data, this can only be changed by administrators.
There is also temporary subscriber data, which may change as a result
of normal operation of the system, e.g. location updates or other changes
by the subscriber.
3.3.2
System Data
Apart from subscriber data, there are also tables holding system data, including information about which servers that are allowed to connect to the
system. 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 subscriber and profile data, as well as system data. The tables were separated
and structured based on different criterias. One criteria was the temporal
nature of the data, whether the data is changed by an administrator or updated as a result of a common operation. Another aspect is sequrity, for
instance all administrators accessing the database should not be able to see
all the data for a particular subscriber. Finally there is disk-access issues; if
the records in the tables becomes to large we will suffer from IO-overheads
when we try to access a particular data-field for a subscriber. This is due
to the fact that read/write-operations in Mnesia can only access an entire
record in a table, there is no way to do individual field updates or lookups.
An important task before beginning implementing, was to pick out a
subset of the subscriber data needed to support SMS services on top of
the basic required services, including some other non-basic services, such as
CAMEL support for SMS [13], Operator Determined Barring (ODB) and
Location Services (LCS). Some of the data are mandatory to all services,
while other are operation dependent. Others end up in a gray zone where
the support could be useful, yet functionally it will work without it. A
rather large such restriction we did was to not support any GPRS related
functionality, such as SMS over SGSN. Supporting GPRS would require a
larger implementation and is not strictly needed for the scope of this thesis.
3.4
Subscriber data
Subscriber data is the collection of data that specifies the subscription of
a subscriber, this includes all information about subscribed services, identification, barring information and authentication data. The specification
GSM 03.08 [2] specifies what subscriber data an HLR should keep. For an
HLR which only support SMS, we could choose a subset of the parameters
listed. 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 the
SMS_HLR does not support.
3.4.1
imsi_lookup
The IMSI is the key in many of the tables, but in some MAP-operation
there is no IMSI provided only MSISDN. The imsi_lookup, Table 3, is used
to lookup the imsi of a subscriber when only the MSISDN is given in a
MAP-operation.
23
Parameter
IMSI
MSISDN
LMSI
Mobile Station Category
Authentication Key
RAND/SRES and Kc
MSRN
VLR Number
MSC Number
Roaming Restriction
Provision of Bearer Service
Provision of Teleservice
BC Allocation
Subscription Restriction
Provision of suppl. services
CUG interlock code
CUG index
Per call basis subscription
Notification to calling party
User-to-user signalling service ind.
CUG facility
Preferential CUG facility
Barring incoming calls within CUG
Barring outgoing calls within CUG
Maximum number of conferees
Control of barring services
Forwarded-to number
Registration status
No reply condition timer
Call barring password
Activation Status
Check Suppl. Services flag
Access priority class
Messages Waiting Data
Type
P
P
T
P
P
T
T
T
T
T
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
T
T
T
T
T
T
P
T
Selected
YES
YES
YES
NO
YES
YES
YES
YES
YES
YES
YES
YES
NO
YES
YES
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
YES
YES
YES
YES
Table 2: This table shows the parameters defined in [2], the ones marked
“YES” are used by the SMS_HLR
24
msisdn
imsi
E.164 address
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 information is stored. To keep the size of the subscriber table down, the hlr keeps
profiles for common ss, odb, lcs and camel settings. This means that when
a service is applied, modified or removed (either via an administrator or
subscriber action), a different profile is selected. During runtime this means
that the table only holds a reference to another table, instead of holding
the complete description of the setting, this saves size during lookups but
creates a dependancy to another table.
imsi
msisdn
teleserviceList
accessRestriction_Data
subscriber_status
network_access_mode
lcs_profile_id
odb_profile_id
ss_profile_id
camel_profile_id
imsi
E.164 ISDN address
a list 5
list, valid elements are’utranNotAllowed’ and ’geranNotAllowed’
true or false, defaults to true
’only_MSC’
integer referring to an entry in the lcs_profile table
integer referring to an entry in the odb_profile table
integer referring to an entry in the ss_profile_id table
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 for
all subscribers, later when the HLR gets an update location request for the
marked subscriber, the HLR sends a check forward indication to the VLR
that sent the update location request. This data is stored in the table called
“temporary_data” and is shown in Table 5
imsi
check_ss_indication
ms_purged_for_non_gprs
imsi
true or false
true or false
Table 5: Temporary data
25
3.4.4
roaming_data
The roaming_data Table 6 handles information regarded to roaming. It
keeps the address of the VLR and MSC. It also keeps track of the LMSI if
one has been assigned.
imsi
vlr
msc
lmsi
imsi
E.164 ISDN address
E.164 ISDN address
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 the
Message Waiting Indicator or MWI for short, Table 7. Here you can find
information about if a subscriber has a message waiting and the reason to
why the subscriber has been unable to receive the message
The last element in the MWI is the MWD. The MWD keeps a list of
service centers that has tried to reach the subscriber, it also keeps track of
which ISDN-address, that they should send an alert when the subscriber
attaches/memory is available. This MSISDN is called the MSISDN-Alert.
imsi
mnrf
mnrr_msc
mcef
mwd
imsi
true or false, defaults to false
integer, reason for absence, only two options are valid, 0 and 1
true or false, defaults to false
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 location
based services. For LCS to work, the HLR must specify MSC- and GMLCaddress, as well as location capabilities for the UE (among other things if it
has support for assisted GPS positioning) and also if LCS over CS networks
is supported by the phone (cs_LCS_NotSupportedByUE).
3.4.7
camel
Camel is short for Customised Applications for Mobile network Enhanced
Logic and is specified in [14], in short it enables the operators to enable or
26
6
imsi
network_node_number
supported_LCS_capability
v_GMLC_address
cs_LCS_NotSupportedByUE
imsi
E.164 ISDN Addresss of the MSC
integer, 0 to 5
IP address of V-GMLC for MSC
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 where
in the call-flow a camel service can be supported, by the VLR (o-csi,dcsi etc). There is also information about what phase of CAMEL that the
VLR supports (there is a number of versions of CAMEL, called phases, in
which different CAMEL services are defined, for SMS phases 3 and 4 are
needed). Because only SMS is supported, there is also place to store a
CAMEL capacity for mo-sms and mt-sms, negotiated between the network
and the handset. This table is referenced by the subscriber table.
imsi
vlr_offeredCamel4CSIs
vlr_supportedCamelPhases
mo_sms_csi_VLR_NegotiatedCamelCapHandling
mt_sms_csi_VLR_NegotiatedCamelCapHandling
imsi
a list with allowed values :
’o-csi’, ’d-csi’, ’vt-csi’, ’t-csi’,
’mt-sms-csi’ ’mg-csi’and ’psienhancements’
[N,...] 1 =< N =< 4
undefined or 3
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 based
services, this table is referenced by the subscriber table. Each profile holds
a list of GMLC numbers from which a location request for an specific ME is
allowed (this procedure is shortened MTLR) , it also holds the IP-address
of the GMLC in the subscribers home network.
id
gmlc_numbers
h_GMLC_address
integer
list of E.164 Addresses
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 are
defined. The table is referenced by the subscriber table. The table information is changed by administrators.
id
odb_general_data
odb_plmn_specific_data
integer
see below
list, valid entries : ’plmnSpecificBarringType1’,’plmnSpecificBarringType2’,’plmnSpecificBarringType3’,’plmnSpecificBarringType4’
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
• interzonalOGCallsAndInternationalOGCallsNotToHPLMNCountryBarred
• 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 supplementary services (SS) defined for the subscriber. The table is referenced by the
subscriber table. There is one table per subscriber and it contains a password, for changing the services, the number of failed attempts of supplying
the password and whether the subscriber is blocked from changing the SS.
imsi
registration_passwd
wrong_passwd_attempts_count
blocked
imsi
DES encypted binary
N = 0..2, where N is the number of times there has been
incorrect passwords, N > 2
means 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, this
table is referenced by the subscriber table. The ss_subscription_option
part 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 use
a 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 which
shows which basic service it is applicable for and whether it is enabled or
not.
id
ss_subscription_options
call_barring_lst
integer
defining the SS
defines the call barring for the SS
Table 13: The ss_profile table
29
provisioning_state
registration_state
activation_state
hlr_induction_state
provisioned | not_provisioned
registered | erased | not_applicable
not_active | active_and_operative | active_and_quiescent
induced | not_induced
Table 14: Supplementary Status table
id
mo_sms_CSI
mt_sms_CSI
integer
mo_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 AuC
function to authenticate users. Apart from a shared secret, the auhtentification_data also holds information about the latest used challenge. The
challenge can be reused a configurable amount of times, why this information needs to be stored.
imsi
ki
challenges
imsi
128 bit binary key
list of challenge information
Table 16: Authentication data table
4
Implementation
4.1
4.1.1
supervision tree
sms_hlr_sup
The main supervisor of the SMS HLR starts one worker and two supervisor
processes. The worker is named sms_hlr_helper and holds configuration
parameters 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 timeouts for location updates and mwd. When a location update is received a
timer 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 runs
out, it removes the information about notification to service centers.
30
Figure 7: The process tree, source: the picture was generated by the Erlang
appmon application.
4.1.3
tcap_sup
Tcap_sup starts a tcap instance supervisor which makes sure there is a
connection to the SS7 stack through an external TCAP server. When the
TCAP server gets a MAP request it starts a MAP handler for this, the
MAP handler is a finite state machine (gen_fsm) named map_dialog. The
map_dialog checks the syntax of the MAP request and runs it through a
filter. The filter checks if the sender is allowed to send any or specific MAP
requests to the HLR or not. One can also limit the allowed MSISDN number
series. Whether the sender, request-type, etc is allowed or not is configurable
in runtime.
31
4.2
4.2.1
Interfaces
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 client
and send requests. MAP is defined in the 3GPP standards using ASN.1
notation with basic encoding rules, we used the Erlang OTP ASN1 support
to create modules to encode and decode MAP.
4.2.2
TCAP Interfaces
The tcap connection is taken care by a configurable set of supervised
gen_servers. The gen_servers run an external Erlang process in the form
of a C-executable (named tcap_server) which is used to connect to the SS7stack.
There are two parts to the tcap interface, tcap_manager which keeps
track of registered tcap handlers. The tcap handlers are supervised by
tcap_sup, which can restart the handlers if they crash. The number and
parameters 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. When
tcap has a new incoming map-request an internal seizure request is generated
and sent to the HLR_FSM. If there is an available hlr_fsm process, the
HLR_FSM replies with a response including the pid for the sms_hlr process.
This enables the TCAP process to forward the MAP request as described
in 4.1.3.
4.3
Database Implementation
To interface with the database there are two modules, hlr_api and
hlr_oam_api which takes care of reading and writing to the database. Since
the db-change made is transparent the modules are the same regardless
whether using Mnesia or CouchDB.
When using CouchDB instead of Mnesia the dets calls to are changed to
calls to ecouch. To enable this, dets starts a module called db_server, which
in 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 of
db_server will make it easier to change to other databases in future work.
4.4
CouchDB Considerations
Because there is no automatic compaction of the CouchDB database and
the CouchDB keeps 1000 revisions the database would grow for each update eventually running out of disk space. By manually compacting of the
databases, the problem could be removed temporary (shrinking a 600 MB
table to a 4MB table), but this is not usable in a production system. So
instead of keeping all revisions, we chose to configure the database to keep
only one revision for each object. Each time a new transaction is started an
ets-table for the transaction is created, unfortunately the transaction took
so much time that the maximum number of ets-tables were created and
new transactions were discarded. To fix this problem, we changed to using
”dirty” mnesia operations, without transactions. These operations are normally faster than operations with transactions, but scarifies the atomicity
and isolation that comes with using transactions.
4.5
MAP Operations
An HLR taking care of SMS has to take care of a lot of different scenarios
involving different MAP operations and procedures. MAP operations are
divided into five different categories:
1. Mobility Management, keeping track of where the subscriber is.
2. Operation and Maintenance, operator operations to maintain subscribers and SS7 nodes. Also tracing.
3. Call Handling, taking care of calls.
4. Supplementary Services, operations for subscribing and maintaining
supplementary 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 Handling
Since the HLR does not support calls, no operations from this group
were implemented.
4. Supplementary Services
Supplementary services is a standardized set of extensions used when
calling, i.e. caller id, call forwarding. These extensions are used with
calls, 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]. The
HLR can optionally log UL Timestamp, IMSI and IMEI SV for MSC. For
the first UL received for the subscriber from a VLR and no Skip Subscriber
Data Update for MSC is indicated, the HLR:
1. Sends Insert Subscriber Data (ISD) without including Network access
mode 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 Cancellation 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 the
provided IMSI, and initiates the sending of Alert SC procedure for the IMSI
as 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]. If
the received PMS includes the same VLR Number as stored for the subscriber 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 if
the subscriber is known and if the subscriber is known:
1 Sends Insert Subscriber Data (ISD) including Network access mode to
the VLR
2 Receives the ISD Response
The HLR then:
1. Sends RD Response to the VLR including MS Not Reachable Flag if
the 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 Send
Authentication Info (SAI), the AUC only accepts VLR as Requesting Node
Type. The AUC also ignores the Immediate Response Preferred Indicator.
The AUC analyzes the most significant digits in the IMSI to select the
served HPLMN. The authentication triplets/quintuplets are generated on
per served HPLMN in the AUC using operator defined authentication and
key generating algorithms (A3/A8) and functions (f0, f1, f1*, f2, f3, f4, f5 and
f5*) per served HPLMN. We chose to use the specified functions in the 3gpp
specifications (milenage), if the operator wants to change he needs to specify
them in erlang modules and configure the system to use this module. The
AUC uses Requesting PLMN ID, if received, to select the served VPLMN.
The AUC returns an empty response if authentication triplets/quintuplets
are not available.
MAP Authentication Failure Report (AFR) procedure
When the AUC receives Authentication Failure Report (AFR), the AUC
can optionally log Timestamp and all AFR received parameters (Calling
GT, 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 routing
information for SMSs is handled correctly, a big operation.
When the HLR receives Send Routing Info for SM (SRISM), the HLR
ignores any included GPRS parameters. The HLR checks the provided requesting party and can return an error message containing “Facility Not
Supported” if the requesting party is not allowed to request routing information. If the subscriber is marked as available, i.e. does have enough
memory 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-RPPRI, and the subscriber’s real IMSI, LMSI and MSC Number is stored as
Roaming Data, the HLR returns a positive response including this Roaming
Data.
In such case an MSISDNAlert is stored for the MSISDN, the response
is also preceded by the HLR sending an InformSC including the MSISDNAlert. If an MWD is stored for the MWD subscriber, the HLR then restarts
the MWD timer for the MWD subscriber.
If the MWD, for either the MSISDN or MSISDNAlert, indicates an absent subscriber or a subscriber out of memory, and no smRPPRI was included in the request, or there is no roaming data for the subscriber, the
HLR includes the given SCaddress in the MWD List of SCaddresses, if not
already included. The purpose is to be able to contact the SC later when
the subscriber is reachable again.
If there were no MWD data for the MWD subscriber, the HLR creates
the MWD storing Absent Subscriber and MS Not Reachable via MSC Reason as applicable. The HLR then restarts the MWD timer for the MWD
subscriber. The HLR then sends an InformSC including Absent Subscriber,
MS Memory Capacity Exceeded and MS Not Reachable via MSC Reason
as stored, and MSISDNAlert if stored. The HLR then returns a negative
response indicating Absent Subscriber.
MAP Report SM Delivery Status (RSMDS) procedure
When receiving the request, the HLR runs the filter function and checks the
received SCAddress, and returns Facility Not Supported if the SC-Address
is not ok. If unsuccessful SMDelivery Outcome is indicated, the HLR updates the MWD for the MSISDNAlert, if stored for the MSISDN or the
MSISDN if not stored, ith Absent Subscriber (MNRF) or MS Memory Capacity Exceeded (MCEF) as provided, MS Not Reachable via MSC Reason
(MNRRMSC) as provided, and includes the given SCaddress in the MWD
List of SCaddresses, if not already included. The HLR then restarts the
MWD timer for the MWD subscriber. If an MSISDNAlert is stored for the
MSISDN, the HLR also includes the MSISDNAlert as Stored MSISDN in the
response. If successful SMDelivery Outcome is indicated, the HLR removes
Absent Subscriber (MNRF), MS Memory Capacity Exceeded (MCEF) and
MS Not Reachable via MSC Reason (MNRRMSC) in the MWD for the
MSISDNAlert, if stored for the MSISDN or the MSISDN if not stored, and
initiates the sending of Alert SC procedure for the MWD subscriber, as
described in section 4.5.1.
37
MAP Ready for SM (RSM) procedure
When the HLR receives Ready for SM (RSM), the HLR ignores all GPRSrelated parameters (Alert Reason Indicator) and IMSrelated parameters
(Additional Alert Reason Indicator).The HLR updates the MWD for the
IMSI with Absent Subscriber (MNRF) or MS Memory Capacity Exceeded
(MCEF) as provided by Alert Reason, and removes MS Not Reachable
via MSC Reason (MNRRMSC) if the provided Alert Reason indicates MS
Present.The HLR then initiates the sending of Alert SC procedure for the
MWD 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 MS
Memory Capacity Exceeded (MCEF), the HLR sends Alert SC to all MWD
stored SCaddresses for the MWD subscriber. In such case, at successful
Alert SC response, the SCaddress instance is removed from the MWD data
for the MWD subscriber. If a successful Alert SC response is then received
for all stored SCaddresses, the HLR removes the MWD data for the MWD
subscriber 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 stored
for the MSISDN received in the request, if it finds an IMSI it includes it in
the 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 screen
the received gsmSCFAddress and return ATI Not Allowed if not configured
to 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 HLR
can screen the received MLC Number and return Unauthorized requesting
network if not allowed. If the HLR stored subscriber data indicates CS LCS
Not 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, HGMLC 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 including
LMSI, if stored, and Cancellation Type indicating Subscription Withdrawal
to 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 subscriber
The HLR can send Insert Subscriber Data (ISD) to an attached subscriber
without including Network access mode when:
1. The operator has applied, changed or removed Operator Determined
Barring.
2. The operator has changed the subscription of one or more supplementary services, basic services or data of a subscriber (however not at
withdrawal of a Basic or Supplementary service, when the DSD procedure below is used instead).
The HLR then receives ISD Response and acknowledges this to the operator.
OAM Delete Subscriber Data (DSD) procedure at attached subscriber
The HLR can send Delete Subscriber Data (DSD) to an attached subscriber
at:
1. Operator withdrawal of one or more supplementary services or basic
services (however not in case of erasure or deactivation of supplementary services, when an Insert Subscriber Data is initiated instead).
The HLR then receives DSD Response and acknowledges this to the operator.
39
OAM Reset (RT) procedure
After an HLR restart, the HLR can send a Reset to each of its configured
lists of VLR Addresses to indicate that an HLR failure has occurred. One
Reset is sent for each combination of configured VLR Address and configured
VLR Number. Each Reset includes the HLR ID List as configured for the
included VLR Number. After an HLR restart, the HLR sets Send Forward
Check 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 the
Roaming 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 Data
for the MSISDN.
5
5.1
Evaluation
Testing
To test two virtual machines were used, one with the HLR installed and the
other with a traffic generator, MTG, installed. Both nodes used a proprietary SS7 stack configured for SS7 over IP. Both database backends were
tested separately, exchanging the backend in the HLR node between the
tests. The same SS7 and HLR configuration were used for both backend
variants. The MTG is configured to have dual roles, acting as both VLR
and MSC during the testing. The MTG replies with a hard-coded response
when the HLR queries it. For the performance test, we decided to go for lots
of location updates, simulating many users changing positions. The MTG
generated lots of Update Location procedures (ULs) which it sent to the
SMS-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 the
MTG 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 the
database in order to retrieve enough subscriber data to make a MAP-InsertSubscriber-Data (ISD). The MTG receives the ISD and then replies with a
hardcoded ISD-response. Upon receiving the ISD-response, the HLR ends
the UL procedure with sending a MAP-Update-Location response to the
MTG. 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 data
is then used in creating statistics.
Figure 8: This figure shows the Update Location test. Source: generated at
http://www.websequencediagrams.com
This round, described in Figure 8 from traffic generator to HLR and
back to traffic generator, counts as one successful traffic case. If there was
an error for one “program”, an error counter is incremented. For each test
both start- and end time, as well as the result from the HLR is stored.
5.2
Results
In the first test we added 5000 subscribers and timed the time it took to
add 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 seconds) 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.97
seconds). So Mnesia is faster by a factor of 2. Even when we use
couchdbs 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 location updates from the sms_mtg node to the sms_hlr node. We configured
the sms_mtg to send 500 location updates, the first test with the ordinary
mnesia database could not be compared to the tests with the couchdb backend since the erlang transactions management broke down. The database
transactions started to take too long time so that the HLR started to drop
the application transactions. To solve this we decided to skip the mnesia
transaction manager and use dirty operations like discussed earlier in section
4.4. As explained earlier we could not get any results from these tests.
42
6
Discussions and Conclusions
The results we got from test one shows that our implementation with the
CouchDB backend performs very bad against Mnesia. Also we could not
provoke any fatal Mnesia failures, instead it was CouchDB that over time
had If the results from the CouchDB tests had been close the results of
Mnesia, there might have been more value in actually continuing testing, but
when the initial tests showed this bad performance in comparison, something
drastic would have to be done to improve the results. When we removed the
transaction handling from the CouchDB we probably sped up the process a
bit. An interesting test is to see if the transaction-less version of CouchDB
could be faster. We did not however have time to test this. We did fulfill
our goal of making a working HLR and this HLR has been used in other
projects since.
6.1
6.1.1
Problems
SS7 Stack
In the beginning of the project we used a beta version of a SS7 stack, which
was hard to configure and prone to errors. Troubleshooting errors and trying
different configurations took a lot of valuable time we could have spent
testing and implementing. In the end of the project we got the option to
change stack to an official release which we decided to do. The new stack
was easier to configure, troubleshoot and use, but featured a little different
interface which took a little time to get right. All in all the decision to
change stack was beneficial since it proved a lot more stable when running
tests.
6.1.2
MTG
Mobile Arts provided us with a prototype for a traffic generator. The traffic
generator was extended with support for all operations that were needed
in our tests. For the load-tests that we wrote there is an open-source load
tester which is called Tsung, earlier known as Tsunami. Tsung is primarily
used 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 Learned
This section deals with lessons learned from running the prototype(s). We
should have used a final version of the SS7 stack from the start, the purpose
of the thesis was not to evaluate SS7 stacks but ended up partly doing so.
43
6.3
Future work
There are more databases to try out, in our preliminary work we looked at
PostGRESQL7 which is a fast and widely used database, we hoped to be
able to implement a backend for this too, but we ran out of time and decided
to leave this for future work instead. Apart from CouchDB there have been
many advances among the non-relational databases, the latest years more
databases have emerged. Amazon released a paper [16] on Dynamo, which
is a technology Amazon use to get a scalable, flexible key-value storage with
high-availability features. Apart from Dynamo, there is also Cassandra8 ,
MongoDB9 and Riak10 (which was inspired by the paper on Dynamo). There
are more MAP-operations to implement, this means more work on both
the MTG and the HLR. The MAP-protocol has evolved during some time
and there are three different versions. When a MAP-dialogue is started
a common version should be decided on through protocol. However, we
chose to only support the newest version when possible, otherwise we choose
the highest possible version (almost always version 3). The team behind
CouchDB will release an Erlang-API in the future which would bypass the
current slow HTTP-interface 11 . A version of the sms_hlr was also used
by the project CS course on Uppsala University in the fall semester 2010,
the students implemented an SMS capable MSC and implemented a small
mobile network capable of SMS. There are plans to extend that version of
the sms_hlr so that it support calls.
6.4
Transaction problem
During the development of the couchdb version of the sms_hlr a problem
appeared with the Mnesia transaction handling. Each time a new transaction is made using mnesia, an ets table named mnesia_trans_store is
created, this is used to store information about the transaction. When the
transaction ends, the ets table is removed, this should be a very quick operation. But when using CouchDB for a backend, the transactions take so
much more time to complete that the number of created ets-tables hit the
maximum limit for number of current ets-tables in the system. When the
limit is hit, new ets-tables cannot be created so the transactions started to
fail. We could either speed up the transactions or remove transactions alltogether. We decided to remove the transactions and use dirty-operations
instead, this was the quickest way to move forward.
7
http://www.postgresql.org/
http://cassandra.apache.org/
9
http://www.mongodb.org/
10
http://basho.com/riak/
11
http://wiki.apache.org/couchdb/Frequently_asked_questions#i_can_has_no_http
2009–11–22
8
44
6.5
Summary
Since CouchDB keeps revisions of everything and needs to compacted by
hand and the data in SS7 is often changed and old data is usually of no
interest, CouchDB makes a poor match for telecom. We did not experience
the well-known dets-bug while we tested. So we do not know if the Couchflavored Mnesia suffers from the same problem or if it is unrelated. Looking
at 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, namely
by the students at Uppsala University.
2. CouchDB is a bad match for telecom.
A
Appendix A Acronyms
AUC Authentication Centre, serves to authenticate each SIM card that attempts to connect to the GSM core network. This step has to be
completed before the HLR is contacted. An encryption key is also
generated to encrypt all wireless communication. Acceptable Cell cell
that the UE may camp on to make emergency calls. It must satisfy
certain conditions.
AuC - Authentification Centre.
BSC - Base Station Controller
BSS - Base Station Subsystem
BTS - Base Transceiver Station
EIR - Equipment Identity Register, contains information about all valid
mobile 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 go
through 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 one
channel to another. For example when a phone moves from one cell
to another and a call is transferred between cells to avoid termination
of 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. International network nodes use a 14-bit PC, except for North America
and China which use an incompatible 24-bit PC, and Japan which
uses a 16-bit PC. International and National PCs are not compatible
and are only valid within the different networks. 3-level hierarchy,
NETWORK:CLUSTER:MEMBER NUMBER. Each level has a 8-bit
number, 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 GPRS
network. Performs the same functions as the MSC for voice traffic.
SGSN and MSC are often co-located. The SGSN is connected to
the BSC. The SGSN is the service AP to the GPRS network for the
mobile user .Serving GPRS Support Node, responsible for delivering
data packtes from and to the mobile stations within its geographical
service 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 text
messages.
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. Can
originate and terminate messages, but not transfer
STP - Signal Transfer Points, resposible for the transfer of SS7 messages
b/w other SS7 nodes, much like a router in the IP network. STP:s
only route/transfer messages.
TMSI - Temporary Mobile Subscriber Identity, used for giving MEs temporary ids, used for roaming (when VLRs are used). Used as a substitue
for the IMSI to limit the number of times the IMSI is broadcasted
over the open air interface. These are issued during the location update procedure.
TMSI - Temporary Mobile Subscriber Identity, used for giving MEs temporary ids, used for roaming (when VLRs are used). Used as a substitue
for the IMSI to limit the number of times the IMSI is broadcasted
over the open air interface. These are issued during the location update 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 associated
to a MSC. Contains the exact location of all mobile subscribers currently present in the service area of the MSC. This information is used
to route the calls to the right base station. The entry is deleted when
the user leaves the service area.
VMS - Voicemails system records and stores voicemails
B
Appendix A Server setups
We used two servers.
B.1
mtg
Sun Microsystems sun4u Netra t1 1 UltraSPARC-IIi 440MHz cpu 512 MB
RAM 1 x 18 GB 10000 rpm hdd - SCSI
B.2
hlr
Sun 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 Attached
SCSI (SAS)
C
Appendix B Setting up HLR on RedHat XX
C.1
C.1.1
configuration
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 * * *) = 8
tcap_ssn (xjobbhlr * * *) = 6
% The module to handle incoming TCAP dialogues,
% needs to be specified for each node
tcap_incoming (xjobbmtg * * *) = mtg_map_dialog_in
tcap_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 they
match 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 functions). Default is:
crypto_mod = hlr_api
crypto_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.9
Since our hardware options were limited we decided to setup our MTG on
Installing Erlang on old servers can be somewhat of a hassle, hopefully this
documentation can ease the progress.
We use autoconf for compiling our binaries and automake complained
that /usr/bin/local/autom4te was of the wrong version, but what this really
meant is that Perl was to old. The fix was to change the binary path at the
first 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 “configure - make - make install”.
installing libncurses, GNU, from
http://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)
make
cd \$(MA\_MACALLAN)\/config
make
cd \$(MA\_COMMON)
make
cd \$(MA\_EXTERNAL)
50
\#at the following make problems might appear so be wary
make
cd \$(MA\_MACALLAN)
make sms\_mtg
E
Appendix D Notes on Building
When building for linux, use SS7_API=linux_hd_1, this builds an binary named oam_server, make a link to it called mgmt_server (move any
mgmt_server binary out of the way). crypto_srv build might fail due
to linking of a shared binary to a static archive, link it manually to the
libcrypto.so in /usr/lib/
F
Appendix E Notes on Mnesia
This 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. When
building the sms_hlr the hlr_api module creates tables on all configured
nodes (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 <prefix>/<prod>/data/db/<prod>/ directory The other ones are
disc_only_copies and will have a couch-db table.
When mnesia: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) on
the table and ensures the schema is writeable. After this mnesia_schema
creates a c̈structẗo hold all the information about the table that should be
written. The cstruct is filled in with the information from the kv-list given
as an argument to create_table (or if only the name is given, a kv-list
holding 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, the
cstruct is expanded with fragment properties by the mnesia_frag module
(expand_cstruct(CStruct)). Then each fragment is created as a separate
table. The sms_hlr does not use any fragmented tables, so next step taken
by the mnesia_schema module is to create the actual table. First it checks
that mnesia is still up and running (I think). Then it checks if the table
already exists, if so it aborts. Next step is to verify that the node-options
are alright (disc_only_copies at thos nodes, ram_copies on those etc) and
then that the cstruct options are legal. When everything looks ok, mnesia_schema make sure all nodes that should be running is running and
gets a write lock on all nodes (again mnesia_locker). It then creates a list
of operations containing one operation, create_table. The operation is a
3-tuple, 1st element op, 2nd create_table and 3rd is the cstruct in a list
format, 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 Statistics
The statistics are collected from the MTG node. The MTG node saves the
time when the operation is sent from the MTG and
G.1
mtg_statistics:collect/0
This functon collects the saved statistics by
G.2
mtg_statistics:lu_stats/0
This 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/0
This function resets the statistics, returns ok.
G.4
mtg_statistics:collect_and_report/0
This 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. You
can get this data via mtg_lu_log:get_ts_list/0 which will return a tuple
N,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 use
this to make graphs and compare running times.
References
[1] Armstrong, J. (2007) Programming Erlang. Raleigh:The Pragmatic Programmers.
[2] ETSI, Recommendation GSM 03.08 Organization of subscriber Data, release 92.
53
[3] 3GPP Technical Specification 29.002, 3rd Generation Partnership
Project; Technical Specification Group Core Network and Terminals;
Mobile Application Part (MAP) specification , release 7.
[4] 3GPP Technical Specification 23.008, 3rd Generation Partnership
Project; Technical Specification Group Core Network and Terminals; Organization of subscriber data , release 7.
[5] 3GPP Technical Report 21.905, 3rd Generation Partnership Project;
Technical Specification Group Services and System Aspects; Vocabulary
for 3GPP Specifications, release 7.
[6] 3GPP TS 23.040 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Technical realization of the
Short Message Service (SMS), release 7.
[7] 3GPP Technical Specification 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security;
Specification of the MILENAGE Algorithm Set: An example algorithm
set 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; Technical Specification Group Core Network and Terminals; Numbering, addressing and identification, release 7.
[9] Cardell, R. (2009) Evaluation and Testing of Erlang Database Backends
Uppsala: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 of
the third ACM SIGPLAN conference on History of programming languages, ISBN 978-1-59593-766-7.
[12] Wiger,U., Ask,G. and Boortz, K. (2002) World-class product certification using erlang, in Proceedings of the 2002 ACM SIGPLAN workshop
on Erlang, ACM Press.
[13] 3GPP, Technical Specification 3rd Generation Partnership Project;
Technical Specification Group Core Network and Terminals; Customised
Applications for Mobile network Enhanced Logic (CAMEL) Phase 4;
Stage 2, release 7.
[14] 3GPP, 3rd Generation Partnership Project; Technical Specification
Group Services and System Aspects; Customised Applications for Mobile 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, Sivasubramanian, Vosshall and Vogels Dynamo: Amazon’s Highly Available
Key-value Store, 2007.
55