Professional Documents
Culture Documents
Examensarbete 30 hp
Mars 2013
Institutionen fr informationsteknologi
Department of Information Technology
Abstract
Home Location Register (HLR) dedicated for Short
Message Service (SMS)
Niklas Rnnblom and Johan Vikman
Sammanfattning
Inom telekom anvnds en Home Location Register (HLR) fr att registrera
abonnent-data gllande flertalet tjnster, inklusive krestkopplade samtal,
SMS m.fl.
Eftersom mnga olika tjnster mste stdjas blir implementationen av
HLR-databasen omfattande och drmed vldigt dyr, exempelvis mste ca
50 olika och ganska komplicerade databasoperationer hanteras.
Dremot finns tillmningsomrden, t.ex. lskautomater, fr vilka SMS
r den enda tjnst som behver stdjas.
Mlet med denna uppsats r att implementera en HLR-prototyp fr att
utforska realtidsegenskaperna hos en delmngd av databasoperationerna fr
HLR som krvs fr att stdja enbart SMS. Prototypen vi utvecklat och
testat fljer standarden specificerad av 3GPP. Den r ven mycket enklare
att konfigurera och underhlla n en konventionell HLR. Nstan all implementation r gjord i Erlang, ett programmeringssprk som r vl lmpat
fr system dr flera processer samverkar och sprket r ofta anvnt inom
telekom.
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
on
. .
. .
. .
. .
. .
. .
RedHat XX
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
56
56
56
57
57
57
58
58
59
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
61
61
61
61
61
Introduction
Masters Thesis at UU
Supervisor: Lars Kari
Rewiever: Olle Gllmo
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
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 dierent 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 suer 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.
1.3.4
Validation phase
1.4
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 dierent 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
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.
http://en.wikipedia.org/wiki/GSM
10
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 dierent 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
BTSs 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
BTSs 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/oine, 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
operators subscribers, the VLR holds location information for the
operators 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 oine.
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
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
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
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,
o time for updating is not allowed. It should also scale well and have
acceptable performance.
2.5.1
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 dierent Erlang systems,
which are also called nodes. The transparency means that there should be
no dierence 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 dierent
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
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
19
2.7
CouchDB
Replication
Multi-Version-Concurrency-Control
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.
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
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
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 dierent 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 suer 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
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 dierent 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 areutranNotAllowed 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
25
3.4.4
roaming_data
imsi
E.164 ISDN address
E.164 ISDN address
E.164 ISDN address
Table 6: Table for roaming data
3.4.5
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
camel
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 dierent 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_oeredCamel4CSIs
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-csiand psienhancements
[N,...] 1 =< N =< 4
undefined or 3
undefined or 4
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
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
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
ss_profile
integer
defining the SS
defines the call barring for the SS
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
integer
mo_sms_csi
mt_sms_csi
Table 15: The camel_profile table
3.4.12
authentification_data
imsi
128 bit binary key
list of challenge information
Table 16: Authentication data table
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
31
4.2
4.2.1
Interfaces
MAP Interfaces
TCAP Interfaces
Internal Interfaces
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
4.5
MAP Operations
An HLR taking care of SMS has to take care of a lot of dierent scenarios
involving dierent MAP operations and procedures. MAP operations are
divided into five dierent 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
35
marked as available but the request for routing info included an sm-RPPRI, and the subscribers 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
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
39
5
5.1
Evaluation
Testing
To test two virtual machines were used, one with the HLR installed and the
other with a trac 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 trac generator to HLR and
back to trac generator, counts as one successful trac 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.
42
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
dierent 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 ocial release which we decided to do. The new stack
was easier to configure, troubleshoot and use, but featured a little dierent
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 trac generator. The trac
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 dierent 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
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
20091122
8
44
6.5
Summary
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
Hando - 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 Trac 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 dierent networks. 3-level hierarchy,
NETWORK:CLUSTER:MEMBER NUMBER. Each level has a 8-bit
number, between 0 and 255.
PDP - Packet Data Protocol
46
B.1
mtg
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.1
C.1.1
configuration
ss7.cfg
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
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
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]
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
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/
create_table
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 cstructto 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
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
G.2
mtg_statistics:lu_stats/0
G.3
mtg_statistics:reset/0
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 trac 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
55