IT 12 048

Examensarbete 30 hp
Oktober 2012

HSS Front-End implementation

for a large scale common HLR/HSS

PraveenKumar Bhadrapur

Institutionen för informationsteknologi

Department of Information Technology
2
 Abstract
"HSS Front-End implementation for a large scale
common HLR/HSS"
PraveenKumar Bhadrapur

Teknisk- naturvetenskaplig fakultet

UTH-enheten With rapid growth in the use of telecommunication services, subscribers enjoy
value-added services via different telecommunication technologies. The
Besöksadress: telecommunication companies need to get a single view of the subscriber data in
Ångströmlaboratoriet
Lägerhyddsvägen 1 order to profile them (for example:profitable subscribers) and reduce operational
Hus 4, Plan 0 costs by the virtue of maintaining common subscriber data. A Home Location
Register (HLR) in Global System for Mobile Communication (GSM) domain and
Postadress: Home Subscriber Server (HSS) in IP Multimedia Subsystem (IMS) domain store
Box 536
751 21 Uppsala subscriber data.
Telefon: A subscriber may use both GSM and IMS services. The 3rd Generation Partnership
018 – 471 30 03 Project (3GPP) has specified separate standard specifications for HLR and for HSS. As
Telefax: a result, in many cases there is duplication of subscriber data in both of them.
018 – 471 30 00 Minimizing duplication in subscriber data can be accomplished by developing a
common HLR/HSS. This would result in providing single view of the subscriber data in
Hemsida: the GSM and IMS services.
http://www.teknat.uu.se/student

This thesis work investigates the possibility to implement a common HLR/HSS

product by adding a HSS Front-end (FE) server and an IMS subscriber database to an
already existing HLR implementation consisting of a HLR FE server and a GSM
subscriber database.

The FE HSS/HLR prototype was designed and developed using Erlang /Open Telecom
Platform (OTP). The prototype developed is capable of handling Diameter queries
from the Application Server (AS) and Call Control State Function (CSCF) in the IMS
domain and provides HLR database access in the GSM domain. Performance analysis
of the third-party tools, components and the prototype was carried out to evaluate
real-time characteristics.

Handledare: Jonas Falkevik

Ämnesgranskare: Justin Pearson
Examinator: Lisa Kaati
IT 12 048
Sponsor: Mobile Arts AB
Tryckt av: Reprocentralen ITC
4
Acknowledgements

I have to thank few people who have helped complete my thesis successfully. First of all, I would like to thank
Jonas Falkevik, Software Designer, Mobile Arts AB supervisor for my thesis work. Jonas was of great help with
technical ideas and providing necessary feedback for the completion of thesis work. I would like to thank Mobile Arts
AB, Stockholm for providing the required infrastructure and encouragement throughout the thesis duration at their
premises.
I would like to thank Master‘s program thesis coordinator Olle Eriksson at Uppsala university. Justin Pearson, Senior
Lecturer at Uppsala university was reviewer of the thesis work. Thank you Justin for reviewing the thesis work.
Finally, I would like to thank all my friends who I have learnt from and have provided necessary support. I would like
to express gratitude to my mother late Smt. Savitri Bhadrapur, my father Shri. Gurusiddappa Bhadrapur and my
brother Pradeep Kumar Bhadrapur.
1
Contents

1 Introduction 10
1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3 Out of scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4.1 3Gdb Home Subscriber Server (HSS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4.2 Open Source IMS Core (OSIMS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4.3 Resilient and optimized Lightweight Directory Access Protocol (LDAP) database implementa-
tion for a large scale Home Location Register (HLR)/ HSS . . . . . . . . . . . . . . . . . . . . 13
1.5 Document organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Technical background 16
2.1 IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2 IMS subscription model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Diameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4 GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5 Abstract data-structure for GSM subscriber data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6 Mnesia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.7 Third-party tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.7.1 Basho-bench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.7.2 Erlsom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.7.3 eLDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 Design and implementation 24

3.1 LDAP Directory Information Tree (DIT) design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3 Design considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4 Data design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5 IMS HSS architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5.1 Supervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.6 GSM HLR database Application Programming Interface (API) . . . . . . . . . . . . . . . . . . . . . . 34
3.7 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.8 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.9 IMS system components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.9.1 I-CSCF Diameter agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.9.2 S-CSCF Diameter agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.9.3 AS Diameter agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.9.4 HSS subscription manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.9.5 Operator interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.10 IMS Interfaces overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.10.1 Diameter agent API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.10.2 HSS subscription handler API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.10.3 HSS database API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4 Evaluation and testing 42

4.1 Test Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2 Test data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3 Test scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4 Performance measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4.1 Diameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

2
 4.4.2 End-to-end Diameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.4.3 End-to-end RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.5 Global System for Mobile Communication (GSM) HLR database API . . . . . . . . . . . . . . . . . . 48
4.6 Performance analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.6.1 Diameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.6.2 End-to-end diameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.6.3 End-to-end RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.7 Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.8 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.9 Load balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5 Conclusion 58
5.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

A Sequence Diagrams 62
A.1 Diameter Cx procedure sequence diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
A.2 Diameter Sh procedure sequence diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

B Starting Basho-bench for testing 72

C Erlang configuration 74

List of Figures

1.1 GSM domain scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1 IP Multimedia Subsystem (IMS) Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2 IP Multimedia Private Identity (IMPI) and IP Multimedia Public Identity (IMPU) relationship. . . . 18
2.3 Relation between Diameter applications and Diameter base protocol. . . . . . . . . . . . . . . . . . . . 18
2.4 GSM Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1 LDAP DIT of HLR/HSS static subscriber data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 HLR/HSS system overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 HSS dynamic data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4 HLR dynamic data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5 IMS HSS architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.6 IMS HSS supervision structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.7 IMS components supervision structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.1 Test framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.2 Diameter Cx Transmission Control Protocol (TCP) performance analysis . . . . . . . . . . . . . . . . 49
4.3 Diameter Sh TCP performance analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4 Diameter Cx Stream Control Transmission Protocol (SCTP) performance analysis . . . . . . . . . . . 50
4.5 Diameter Sh SCTP performance analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.6 End-to-end Diameter Cx over TCP performance analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.7 End-to-end Diameter Sh over TCP performance analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.8 End-to-end Remote Procedure Call (RPC) Diameter Cx performance analysis . . . . . . . . . . . . . . 52
4.9 End-to-end RPC Diameter Sh performance analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.10 IMS HSS Front-end (FE) LIR block. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.11 IMS HSS Back-end (BE) block. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.12 FE scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.13 Load balancing:subscription location analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

A.1 Location Information Request (LIR)/Location Information Answer (LIA) sequence diagram. . . . . . . 62
A.2 User-Authorization Request (UAR)/User-Authorization Answer (UAA) sequence diagram. . . . . . . . 63

3
 A.3 Server-Assignment Request (SAR)/Server-Assignment Answer (SAA) sequence diagram. . . . . . . . . 64
A.4 Multimedia-Auth Request (MAR)/Multimedia-Auth Answer (MAA) sequence diagram. . . . . . . . . 65
A.5 Registration-Termination Request (RTR)/Registration-Termination Answer (RTA) sequence diagram. 66
A.6 Push-Profile Request (PPR)/Push-Profile Answer (PPA) sequence diagram. . . . . . . . . . . . . . . . 66
A.7 Profile-Update-Request (PUR)/Profile-Update-Answer (PUA) sequence diagram. . . . . . . . . . . . . 67
A.8 User-Data-Request (UDR)/User-Data-Answer (UDA) sequence diagram. . . . . . . . . . . . . . . . . . 68
A.9 Subscribe-Notifications-Request (SNR)/Subscribe-Notifications-Answer (SNA) sequence diagram. . . . 69
A.10 Push-Notification-Request (PNR)/Push-Notification-Answer (PNA) sequence diagram. . . . . . . . . . 70

List of Tables

2.1 Basho-bench null configuration test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2 Erlsom performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1 GSM HLR database API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2 Hardware specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3 IMS HSS database API for Cx procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4 IMS HSS database API for Sh procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.1 Identity server performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.2 Diameter performance results over TCP transport. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3 Diameter performance results over SCTP transport. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.4 End-to-end Diameter performance results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.5 End-to-end RPC performance results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.6 GSM HLR database API performance results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4
5
Glossary

3GPP The 3rd Generation Partnership Project

AAA Authentication, Authorization and Accounting
ACID atomicity, consistency, isolation, durability
ADD Automatic Device Detection
AMF Authentication Management Field
AN Access Network
API Application Programming Interface
AS Application Server
AVP Attribute Value Pair
BDB Berkley Database
BE Back-end
BSC Base Station Controller
BSG Basic Service Group
BSSMAP Base Station System Management Application Part
BSS Base Station Subsystem
BTS Base Transceiver Station
CAMEL Customised Applications for Mobile networks Enhanced Logic
CEA Capabilities-Exchange-Answer
CER Capabilities-Exchange-Request
CFB Call Forwarding on mobile subscriber Busy
CFNRc Call Forwarding on mobile subscriber Not Reachable
CFNRy Call Forwarding No Reply
CFU Call Forwarding Unconditional
CLIP Calling Line Identification Presentation
CLIR Calling Line Identification Restriction
CNAP Calling Name Presentation
CN Core Network
COLP Connected Line identification Presentation
CPU Central Processing unit
CSCF Call Control State Function
CS Circuit Switch
CUG Closed User Group
DIT Directory Information Tree
DTAP Direct Transfer Application Part
FE Front-end
G-MSC Gateway Mobile Switching Centre
GPRS General Packet Radio Services
GSM Global System for Mobile Communication
HLR Home Location Register
HSS Home Subscriber Server
I-CSCF Interrogating Call Session Control Function
IANA Internet Assigned Numbers Authority
IETF Internet Engineering Task Force
IMPI IP Multimedia Private Identity
IMPU IP Multimedia Public Identity
IMSI International Mobile Subscriber Identity
IMS IP Multimedia Subsystem
IM IP Multimedia
IO Input Output

6
IP Implementation Proposal
LDAP Lightweight Directory Access Protocol
LIA Location Information Answer
LIR Location Information Request
LMSI Local Mobile Station Identity
MAA Multimedia-Auth Answer
MAP/C Mobile Application Part C
MAP/D Mobile Application Part D
MAP Mobile Application Part
MAR Multimedia-Auth Request
MB megabyte
MCC Mobile Country Code
MC Multicall
MGC Media Gateway Controller
MG Media Gateway
MSC Mobile-service Switching Center
MSISDN Mobile Subscriber ISDN Number
MSS Mnesia Subscriber Server
MS Mobile Station
NAI Network Access Identifier
NGN Next Generation Network
OAM Operation, Administration and Maintenance
OP Operator Variant Algorithm Configuration Field
OSIMS Open Source IMS Core
OS Operating System
OTP Open Telecom Platform
P-CSCF Proxy Call Session Control Function
PNA Push-Notification-Answer
PNR Push-Notification-Request
PPA Push-Profile Answer
PPR Push-Profile Request
PSI Public Service Identity
PS Packet Switch
PUA Profile-Update-Answer
PUR Profile-Update-Request
RAM Random Access Memory
RFC Request For Comment
RPC Remote Procedure Call
RTA Registration-Termination Answer
RTR Registration-Termination Request
S-CSCF Serving Call Session Control Function
SAA Server-Assignment Answer
SAR Server-Assignment Request
SCCP Signaling Connection Control Part
SCTP Stream Control Transmission Protocol
SCUDIF Service Change and UDI/RDI Fallback
SIM GSM Subscriber Identity Module
SIP Session Initiation Protocol
SNA Subscribe-Notifications-Answer
SNR Subscribe-Notifications-Request
SS7 Signaling System 7
SS Supplementary Services
SVN Subversion
TCP Transmission Control Protocol
TMSI Temporary Mobile Subscriber Identity
UAA User-Authorization Answer
UAR User-Authorization Request
UDA User-Data-Answer
UDR User-Data-Request
URI Uniform Resource Identifier

7
VLR Visitor Location Register
VM Virtual Machine
XML Extensible Markup Language
XSD XML Schema Definition
eMLPP enhanced Multi-Level Precedence Pre-Emption

8
9
Chapter 1

Introduction

In the field of telecommunication, extensive technological advancements have resulted in numerous services. The
number of subscribers accessing telecommunication services increased rapidly over recent past. Due to the increase
in the subscriber number and the number of services accessed via several technologies by the subscribers, effective
subscriber data management became vital in-order to sustain higher order growth. Subscriber data management is
one of the primary issues a multi-service telecommunication operator has to face. Strategic data consolidation in
case of subscriber data in-order to learn about the customer preferences for different services and telecommunication
solutions is of immediate need [30].
Global System for Mobile Communication (GSM) and IP Multimedia Subsystem (IMS) telecommunication technolo-
gies currently offer video, voice, call and location services to the subscribers. In order to perform subscriber data
management of the GSM and IMS subscribers, the telecommunication operator has to obtain the single view of the
subscriber data. Single view of subscriber data can be obtained by subscriber data consolidation. In order to consoli-
date subscriber data in the GSM and IMS domain the telecommunication operator needs to look into to the possibility
of reducing duplication in subscriber data. Home Location Register (HLR) in GSM and Home Subscriber Server (HSS)
in IMS are the central repository of subscriber data for a given home network.
Implementation of the HLR and HSS is specified by The 3rd Generation Partnership Project (3GPP) forum. A
subscriber can be both a GSM subscriber and an IMS subscriber. Separate standards specifications for HLR and
for HSS by 3GPP implies that in many cases the same subscriber data must be stored both in Home Location
Register (HLR) and in Home Subscriber Server (HSS). A common HSS/HLR product would minimize the amount of
subscriber data that gets duplicated. This would help in ensuring a telecommunication operator obtain a single view
of the subscriber data for GSM and IMS technologies.

Brief background

Mobile Arts has already developed an HLR product for GSM consisting of Front-end (FE) server terminating the Mobile
Application Part (MAP) protocol towards the Mobile-service Switching Center (MSC)/Visitor Location Register
(VLR)and a Back-end (BE) server including a GSM subscriber database using Mnesia [1] [24]. This HLR shall be
used as the product base for this thesis work.
In addition, this thesis work shall also be coordinated with another concurrent thesis work that aims to use the
Lightweight Directory Access Protocol (LDAP) in order to provide the GSM/IMS common subscriber database access.
The common subscriber database would store the static HLR/HSS subscriber data. The concurrent thesis work (please
refer to the Section 1.4.3) was done by Erik Grafström [28].
This thesis work required close cooperation with system design at Mobile Arts and the concurrent thesis work [1] [28]
(please refer to the Section 1.4.3). This thesis was therefore done mainly at Mobile Arts premises in Stockholm.

Goal

The goal of the thesis is to provide the HSS Front-end (FE) server and HLR database access API required towards
the common subscriber LDAP database. This would result in realizing a proof-of-concept for common HLR / HSS.

10
1.1 Purpose
The purpose with this thesis is to design and develop Front-end (FE) HLR / HSS server prototype. The HLR /
HSS Front-end (FE) server would require common static subscriber data access. Static data access is provided by
the common Back-end (BE) server. The common BE server uses Lightweight Directory Access Protocol (LDAP) to
provide resilient, highly-scalable database infrastructure. Details about the BE server is covered by the concurrent
thesis work (please refer to the Section 1.4.3).
The approach to investigate the possibility of implementing a common HSS/HLR product for GSM and IMS would
be to

• Re-use an existing Mobile Arts GSM-specific HLR.

• Design and develop IMS-specific HSS.
• The Front-end (FE) IMS HSS designed and developed has to be integrated with the common Back-end (BE)
server which provides both GSM and IMS static subscriber data.

1.2 Scope
The HLR/HSS designed will be able to meet the requirements of serving both IMS and GSM subscribers. To accomplish
the task of providing common subscriber data to both GSM and IMS subscribers, concurrent thesis titled Resilient
and optimized LDAP database implementation for a large scale HLR/HSS will be used as reference. More details
about the concurrent thesis can be found in the Section 1.4.3.

GSM scope

Scope of the thesis work in the GSM domain is represented by the following figure 1.1.

MAP INTERFACE

incoming
_dialog_
handler HLR

LDAP

utilities/
common HLR LOGIC HLR_DB_API
libraries

MNESIA Legend
outgoing Concurrent thesis work
_dialog_
handler Re-used

Thesis work

Figure 1.1: GSM domain scope.

HLR database API for the GSM location, routing and Supplementary Services (SS) are in the scope of thesis work
[10] [7]. As shown in the figure the HLR database API would need integration with concurrent thesis work in-order
to access the static GSM subscriber data. The dynamic data access needed is provided by the in-memory Mnesia
database.

IMS scope

IMS HSS needs to serve data look-up queries just as in case for GSM HLR. The IMS HSS clients are the Call
Control State Function (CSCF) entities and Application Server (AS). The IMS HSS clients interact with the HSS via
Diameter protocol. Diameter is a peer-to-peer Authentication, Authorization and Accounting (AAA) protocol. More
information about Diameter protocol is covered in the Section 2.3.

11
Interrogating Call Session Control Function (I-CSCF), Serving Call Session Control Function (S-CSCF) entities inter-
act with the HSS through the Diameter Cx interface and vice-versa [11]. Application Server (AS) interacts with HSS
via the Diameter Sh interface and vice-versa [13].
IMS procedures over the Diameter Cx and Sh interfaces are in the scope [11, 13].

Prototype features

The following features of the HLR/HSS prototype will be addressed:

• Data design - This necessary in-order to classify the data into static subscriber data which can be served by the
common BE server and the dynamic data which can be served by the in-memory Mnesia database.
• Procedure handlers for IMS and data access API for GSM procedures [11, 13] [10]

• Evaluate real-time characteristics.

1.3 Out of scope

The HLR/HSS is a prototype implementation where certain elements have been left out. The following items are out
of scope.

• Product documentation
• Full Operation, Administration and Maintenance (OAM) support

• Operator specific services such as charging, tracing etc

• GPRS, CAMEL , CUG, SCUDIF services
• GSM MAP procedures for SS
• IMS restoration procedures

1.4 Related work

This section provides information about the relevant work in the same domain as of the thesis work. 3Gdb HSS was
good initial reference as it had some sample implementations of some of the features of the HSS. OSIMS provided a
perspective of usage of HSS as a research prototype which is adhering to the 3GPP specifications [27]. Concurrent
thesis work was done in co-ordination with the thesis work, this helped ease the integration of the FE HSS/HLR to
the BE LDAP access.

1.4.1 3Gdb HSS

3Gdb HSS provides a good overview about IMS HSS design and has minimal reference implementation [37]. 3Gdb
HSS work describes the IMS system, provisioning, subscription management, services, operator interface and simple
Mnesia database design for handling procedures over Cx and Sh Diameter interface. The 3Gdb HSS implementation
has no support for Diameter protocol and public service identities are not considered. The reference implementation
is for Diameter Cx interface, Diameter Sh interface is not considered for implementation.
This served as good initial reference for the thesis work. The performance and other non-functional requirements have
not been taken into consideration.
Subversion (SVN) link to browse through sample implementation can be found here [38].

12
1.4.2 OSIMS

OSIMS is open source implementation of the IMS Core Network (CN) components such as I-CSCF, S-CSCF, Proxy Call
Session Control Function (P-CSCF) and HSS undertaken by the Fraunhofer institute for research purpose. The motive
behind the OSIMS implementation is to provide a playground for testing of the IMS CN and develop IMS applications.
This work describes the reference design and implementation in-depth and as mentioned in the website performance
of the CN elements has not been the main motive and hence no performance metrics about the implementation are
provided [27].
Design of the reference implementation of the HSS by the Fraunhoffer FOKUS group can be found here [31] [26].
Web-based management console, Diameter stack implementation in Java backed by MySQL database, authentication
features, Diameter Cx, Sh, Zx interface implementations are the main features of this prototype.

1.4.3 Resilient and optimized LDAP database implementation for a large scale HLR/
HSS

The concurrent thesis Resilient and optimized LDAP database implementation for a large scale HLR/HSS was taken
up by Erik Grafström during the same period. The thesis work required close cooperation with concurrent thesis work
and required infrastructural support from Mobile Arts, Stockholm.
The concurrent thesis work will provide static subscriber data backed by the LDAP database. Concurrent thesis
supports database resilience, fault tolerance by using replication techniques provided by the OpenLDAP and concurrent
management of static subscriber data [32]. This thesis work will provide LDAP management tools necessary for the
operator to perform the subscriber management. More information can be found in the thesis report [28].
The common LDAP BE is essentially an OpenLDAP server designed to serve the static portions of GSM/ IMS
subscriber data in highly concurrent manner. Access to OpenLDAP server was primarily through eLDAP (Erlang
implementation of LDAP client) [36].

1.5 Document organization

This document is composed of several chapters which covers different aspects of the design. The glossary contains
collection of acronyms used in this document.
A software design specification template has been used as a baseline. [17]

Technical background provides necessary information as preliminaries to read this thesis report. This section
provides brief overview of the IMS, GSM networks and their architectures, subscriber concepts of GSM and IMS
and relevant third-party tools (Basho-bench , eLDAP and Erlsom) used this in thesis work [18] [36] [39].

Design and Implementation provides information about

• LDAP DIT used for the BE LDAP schema is discussed briefly which explains the need for common BE.
Data duplication elimination is explained in this section.
• System overview about the scope of the thesis work. GSM, IMS protocol’s, interfaces which are under
consideration for implementation of the common HLR / HSS are highlighted.
• Design considerations for the prototype development are discussed. Constraints involving the third-party
tools is highlighted.
• Data design discusses the ideas behind the static/dynamic data convention and explains the relation between
data items and how the subscriber data is structured.
• System architecture contains the IMS HSS architecture, supervision structure and GSM HLR database API
implemented are discussed.
• Hardware on which the FE HSS prototype would be deployed.
• Software used for configuring the client and FE HLR/HSS server machines are briefly discussed.
• Component design covers the IMS HSS components to be developed, describing their functionality.
• Interface descriptions contains interfaces used between the IMS HSS components, Erlang Diameter appli-
cations and APIs used in the system.

13
Evaluation and testing describes the following
• Test framework used to conduct performance testing of the prototype components and end-to-end scenarios.
• Test data generated which served as necessary parameters to test Diameter Cx, Sh procedures and GSM
HLR database APIs. Test data generated helped conduct performance testing of the components and
system.
• Performance measurements.
• Performance analysis of the measurements observed carried out in-order to identity the bottle-necks in the
system.
• Capacity of the FE HSS node to serve 10000 IMS subscribers.
• Scalability aspects of the FE HSS.
• Load balancing mechanisms of FE HSS node cluster.
Conclusion Summary of the prototype developed, future enhancements possible to the components, third-party tools
and the prototype.

14
Chapter 2

Technical background

This section provides technical background about IMS and GSM concepts, terminologies and basic architecture.
IMS section 2.1 briefly discusses IMS as Next Generation Network (NGN). Need for an IMS network and its usage are
covered. IMS section 2.1 covers the the key elements of IMS network and its layered architecture. IMS HSS, S-CSCF,
I-CSCF and AS the roles and functionalities are briefly covered. The thesis scope is in the IMS domain is restricted
to HSS, S-CSCF, I-CSCF interacting over Diameter Cx interface and AS interacting over Diameter Sh interface.
Section 2.2 describes the relationship between the public identities and private identities of an IMS subscription.
Section 2.3 provides an overview of the Diameter protocol, Diameter applications Cx, Sh and how the Diameter base
protocol can be extended. Erlang Diameter Library provided as part of R15B release will be used for implementation
of the Diameter Cx, Sh applications.
Section 2.4 provides overview about the GSM networks, interfaces and the protocols among the Access Network (AN)
elements and CN elements.
Section 2.5 covers the hierarchical structure of the subscription model as described here [7].
Section 2.6 provides information about Mnesia as Distributed database and its usage for developing telecommunication
applications.
Section 2.7 provides information about the advantages and issues with third-party tools used in this thesis namely the
Erlsom, Basho-bench as testing tool and refers to eLDAP as third-party tool which was used in the concurrent thesis
work [28].

2.1 IMS
IMS is set of requirements and specifications as defined by 3GPP to provide a unifying architecture for Implementation
Proposal (IP)-based services over both packet-switched and circuit-switched networks. IMS uses standard IP protocols
as defined by the Internet Engineering Task Force (IETF) such as Session Initiation Protocol (SIP).
IMS network intends to provide circuit-switched network subscribers with services built and based on the Internet
applications, services and protocols. The intention of IMS network is to provide convergence and access to various
services such as data, voice, messaging, video and web related technologies to both fixed-line subscribers and wireless-
users in general so that growth of the internet with respect to services provided, quality of service results in enhanced
telecommunication usage.
As shown in the figure 2.1 IMS architecture basically composes of the service/application layer, IMS layer and the
transport layer. Service/application layer essentially consists of various AS. An AS can be SIP server serving multiple
IP Multimedia (IM) services and applications. SIP AS communicates with CSCF elements using SIP messages.
Example of an application server can be a presence server or a location server.
IMS provides services which are available both in the packet-switched (IP networks) and circuit-switched networks.
An IMS This is accomplished using the functionality elements such as the P-CSCF which acts as IMS entry/exit point
for an IMS network, S-CSCF element provides the required serving capabilities for an IMS subscriber in the home
network and I-CSCF acts as the contact, forwarding point to each of the operator’s network. The services applications
are hosted by the AS.

16
IMS HSS manages subscriber, service data and is the main database for an IMS network. In an IMS network, HSS
serves requests from the S-CSCF and the I-CSCF over the Diameter Cx interface. An I-CSCF can request an IMS HSS
for the identity of the S-CSCF currently serving a given public identity. S-CSCF can request to download user-profiles
from IMS HSS. AS can request for user-data download over Diameter Sh interface from the HSS. These interactions
over Diameter Cx, Sh interface can be referred in the figure 2.1. These are few of the many instances where HSS has
to serve the subscriber data, location related, authentication information of the identities. Functionalities expected
from an IMS HSS can be looked up here in the technical specification [4].

Figure 2.1: IMS Architecture.

2.2 IMS subscription model

An IMS subscriber holds a relation with respect to the IMS operator network through an IMS subscription. IMS
subscription can have multiple users. Each IMS user is identified uniquely by IMPI or the private user identity [5].
Private user identity is in the form of Network Access Identifier (NAI) and take the form username@realm [5] [29].
Private user identity is basically used to authenticate the user and is not known to the user usually. Steps to generate
an private user identity by the operator in the home network can be found here [5].
Communication with other users is done using the public user identity or IMPU. Public user identities are in the
form of SIP Uniform Resource Identifier (URI) or telephone URI. An example IMPU in the SIP URI format could be
sip:james@it.uu.se.
IMS service profile is basically collection of service and user related data [11]. The IMS service profile is defined and
maintained by the IMS HSS.
Relationship between the IMS user identities can be visualized via the following figure 2.2 [9].

17
 Public user
identity

Service
Profile

Private user Public user

IMS subscription
identity identity

Public user Service

identity Profile

Figure 2.2: IMPI and IMPU relationship.

Public user identities can be implicitly registered as a group of public identities, this ensures that all public identities
are registered at the same time and similarly for de-registration. Some of the implicitly registered can be associated
with different services profile than the other in the same group. Sharing of the service profiles among the implicit
groups is allowed. A single public identity can also be shared among two or more private identities. More information
can be found here [9].
Public Service Identity (PSI) identifies a service, or a specific resource in an AS created for a particular type of service
[5]. Public service identity can take the form of SIP URI or a telephone URI. These identities are mainly used over
the Diameter Sh interface. Example for a PSI is sip:voicechat@it.uu.se.
Private service identity is similar in relationship to PSI as the IMPI is to the IMPU. Private service identity is
of the form NAI. This is usually operator defined and used in similar manner as the IMPI to register, de-register,
authenticate and authorize services [5].

2.3 Diameter
Diameter is AAA framework for applications used in the IMS network [33]. Diameter protocol is an extension and
enhanced version of the RADIUS protocol. The Diameter base protocol is defined in the Request For Comment (RFC)
3588. Diameter applications (Diameter applications here mean, a protocol which can extended) can be built over the
Diameter base protocol. Each such application is identified by the application-identifier. For example, Internet
Assigned Numbers Authority (IANA) has allocated Diameter Cx application, an application identifier 16777216.
Relationship of Diameter applications and Diameter base protocol is as shown in the figure 2.3.

Diameter Diameter
Cx Sh

Diameter base
protocol

Figure 2.3: Relation between Diameter applications and Diameter base protocol.

Diameter supports reliable transport protocols TCP and SCTP ([34]). Diameter base protocol provides delivery of
Attribute Value Pair (AVP)s. AVP are used to deliver data and every Diameter message is composed of the several
AVPs, some of which are mandatory [33]. Diameter applications can added their own AVPs if they are not defined as
part of the base protocol.
Diameter client can be a P-CSCF, which could perform access control. Diameter server can be a HSS which provides
AAA requests for the realm under consideration. A HSS has to support Diameter applications Cx, Sh in addition to
the base protocol in order to support both Diameter Cx clients I-CSCF, S-CSCF and Diameter Sh client AS.
Erlang/Open Telecom Platform (OTP) in the release R15B has provided Diameter base protocol implementation
version 1.1 [19]. Further in this thesis report, wherever Diameter discussions regarding the implementation are carried
out will refer to the Erlang/OTP R15B provided Diameter version 1.1 library.

18
2.4 GSM
GSM network typically consists of AN elements and CN elements. Mobile Station (MS), Base Transceiver Station
(BTS) and Base Station Controller (BSC) form the AN. MSC, VLR and the HLR form the CN.
BTS is the radio element which serves one cell. Typically a BTS has several trans-receivers which can serve several
different frequencies for a given cell area. BTS provides necessary signaling to BSC over Abis interface and media to
the CN. MS connect to the BTS over the Um interface. BSC handles number of BTS. It handles the administration of
BTS, cell data and location related data. BTS and BSC form the Base Station Subsystem (BSS). The Abis interface
used between the BTS and BSC consists of radio-link establishment and management procedures [3].

Figure 2.4: GSM Architecture.

A MSC is connected to large number of BSC via the Mobile Application Part (MAP) A interface. Several protocols are
used between BSC and MSC over the A interface. Signaling Connection Control Part (SCCP) provides connection-
oriented and connectionless services as a lower layer protocol [2]. Base Station System Management Application
Part (BSSMAP), Direct Transfer Application Part (DTAP) protocols use SCCP as underlying protocol, all of these
protocols interact over the MAP A interface.
MSC is the main routing entity in the CN. Via the B interface it connects to the VLR. MSC uses Mobile Application
Part (MAP) B interface for interrogating the VLR during the location and call procedures execution.
MSC handles call-control, signaling and directs the Media Gateway Controller (MGC) to manage the resources per-
taining to the media services in a Media Gateway (MG). VLR stores temporary information such as Temporary Mobile
Subscriber Identity (TMSI) and handles location management, call related procedures and temporary subscriber data
for a given MSC area which pulled from the HLR.
HLR is the main database for given home network managed by the operator. HLR mainly stores permanent subscriber
data. HLR provides necessary interface to retrieve the subscriber data for a VLR over the MAP D interface. Gateway
Mobile Switching Centre (G-MSC) interfaces over MAP C interface to interrogate the HLR for subscriber information
and locating the MSC/VLR which is currently handling a given MS.

2.5 Abstract data-structure for GSM subscriber data

Abstract data structure for storing the GSM subscriber data can be referred in the [7] which is essentially a hierarchical
tree rooted with International Mobile Subscriber Identity (IMSI) of a given GSM subscriber. The data which is
retrieved for the VLR request is in the scope of interest. Below the numbering schemes, subscriber identification, SS,
Basic Service Group (BSG) and other terminologies related to handling of subscriber data are discussed.
IMSI is allocated for each mobile subscriber in the GSM [5]. IMSI uniquely identifies a mobile subscriber and hence
needs confidentiality over the Um interface. TMSI is generally allocated by VLR for this purpose. IMSI is used for
authentication purpose during location updates and call handling procedures.

19
At least one Mobile Subscriber ISDN Number (MSISDN) is assigned to the mobile subscriber. MSISDN is typical
used for call-routing purpose. MSISDN is allocated such that it can be used as SCCP global-title address, which is
essential for the routing messages to the HLR which holds the subscriber data for a given MS.
Subscriber data consists of Basic service and SS information which determines the type of services provisioned for a
given subscriber. Basic services consist of Tele-services and Bearer-services. Several BSG have been defined for the
Tele-services and Bearer-services.
SS enhance the Basic services, they work on per BSG basis. Examples of SS can be a Call Forwarding Unconditional
(CFU), Call Forwarding No Reply (CFNRy).

2.6 Mnesia
Mnesia is distributed database primarily developed for telecommunication applications [24]. Mnesia was used in the
Random Access Memory (RAM) only mode for this thesis work. Mnesia provided dynamic data access to the FE HLR
/ HSS servers. Mnesia as distributed database provides transactional features the atomicity, consistency, isolation,
durability (ACID) properties which were used extensively. Mnesia features are listed in the reference manual [24].
Mnesia is bundled along the Erlang/ OTP release as a library. Erlang records are turned into the entries of the
respective tables in the Mnesia database. This close interoperability of Mnesia with Erlang/OTP with data-structures
such as Erlang records and for querying, the list comprehensions makes Mnesia a viable option for usage in our thesis
which is also a telecommunication application.

2.7 Third-party tools

The following sections describe the third-party tools used in the design and implementation, testing and evaluation of
the HLRHSS prototype.

2.7.1 Basho-bench

Basho-bench provides a test framework for testing a huge number of highly concurrent Erlang processes which not
only stress test the system but also provide visual performance analysis of the tests run in terms of throughput,
latency(mean, median, percentile) metrics [18].
Basho-bench provides a mechanism to configure test runs and write customized drivers to test each Erlang process
or a component. Basho-bench was used extensively to test the FE components such as Erlsom, eLDAP, Diameter
components and to run end-to-end tests via Diameter protocol and via RPC.
Usage of basho-bench can be found in the Appendix B. Appendix B details about how to start a basho-bench test
and required drivers and configuration files to be written in order to run required tests.
Basho-bench as test-tool was run on one of the client machine using driver basho_bench_driver_null and configu-
ration parameters as shown in the table 2.1. basho_bench_driver_null driver shipped with the Basho-bench tool
tests the the basho-bench performance with minimum overhead.
Table 2.1 has results for the basho_bench_driver_null test.

Number of CPU Memory

Rate Yield
concurrent Throughput utilization utilization
(ops/sec) (%)
workers (%) (%)
1000 10 9900 99 45 27
2000 10 19530 97.65 45 52
3000 10 29370 97.9 45 78

Table 2.1: Basho-bench null configuration test

Advantages

• Supports testing of large number of concurrent workers at desired rate.

20
 • Provides performance testing infrastructure with visual results in terms of throughput, latency as key metrics.
• Provides configuration and customized drivers for each of the test case required and provides test data (example:
for key generation).
• Max rate does provide an idea about the performance and behaviour of the server while the server is overloaded.

Drawbacks

• Does not provide required yield (required throughput) as depicted in the table 2.1.
This explains the minor inconsistency in providing required yield and affects the testing results observed with
minor error rate.
• Max rate, does not show the exact number of operations/sec possible. Some of the test runs revealed that
Central Processing unit (CPU) was not utilized completely when the test were run at the max rate.
• Memory utilization per concurrent worker is high. As derived from the table 2.1, a single worker uses around
1MB of memory.
• More information about test results such as CPU utilization, memory utilization and io for both the basho-bench
client and the system to be tested, would be nice to have it in one place for each test run.

2.7.2 Erlsom

The Erlsom library provides API’s to transform Erlang data structures into a Extensible Markup Language (XML)
governed by a schema. Erlsom is to be used to write XML strings according to the Diameter Cx XML schema and
the Diameter Sh XML schema using Erlsom‘s Data Binder mode [39].

Erlsom performance

Performance of the Erlsom XML parsing utility in-order to transform Erlang records into XML strings validated
against a schema has been tabulated in table 2.2 [39]. The schema for each of the interface Cx and Sh interface has
been specified in technical specification TS:29.228 and TS:29.328 respectively [11] [13] . Schema‘s serve as models
against which the generated the XML will be validated against. Minimal data was used to fill the required XML
records which was written as XML string. All the tests tabulated below had schema‘s pre-compiled into models. This
is done as it reduces the CPU computation required every time the schema‘s are compiled into models and the same
optimization has been used in the implementation of HLR / HSS. Rate at which each basho-bench concurrent worker
is 10 ops/sec. (worker - here is the driver code which transforms an Erlang record into an XML string as specified
by the schema). Number of concurrent workers in each of the tests has varied from 50, 100, 200 giving number of
operations per sec values 500, 1000, 2000 respectively.

Observed CPU Memory

Expected Latency
Schema Throughput utilization utilization
Operations/sec (ms)
(ops/sec) (%) (%)
Cx 500 500 0.6 80 2.5
1000 1000 0.6 150 4
2000 2000 0.8 215 7.6

Sh 500 500 1.15 105 2.5

1000 1000 1.2 185 4.1
2000 2000 0.8 225 7.6

Table 2.2: Erlsom performance.

Erlsom performance analysis

Observation in the table 2.2 shows that with increase in the operations /sec the expected throughput on the test
machine is delivered and with less variation in latency. The CPU utilization goes up considerably and memory
utilization increases slightly.

21
Considerable increase in CPU utilization by the Erlsom with respect to operations/sec is of prime concern since the
procedures which use Erlsom extensively such as Cx/SAR , Sh/UDR, Sh/PUR, Sh/SNR will be bottle-necked for
CPU for other operations. This observation is discussed more in the end-to-end RPC Section here 4.4.3.
Erlsom allows pre-compilation of the schema into a model. A schema can once be pre-compiled and stored in memory to
be read later for validation when XML strings are written by the Erlsom. This optimization reduces CPU computation
considerably. CPU utilization reduction for Erlsom write calls needs to be investigated at moderate to high loads.

Advantages

• Ease of use.
• Schema to model transformation can be done once and re-used.
• Memory utilization for trivial data is not very high.

• Provides utility to get the record and fields for a given XML Schema Definition (XSD) schema.
erlsom:write_xsd_hrl_file() will get the necessary Erlang records for a given schema into a Erlang hrl file.

Drawbacks

• High CPU utilization is of prime concern as the number of operations/second increases. The increase is almost
linear, possible ways to reduce the near linear increase in CPU utilization needs to be investigated.

2.7.3 eLDAP

eLDAP [36] was used to connect to the BE OpenLDAP servers. eLDAP APIs were provided by the concurrent thesis
work 1.4.3. More about eLDAP API can be found here [28].

22
Chapter 3

Design and implementation

This chapter covers the design and implementation aspects of the HLR/ HSS prototype.
The design of LDAP DIT in the section 3.1. The BE LDAP schema design in the concurrent thesis work 1.4.3 is based
on the DIT presented in the figure 3.1.
Section 3.2 provides the overview of the HLR/HSS prototype and functional blocks which required interfaces to be
designed. LDAP functional block from the FE HLR/HSS perspective is essentially eLDAP API interface provided by
the concurrent thesis work 1.4.3
Section 3.3 reflects on why Erlang/OTP was preferred language for implementation and classification of data between
the FE and BE. Erlang Diameter library, hardware constraints, need of Erlsom as third-party library are constraints
with which the prototype was to be designed and developed.
Section 3.4 has information about the dynamic data stored in the Mnesia tables. Fields of the tables are briefly
explained. The Mnesia tables and fields considered here are sufficient for the procedures of Diameter Cx, Sh interface
in IMS domain and to provide location, call-handling and SS procedures in the GSM domain.
Section 3.5 explains the sharing-nothing design of the FE HSS components. Interactions of the Diameter agents over
Cx and Sh interface, the procedure worker components, the HSS database API components and the HSS subscription
manager components are covered.
Section 3.6 provides the mapping between the MAP procedures which use the HLR database API resulting in corre-
sponding eLDAP queries or Mnesia database access or both.
The hardware specification of the machines used in this thesis are covered in the section 3.7.
Erlang/OTP as development environment and Operating System (OS) deployed on the test machines are covered in
the Section 3.8.
Components of the IMS HSS system described in the Section 3.2 are covered in more detail in the Section 3.9.
Interfaces description for the Diameter agents implemented using the Erlang Diameter library , HSS subscription
handling interfaces and the HSS database API are covered in the Section 3.10.

3.1 LDAP DIT design

Initial study on the parameters needed to serve both IMS, GSM subscribers helped to identify the required data and
classify the data into static subscriber data and the dynamic data (essentially procedural data).
A common BE server serves both GSM/IMS subscriber data. The DIT in the figure 3.1 has a subscriber (subscriber-id
SID = 1234 )with both GSM and IMS subscriptions.
Service profiles are identified by the ServiceProfileId. Services are uniquely identified by private service identity.

24
 Figure 3.1: LDAP DIT of HLR/HSS static subscriber data.

By grouping IMS and GSM subscribers under the common group of Subscribers, data pertaining to charging, account-
ing, billing, some of authentication parameters and other common subscriber data can be stored once.
An operator would have common set of service profiles which could be served in the given home network. By generating
a common-set of service profiles which could be associated with most of subscribers, a large amount of data duplication
is avoided. Each service profile would have both GSM and IMS service profile. By mapping the members of the group
Subscribers to the group Profiles, the data to be managed would be significantly lesser than associating each subscriber
to a profile.
The number of service profiles would increase only if the operator would have set of services are newly added or a
new combination of services in a profile is requested. Service profiles are combination of the members from the group
Services. Since each service is uniquely identified by private service identity, a reference to the object of the service in
the profile is necessary and sufficient to create an association. Similarly an association between the object of subscriber
and service profile can be created by referencing to the service profile id of interest.

3.2 System Overview

An overview of the HLR/HSS can be seen in figure 3.2. The HLR/HSS serves both GSM and IMS subscribers
by the use of a FE and BE where the FE handles the procedure logic and dynamic data and the BE serves the
static subscriber data. This enables the use of specialized technologies, LDAP in the BE is optimized for a heavy read
intensive environment while Mnesia in the FE serves well as in-memory database and Erlang/OTP provides concurrent
messaging among various components of the HLR/HSS.
The IMS part of the FE is comprised of a Diameter protocol handler, a HSS server and a Mnesia database for the
IMS dynamic subscriber data.
The GSM part of the FE is comprised of a MAP protocol handler, a HLR server and a Mnesia database for the GSM
dynamic subscriber data.
The common LDAP backend is comprised of a LDAP client and the LDAP server with its database of static subscriber
data serving both GSM and IMS subscribers.

25
 Figure 3.2: HLR/HSS system overview.

3.3 Design considerations

The aim of the HLR/HSS design is to enable subscriber registration, location update procedures and to set up calls
as specified by 3GPP.
The HLR/HSS supports a subset of the IMS and GSM subscription models. (Please refer Section 2.2 and Section 2.5
for preliminary information about IMS and GSM subscription model).
The key idea behind the division between a FE and BE is a divide in how subscriber data is managed and used by the
procedures to serve subscribers. The FE handles dynamic subscriber data such as current location, registration status
and service status. The BE (please refer concurrent thesis work in the Section 1.4.3 for more information) handles the
static portion which can be seen as provisioning data, it contains the subscriber and the service profile data.
One example of how the static data relates to the dynamic data is SS. The BE only covers the provisioning state of
different SS codes while the FE handles registration and activation state.
Erlang is the programming language of choice for implementing the FE. Erlang provides the required features to
implement a highly concurrent and fault-tolerant HLR/HSS. OTP provides required platform to implement procedures
as described by the specifications. The Mnesia database is used to serve dynamic data since Mnesia provides in-memory
low-cost and highly efficient look-up in RAM-only mode.
The constraints on the HLR/HSS are as follows.

• The HLR/HSS is required to be standards compliant. Compliance has been achieved in design by basing the data
and component design on 3GPP specifications. Implementation of procedures according to the specifications
was primary requirement which has been met.

• Erlang Diameter stack has to be used since as described above Erlang/OTP is the preferred language and the
Erlang Diameter protocol is provided as library in the R15B release. Preferred development environment is
Erlang/OTP in Mobile Arts [19].

26
 • Erlsom library was needed for some of the Diameter Cx and Sh procedures in-order to generate XML string
according to the schema specified in the specification TS:29.228 and TS:29.328 [39] [11] [13]. More details on
Erlsom can be found in Section 2.7.2.
• Hardware specifications are in the table 3.2 for the client and the FE HSS server. Performance measurements
of the components and the prototype were carried on the hardware mentioned in the table 3.2.

3.4 Data design

Dynamic data records are stored in Mnesia tables. Refer to figure 3.3 for an overview of the HSS dynamic data and
figure 3.4 for the HLR dynamic data.

HSS dynamic data

IMS operator data as seen in figure 3.3a is configuration data related to access control and network capabilities which
is set at start-up and mostly read while running. The data items in the operator data Mnesia tables enable the HSS
to handle Cx and Sh procedures.
IMS network data tables as seen in figure 3.3b are read/updated by Cx and Sh procedures. The grey objects(nested
records) as highlighted are sub-objects of the (outer nested records) black objects. Sub-records are contained within
the records. These records are needed to enable user registration and service registration over the Cx interface and
subscription notification handling for transparent data over the Sh interface.

(a) Operator data. (b) Network data.

Figure 3.3: HSS dynamic data.

The contents of the tables are as follows.

as_permission_list
as_permission_list is operator data which contains permissions for each AS in the operator network. Allowed
operations are update, subscribe, receive transparent and non-transparent data over the Sh interface.
as_id is the Diameter name of a given AS.
data_ref_id is an identifier to transparent repository data or the non-transparent data.
allowed_operation as discussed above for a data_ref_id.
operator_specific_data
operator_id is the key used to retrieve information for a given operator network.
operator_id is a unique identifier for a given operator.
op is a 128 bit Operator Variant Algorithm Configuration Field (OP) used when generating authentication
vectors for users and is secret for a given operator. [15]

27
 loose_route_ind_capability indicates if SIP loose routing mechanism is supported by the operator network.
hss_max_data_size indicates the maximum data size supported by the HSS while performing operations on the
user profile or user data over Diameter Cx and Diameter Sh interface respectively.
amf is a 16 bit Authentication Management Field (AMF) defined per operator and is used when generating
authentication vectors.

user_registration_info
user_registration_info has a wild-carded IMPU or a distinct IMPU as key. This table is used when serving
requests to verify the current state of a given IMPU, its current associated S-CSCF Name, implicit IMPU set,
authentication pending flag and sequence number.
(w)impu is in the form of a SIP URI.
impi is private identity of a given IMS subscriber and can be any URI.
is_auth_flag_pending is indicates if authentication pending for a given IMPU.
status reflects the IMPU’s current state: registered, unregistered or not-registered.
s_cscf_name is the Diameter name of the assigned S-CSCF.
implicit_impu is a list of the implicitly registered IMPU set.
sequence_number is the SQN HE part of the sequence number used in authentication.
service_registration_info
service_registration_info has wild-carded PSI as the key. It is used to retrieve information regarding the
current state (psi_activation_state) of a given PSI, the assigned S-CSCF and the private_service_ identity
associated with the PSI.
(w)psi is in the form of a SIP URI.
private_service_identity is private identity of a given PSI. It can be any URI.
psi_activation_state reflects the PSI’s activation state.
s_cscf_name is the Diameter name of the assigned S-CSCF.

sh_subscription_notify_info
sh_subscription_notify_info record contains information about the subscriptions to transparent or non-
transparent data made over the Sh interface. data_ref_id is the key and wild-carded/distinct IMPU, PSI and
as_id are in-dices for quick look-up.
data_ref_id identifies a transparent repository data item or a non-transparent data item. Refer to Table 7.6
in TS 29.328. [13]
(w)impu_(w)psi can be either a wild-carded/distinct IMPU or wild-carded/distinct PSI. It is a SIP URI.
as_id is the Diameter name of a given AS.
expiry_time is relative time used to indicate the expiration of the subscription after which no notifications are
sent.
private_identity(user_service) is a private identity of user or a service.
is_one_time_avp is used to denote if a notification is to be sent only once.
repository
repository has wild-carded or distinct PSI or wild-carded or distinct IMPU as the key. It contains a list of
repository_data records for which a given identity.
(w)impu_(w)psi can be either a wild-carded/distinct IMPU or wild-carded/distinct PSI, it is a SIP URI.
repository_data is a list of transparent data.
repository_data
repository_data has service indication as key which is a unique string used to identify a given service. Reposi-
tory data is semantically transparent to the HSS but not to the AS which is subscribing to the data. It contains
mainly service information which can be updated by the AS.
service_indication uniquely identifies a service.
service_data is data which is semantically understood by the AS.
sequence_number is used to update the service data and is maintained by the HSS.

28
HLR dynamic data

HLR dynamic data is a set of Mnesia tables comprised of GSM operator data seen in figure 3.4a and network data
seen in figure 3.4b. The grey objects(nested records) as highlighted are sub-objects of the (outer nested records) black
objects. Sub-records are contained within the records. GSM network data is accessed over the MAP using MAP/C
and MAP/D procedures and the operator data contains operator specific configuration data required to set up and
run a GSM network.

(a) Operator data.

(b) Network data.

Figure 3.4: HLR dynamic data.

The contents of the tables are as follows.

operator_information
operator_information has operator_id as key. This table contains the GSM operator information such as the
operating VLR list , HLR list, MSC list, supported services by MSC, pre-paging support, Automatic Device
Detection (ADD) functionality and domain selection support for a given HLR.
operator_id is the key and it is used to identify the operator.
operating_vlr_list is a list of active VLRs in the network.
operating_hlr_list is a list of active HLRs in the network.
operating_msc_list is a list of active MSCs in the network.
mcc is the operators Mobile Country Code (MCC).
supported_msc_services_list is a list of services supported by the MSCs in the operator network.
pre-paging_supported_supported_hlr is used to indicate if the HLR supports pre-paging.
hlr_add_functionality_supported indicates if the HLR supports ADD functionality.
hlr_domain_selection_supported indicates if the HLR supports domain selection among Circuit Switch (CS),
Packet Switch (PS) or other domains.

29
subscriber_status
subscriber_status information for a given IMSI contains status flags and other registration related parameters.
MSISDN is alternative index to make look-ups more efficient.
imsi is the key, used to uniquely identify a GSM Subscriber Identity Module (SIM).
msisdn is used for routing calls to a active MS
mnrf is flag to indicate if the MS is reachable or not.
lmsi is the associated Local Mobile Station Identity (LMSI) of an IMSI.
ms_purge_flag indicates if the MS’s subscriber data is purged by the operator.
check_ss_indication indicates if the subscription has SS to process.
roaming_info
roaming_info record is updated frequently when a MS moves from one VLR to another. The associated LMSI,
MSC are updated.
imsi serves as key to retrieve roaming information.
vlr_number is the E.164 number of the currently associated VLR.
msc_number is the E.164 number of the currently associated MSC.
lmsi is the associated LMSI for a given IMSI.
ss_profile
ss_profile record for a given IMSI consists of a list of SS provisioned and the registration data for SS.
imsi used as key to retrieve the provisioned SS list and SS registration data. provisioned_ss_list is a list of
provisioned_ss_features.
ss_registration_data contains registration information for a given IMSI applicable for all the provisioned SS.
provisioned_ss_features
provisioned_ss_features record contains information about one SS code.
provisioned_ss_code Provisioned SS code identifies the SS.
bsg is a list of BSG for which the SS code applies to.
ss_status is the current status of the SS code, which is kept in the ss_status record.
subscription_options is an option for Call Forwarding on mobile subscriber Busy (CFB), Call Forwarding on
mobile subscriber Not Reachable (CFNRc) and CFNRy.
override_category is an option for Calling Line Identification Presentation (CLIP), Connected Line identifi-
cation Presentation (COLP) and Calling Name Presentation (CNAP).
presentation_mode is an option for Calling Line Identification Restriction (CLIR)
max_entitled_priority is an option for enhanced Multi-Level Precedence Pre-Emption (eMLPP).
default is an option for eMLPP.
subscribed_max_cs_bearers is an option for Multicall (MC).
user_defined_max_cs_bearers is an option for MC.
ss_registration_data
ss_registration_data contains registration details for a subscribers SS profile.
password is the password which is used when registering a SS.
number_of_retries number of password retries allowed during registration.
controlled_password indicates if SS registration is controlled by user-password or by the service provider.
blocked indicates if the given IMSI is blocked from SS registration.
bsg
A BSG is identified by its bsg_code.
bsg_code is the BSG code, an example is AllTeleservices.
ss_status is the SS status of for this BSG, which is kept in the ss_status record.
forwarded_to_number is a SS option for this BSG which applies to SS CFB, CFNRc and CFNRy.
forwarded_to_subaddress is a SS option for this BSG which applies to CFB, CFNRc and CFNRy.
no_reply_condition_timer is a SS option for this BSG which applies to CFNRy.

30
ss_status
SS status is comprised of four state flags.
provision_state is set when the SS is provisioned by the service provider for a given IMSI. When subscription
for the SS is withdrawn the state is set to not provisioned. This can only be performed by the service provider.
The provisioning state shall be on a per subscriber basis, and hence the same for all basic service groups.
registration_state is set when the SS is registered by the service provider for a given IMSI or by the MS.
When the SS subscription is de-registered, the state is set as not registered. This can be done by either service
provider or the MS.
activation_state is set to either active and quiescent or active and operative when the SS is activated, not
active when the SS is deactivated.
induced_state is set as induced by the HLR for some of the SS where it is applicable.

authentication_info
A set of authentication vectors are stored in the HLR for a given IMSI.
imsi key to retrieve the authentication vectors.
challenge_data is a list is authentication vectors.

challenge_data
challenge_data contains all the data of a authentication vector, where item_num is the vector index.
item_num is the index of the authentication vector.
rand is a 128 bit random number used for calculating the challenge and response.
sres is a 128 bit authentication challenge.
used_indicator indicates if the authentication data vector has been used before.
number_of_retries is the number of retries allowed for a certain challenge.

3.5 IMS HSS architecture

IMS system architecture 3.5 employs a share-nothing design [35]. There exists no global state in the system. The
state of the system across sessions responsible for handling the procedures is stored only in Mnesia or LDAP. This
would lead to each and every process in the system have only its state. As result, when a process crashes, it would
result in the loss of its own state without affecting the global state of the system.
The Share-nothing architecture choice requires a control database with high concurrency management [35]. Transac-
tional properties is required for the data which is updated and read. Mnesia is a distributed database system which
provides transactional operations on the data it stores. Dynamic data records, the Mnesia tables are explained in
more detail in section 3.4.
Reading static data from the LDAP database is highly efficient 1.4.3. Mnesia database serves well in handling session
data for each of the Cx and Sh procedures. Data read by the procedure workers can utilize the read data in efficient
manner, if the procedure logic reuses the data. This reduces the number of queries made to the BE LDAP server.
Pre-fetching of data for the subsequent queries would result in higher memory usage as the read data exists in memory
till the procedure worker completes execution, this is a design trade-off. Appropriate pre-fetching of data by the
hss_db_api workers is possible since the LDAP server provides the required data object with all of its attributes
(refer to LDAP schema discussion in [28]). This results in re-use of the read data instead of making subsequent
LDAP queries, as procedures usually need the attributes from the same LDAP data object to proceed executing. For
example, a search query for a given IMPU on imsUser objectClass would result in returning all the attributes of the
objectClass imsUser which could be reused by the procedure logic by storing the data in its own state (refer to the
LDAP schema in the concurrent thesis report [28]). Similarly, data fetched by reading from the Mnesia transactions
can be reused for data stored in the Mnesia database. The fetched data is stored in the state of the procedure worker,
a gen_server behaviour provided by the OTP. In the memory vs number of database look-ups trade-off, this design
prefers reduced number of database look-ups for the reasons described above.

31
 IMS Control Plane HSS

i-cscf_diameter_agent hss_cx_diameter_agent hss_cx_diameter_server_workers

LDAP Server
icscf_diameter_client hss_cx_diameter_server hss_cx_query_select_pull

icscf_diameter_client_cb hss_cx_diameter_server_cb hss_cx_put_pull hss_db

icscf_diameter_server hss_cx_diameter_client_cb hss_cx_location_query

eldap_manager
icscf_diameter_server_cb
hss_cx_diameter_client hss_cx_authdatareq hss_db_api
hss_db_api

mnesia_worker

s-cscf_diameter_agent
scscf_diameter_client

scscf_diameter_client_cb hss_cx_diameter_client_workers
operator_interface
hss_cx_deregister
scscf_diameter_server hss_subscription_manager

scscf_diameter_server_cb hss_cx_update_subscr_data
hss_t_data_ hss_nt_data_
subs_server subs_server

hss_sh_diameter_server_workers
IMS Service Plane
hss_sh_pull
hss_subs_handler
as_diameter_agent hss_sh_diameter_agent
as_diameter_client hss_sh_diameter_server hss_sh_update

as_diameter_client_cb hss_sh_diameter_server_cb hss_sh_subs_notif

as_diameter_server hss_sh_diameter_client_cb
hss_sh_diameter_client_workers
as_diameter_server_cb hss_sh_diameter_client hss_sh_notif

Mnesia

Legend
Cx HSS Server Call

Sh HSS Server Call

Cx HSS Client Call

Sh HSS Client Call

Erlang Message

Figure 3.5: IMS HSS architecture.

Each Diameter agent can act as a Diameter client or a Diameter server. The IMS Control Plane consists of two Diameter
agents (i-cscf_diameter_agent and s-cscf_diameter_agent) which interacts with the HSS hss_cx_diameter_agent.
This interaction of the IMS Control Plane Diameter agents over the Diameter Cx interface is highlighted shown in
figure 3.5.
The IMS Service Plane consists of as_diameter_agent which would interact with the HSS hss_sh_diameter_agent.
This interaction of the IMS Service Plane Diameter agent over the Diameter Sh interface is also highlighted in figure
3.5.
Diameter applications can be configured to have separate call-back modules or the same call-back can be configured
to handle both Diameter applications Cx, Sh (As previously mentioned in the Section 2.3, Diameter application here
refers to the Diameter protocols Cx, Sh extended over the common Diameter base protocol). Reason for choosing
separate call-backs for each of the application is to have modularity and understand the performance characteristics
of each Diameter application procedure calls, which were run in isolation.
Each of the Diameter agents (client and server) would register Diameter application as a service. For example, the
Diameter agent, I-CSCF could register a Diameter Cx application as service and AS, a Diameter Sh application as
a Diameter service. The corresponding application (Cx or Sh) would be started as service by the HSS Diameter
agent. The Erlang Diameter stack provides connection setup over TCP or SCTP transport protocols. After the
connection set up between two Diameter agents, the client Diameter agent (for example an I-CSCF) can send Diameter
commands to the server Diameter agent(HSS listening to the Diameter Cx application messages). The Diameter agent
(HSS) serving as service application spawns a call-back process for each of Diameter message received. Each received
Diameter command/request received spawns a procedure worker process. The procedure worker process spawned
executes the procedural logic as defined in 3GPP TS 29.228 for Cx procedures and TS 29.328 for the Sh procedures
[11, 13]. The process design pattern of the hss_cx_diameter_server_workers, hss_cx_diameter_client_workers,
hss_sh_diameter_server_workers, hss_sh_diameter_client_workers is a gen_server behaviour or regular Erlang
code. Diameter Sh application messages can be similarly passed on, between the Diameter agents configured as either
a server or client.

32
To execute the procedure logic, each of the workers interact with the hss_db module. The hss_db_api process is
spawned per process request. The hss_db_api process would spawn mnesia_worker process. hss_db_api process
interacts with the eldap_managerprocess to get the eldap_worker process to make LDAP queries. This would result
in high number of concurrent processes performing dynamic data operations on the Mnesia tables and static data
operation via LDAP for each of the procedure worker requests (refer to [28] for more information on the eLDAP
worker process management). After necessary procedural logic execution, an answer message would then be sent by
the corresponding Diameter call-back module process. Detailed sequence diagrams for each of the Diameter message
can be found in Appendix A. The sequence diagrams in Appendix A reflects the data access requirements for each
of the Diameter message without the notion of caching data from Mnesia or LDAP in the gen_server state. The
sequence diagrams for each of the diameter message shows explicitly the number of database look-ups required.
operator_interface module as shown in figure 3.5 is provided to perform administrative tasks on behalf of the
operator. The operator can perform subscriber management operations such as network initiated termination of
registration and updating subscriber data over the Diameter Cx interface. Other operator tasks such as handling
Mnesia configuration manager are performed. The details about the operator interface in more detail can be found in
section 3.9.5.
hss_db module consists of hss_db_api process which invokes a LDAP query for static subscriber data or a Mnesia
query for dynamic subscriber data. A Mnesia query would be passed to a Mnesia worker and it would on successful
update notify the hss_subscription_manager. A LDAP query would be passed to the eLDAP manager and the
result would be passed back. More details about the API can be found in Section 3.10.3. Process design pattern for
hss_db_api is gen_server.
hss_subscription_manager module is responsible for handling the update user-data/user-state by Cx and Sh interface
workers. hss_subscription_manager determines if an update of user data or user state for subscribed transparent
or non-transparent should trigger the notification procedures described in 3GPP TS 29.328. [13] More details about
exact handling of subscription and notification for non-transparent data is described in Section 3.9.4.

3.5.1 Supervision

Erlang/OTP provides supervisor behaviour, which is basically used in this thesis work to restart child/worker processes
based on the configuration for restart-strategies. Supervision provides clean way of restarting applications if the worker
processes under them die.

IMS HSS supervision structure

The IMS HSS supervision structure is shown in figure 3.6. hss_sup supervises the Cx Diameter agent supervisor
(hss_cx_diameter_agent_sup), Sh Diameter agent supervisor (hss_sh_diameter_agent_sup), operator interface
(operator_interface), (mnesia_sup) and the LDAP client supervisor (eldap_sup).
Cx Diameter agent supervisor (hss_cx_diameter_agent_sup) is responsible to handle supervision of the HSS Cx
Diameter server (hss_cx_diameter_server) and the HSS Cx Diameter client (hss_cx_diameter_client).
Sh Diameter agent supervisor (hss_sh_diameter_agent_sup) is responsible to handle supervision of the HSS Sh
Diameter server (hss_sh_diameter_server) and the HSS Sh Diameter client (hss_sh_diameter_client).
operator_interface monitors the eldap_connection_manager and mnesia_configuration_manager.
Mnesia supervisor (mnesia_sup) supervises the mnesia_configuration_manager and the LDAP client supervisor
(eldap_sup) supervises the LDAP client manager (eldap_connection_manager).

33
 Figure 3.6: IMS HSS supervision structure.

IMS I-CSCF supervision structure

IMS I-CSCF supervision structure is shown in figure 3.7a. I-CSCF supervisor (icscf_sup) is responsible for supervision
of the I-CSCF Diameter server (icscf_diameter_server) and the I-CSCF Diameter client (icscf_diameter_client).

IMS S-CSCF supervision structure

IMS S-CSCF supervision structure is shown in figure 3.7b. S-CSCF supervisor (scscf_sup) is responsible for supervi-
sion of the S-CSCF Diameter server (scscf_diameter_server) and the S-CSCF Diameter client (scscf_diameter_client).

IMS AS supervision structure

IMS AS supervision structure is shown in figure 3.7c. AS supervisor (as_sup) is responsible for supervision of the AS
Diameter server (as_diameter_server) and the AS Diameter client (as_diameter_client).

(a) IMS I-CSCF supervision struc-(b) IMS S-CSCF supervision struc- (c) IMS AS supervision structure.
ture. ture.

Figure 3.7: IMS components supervision structure.

3.6 GSM HLR database API

The scope of the GSM diagram as shown in the figure 1.1 , MAP interface components are to be reused as is. The
HLR logic components contain the procedure handling as specified by 3GPP TS 23.012, 23.018 and 29.002 [6, 8, 10].

34
The HLR database API component is implemented as part of the thesis work. The HLR database API has access to
the static data from the LDAP database and dynamic data provided by Mnesia [24]. Please refer to the concurrent
work thesis report [28] for static LDAP database access details. Details about Mnesia table design for GSM can be
found in the section 3.4.
The below table provides an overview of the mapping of the MAP procedures, hlr_db_api calls to the corresponding
eLDAP queries and the dynamic data accessed which were implemented as part of the HLR database API component.

MAP procedure HLR database API Dynamic data eLDAP query

known_subscriber - check_imsi_exists
get_network_access_mode - check_imsi_exists
get_vlr_number roaming_info -
is_subscriber_allowed_roam_plmn - get_gsm_profile
update_routeing_information roaming_info -
update_location
delete_routeing_information roaming_info -
cancel_location
reset_flag_ms_purged subscriber_status -
insert_sub_data
hlr_add_functionality_supported operator_information -
hlr_pga_functionality_supported operator_information -
check_ss_required subscriber_status -
get_hlr_number operator_information -
clear_mnrf subscriber_status -
known_subscriber check_imsi_exists
-
get_imsi_given_msisdn check_msidsn_exists
-
number_changed check_imsi_exists
-
derive_requested_bs check_imsi_exists
-
check_bs_provisioned get_gsm_profile
-
check_ts_provisioned get_gsm_profile
-
is_operator_baic get_gsm_profile
-
is_operator_bic_roam get_gsm_profile
-
is_operator_bic_roamhz get_gsm_profile
send_routeing_information -
is_baic_bs_provisioned get_gsm_profile
provide_roaming_number -
is_roaming_abroad_activated_bs -
ss_profile
is_acr_activated_bs -
ss_profile
is_cfu_bs_active -
ss_profile
increment_number_fowardings -
ss_profile
is_cfnrc_bs_active -
ss_profile
get_gmsc_number -
operator_information
hlr_supports_domain_selection -
operator_information
check_prepaging_supported_hlr -
operator_information
get_roaming_data -
roaming_info
known_subscriber - check_imsi_exists
purge_ms
set_flag_ms_purge_non_gprs subscriber_status -

Table 3.1: GSM HLR database API

3.7 Hardware
To run and evaluate the system, one of the machine was configured as client with the specifications seen in table 3.2
and the other was hosting the HSS/HLR prototype.

Machine CPU RAM HDD space

HSS/HLR server Xeon E5405 2.00 GHz 12 MB 4 GB DDR2 667 MHz 160 GB 7.2 k RPM
Client Core i5-750 2.66 GHz 8 MB 4 GB DDR3 1333 MHz 320 GB 7.2 k RPM

Table 3.2: Hardware specifications.

35
3.8 Software
The client machine had Ubuntu 10.10, Erlang/OTP R15B01 compiled from source with the configuration shown in
Appendix C.
The HSS/HLR machine run Cent OS 5.5 , Erlang/OTP R15B01 compiled from source with the configuration shown
in Appendix C.

3.9 IMS system components

This section covers the IMS system component design. Each of the Diameter agent I-CSCF, S-CSCF interacting over
Cx interface with HSS and AS over Sh interface with the HSS are covered. The interaction among the components
are highlighted in the figure 3.5.
Section 3.9.1 details about the Diameter UAR, LIR message processing by the Cx Diameter server agent
hss_cx_diameter_agent.
Section 3.9.2 details about the Diameter SAR, MAR message processing by the Cx Diameter server agent
hss_cx_diameter_agent.
Section 3.9.3 details about the Diameter PUR, SNR and UDR message processing by the Sh server Diameter agent
hss_sh_diameter_agent.
Section 3.9.4 details about handling of updates on the subscribed data over the Sh interface by the AS. Updates on the
data can be either to the transparent data / non-transparent data by Cx procedures or Sh procedures. Transparent
data here refers to syntactic understanding of the data, but not semantically by the HSS. Non-transparent data is
both understood semantically as well as syntactically [13] by the IMS HSS. hss_subscription_manager triggers the
subscription notifications accordingly, which results in sending PNR Diameter messages to the AS.
Section 3.9.5 describes the operator functionality.

3.9.1 I-CSCF Diameter agent

icscf_diameter_client as shown in the figure 3.5 starts a registered service and establishes a transport layer connec-
tion (TCP or SCTP) with the hss_cx_diameter_server. icscf_diameter_client would send a Diameter command
(such as UAR) to the hss_cx_diameter_server, this interaction over the Diameter Cx interface is highlighted as
shown in the legend. A call-back module hss_cx_diameter_server_cb is spawned for each Diameter message re-
ceived on the Cx interface. The UAR Diameter command is processed by the hss_cx_query_select_pull worker
process. The reply from the hss_cx_diameter_server_cb UAA is sent back to the icscf_diameter_client_cb
module. UAR/UAA interaction is shown in the sequence diagram A.2.
Similarly a LIR diameter message from the I-CSCF is handled by the call-back module hss_cx_diameter_server_cb.
The LIR Diameter message is processed and the LIR procedure is executed by hss_cx_location_query according to
the specifications [11].
LIR/ LIA interaction is shown in the figure A.1, the hss_cx_location_query worker handles the LIR/ LIA Diameter
command.

3.9.2 S-CSCF Diameter agent

The SAR diameter command is sent by scscf_diameter_client and is processed by the hss_cx_put_pull worker
process. The reply from the hss_cx_diameter_server_cb SAA is sent back to the scscf_diameter_client_cb
module. SAR/SAA interaction is shown in figure A.3.
The MAR diameter command is sent by scscf_diameter_client and is processed by the hss_cx_authdatareq worker
process. The reply from the hss_cx_diameter_server_cb MAA is sent back to the scscf_diameter_client_cb
module. MAR/MAA interaction is shown in figure A.4.
The hss_cx_diameter_client worker processes can send PPR Diameter command or RTR commands which are
handled by the scscf_diameter_agent and call-back scscf_diameter_server_cb for each request is spawned. The
replies PPA and RTA are sent by the scscf_diameter_server_cb to the hss_cx_diameter_client_cb. PPR/PPA
sequence diagrams can seen in the figure A.6 and RTR/RTA in the figure A.5

36
3.9.3 AS Diameter agent

The as_diameter_client send Diameter commands over the Sh interface which are handled by the hss_sh_diameter_server
after the initial service start and connection setup.
The UDR Diameter command is sent by as_diameter_client and is processed by the hss_sh_pull worker pro-
cess. The reply from the hss_sh_diameter_server_cb UDA is sent back to the as_diameter_client_cb module.
UDR/UDA interaction is shown figure A.8.
The PUR Diameter command is sent by as_diameter_client and is processed by the hss_sh_update worker process.
The reply from the hss_sh_diameter_server_cb PUA is sent back to the as_diameter_client_cb module. PUR/
PUA interaction is shown in figure A.7.
The SNR Diameter command is sent by as_diameter_client and is processed by the hss_sh_subs_notif worker
process. The reply from the hss_sh_diameter_server_cb SNA is sent back to the as_diameter_client_cb module.
SNR/ SNA interaction is shown in figure A.9.
The hss_sh_diameter_client worker process sends PNR Diameter command which is handled by the as_diameter_agent
Diameter stack and callback as_diameter_server_cb module is spawned each request. PNA is sent by the as_diameter_server_
to the hss_sh_diameter_client_cb. PNR/PNA sequence diagrams is shown in figure A.10.

3.9.4 HSS subscription manager

The hss_nt_data_sub_server registered process in hss_subscription_manager module would upon receiving update
on non-transparent data from the mnesia worker process in hss_db module spawn a hss_subs_handler process. The
hss_subs_handler process would verify if the non-transparent data update subscription is been currently supported
by performing a dirty read on hss_subscription_configuration. If the non-transparent data category subscription
is supported, the hss_subs_handler process would trigger the notification procedure hss_sh_notif worker process
in the hss_sh_diameter_client_workers module.
The hss_sh_update process in hss_sh_diameter_server_workers module triggers the hss_t_data_subs_server
process in the hss_subscription_manager module. The hss_t_data_subs_server process is responsible for trigger-
ing notifications for the subscribed transparent data. hss_sh_notif worker process in the hss_sh_diameter_client_workers
module is spawned to send PNR Diameter message.
Process design pattern for the hss_t_data_sub_server and the hss_nt_data_sub_server is gen_server.

3.9.5 Operator interface

Apart from triggering network initiated terminations RTR/RTA and push profile update PPR /PPA requests the
operator interface is able to manage resources such as the number of eLDAP client connections and the Mnesia
configuration parameters.
mnesia_configuration_manager process has procedures to create schema, initialize Mnesia nodes, create/reset/delete
required dynamic data tables, set operator information for IMS network. The operator information in figure 3.3b.
Process design pattern for mnesia_configuration_manager is a gen_server.

3.10 IMS Interfaces overview

This section provides the overview of the interfaces for the IMS components I-CSCF, S-CSCF, AS and HSS. Each of
the IMS components role can be a Diameter client or a Diameter server. General Diameter agent APIs are discussed
in the section 3.10.1.
Section 3.10.2 provides information about the APIs necessary to support handling of subscription for updated trans-
parent and non-transparent data.
Section 3.10.3 details about the mapping of the required HSS database API onto the static data access API of the
eLDAP and the mnesia data access API.

37
3.10.1 Diameter agent API

• start (ServiceName, ServiceOptions)

Diameter agent either as a client or server can start a service using the diameter:start_service API. This would
result in starting a Diameter service for the client Diameter agent. Service here refers to the locally implemented
peer module, which specifies the Diameter applications (Ex: Diameter Cx Application) it supports and the
capabilities of the peer which are exchanged using the Capabilities-Exchange-Request (CER) / Capabilities-
Exchange-Answer (CEA) [19]. ServiceOptions could be specified as below
[
{ ’ Origin - Host ’ , atom_to_list ( ServiceName ) ++ " . example . com " }
,
{ ’ Origin - Realm ’ , " example . com " } ,
{ ’ Vendor - Id ’ , 10415 } ,
{ ’ Product - Name ’ , " ICSCF Client " } ,
{ ’ Auth - Application - Id ’ , [ ? D IA ME TE R_ APP _I D_ CX ] } ,
{ application , [ { alias , ? APP_ALIAS } ,
{ dictionary , ? DIAMETER_DICT_CX } ,
{ module , ? CALL_BACK_MOD }
]
}
].

application attribute in the option list specifies the Diameter Application supported by the service, a dictionary
module which specified how to encode and decode the application messages and AVPs and call-back module
which handles the incoming the diameter messages for the given Diameter application. Erlang Diameter library
provides diameterc utility which transforms the diameter dictionary files into Erlang source code [20].
capabilities options can be specified using the AVPs, few of the options are included above ’Origin-Host’ - Value
of the Origin-Host ’AVP. ’Origin-Realm’ - Value of the Origin-Realm AVP in the out-going diameter messages.
’Vendor-Id’, ’Product-Name’ and ’Auth-Application-Id’ AVPs are sent as part of the CER / CEA messages.
• connect (ServiceName, TransportProtocolName) or listen(ServiceName, TransportProtocolName)
diameter_add_transport API is called when either a Diameter client or server wants to connect to Diameter
server or the Diameter server wants to listen for the Diameter client messages respectively.
Parameters to the diameter_add_transport API are ServiceName, connect|listen, TransportOptions.
Attribute transport_module takes the TransportProtocolName parameter as value. Local IP address and
Remote IP address, Remote port are specified as shown below in the transport_config attribute.
TransportOptions for listening transport (Diameter server).
[ { transport_module , sctp | tcp } ,
{ transport_config , [ { reuseaddr , true } ,
{ ip , Serve rLocal IPAdd r } ,
{ port , Port } ] } ] ;

TransportOptions for connecting transport (Diameter client).

[ { transport_module , sctp | tcp } ,

{ transport_config , [ { ip , Clie ntLoca lIPAd dr } ,
{ raddr , R emo te Se rv er IP Ad dr } ,
{ rport , RemoteServerPort } ,
{ reuseaddr , true } ] } ] ;

• stop (ServiceName)
Stops the Diameter service.
• call(ServiceName, ApplicationAlias, RequestMessage, CallOptions)
To send a Diameter message, a Diameter agent uses the diameter:call(ServiceName, ApplicationAlias,
RequestMessage, CallOptions) API.
I-CSCF can send UAR, LIR Diameter messages, S-CSCF can send SAR, MAR Diameter messages and HSS as a
Diameter Cx client can send RTR, PPR Diameter messages to the S-CSCF Diameter server and as a Diameter
Sh client can send PNR Diameter message to the AS Diameter server.

38
 Attribute ApplicationAlias is an alias which identifies the Diameter Application in the service configuration
passed while starting the service.
RequestMessage is the Diameter message passed, it consists of list of mandatory AVPs, optional AVPs and
conditional AVPs. List of the AVPs to be passed for Diameter message pertaining to the Diameter Cx application
can be referred here [12] and for Diameter messages pertaining to the Diameter Sh application here [14].
CallOptions can be referred here [19].

3.10.2 HSS subscription handler API

The hss_subs_handler module receives updates on the data, it needs to trigger PNR, is the data updated is subscribed
and the data subscription is allowed by the operator.
Updates on non_transparent data can be received from the Diameter Cx procedures and the transparent data,
non_transparent data updates are received from the Diameter Sh procedures.
update_notification(PublicIdentity, UpdatedData, UpdatedDataType) This API is called when the Diameter
Cx procedure updates data, the mnesia_worker generates cast to the hss_subs_handler module.
Upon receiving the update_notification, verify_supported_subs_data(UpdatedData, PublicIdentity) is called
to verify if the updated data is allowed for subscription. If the updated data is allowed for subscription, initiate_notification(
UpdatedDataType, SubsNotifRecordList, PublicIdentity) is called to notify the list of AS Diameter servers.
notify_transparent_data(PublicId, ServiceIndication) API is called when there is a update on the transparent
data for given the service indication (which identifies the type of service) by the PUR request or in some cases of SNR
requests.

3.10.3 HSS database API

As shown in the figure 3.5, every procedure worker would spawn hss_db_api worker. The hss_db_api makes both
static LDAP queries via the eLDAP component and the dynamic data access through the Mnesia database.
The table 3.3 and 3.4 covers the required Cx/ Sh procedures resulting into the eLDAP queries and Mnesia dynamic
data accesses.

39
Procedure HSS database API Dynamic data eLDAP query
check_public_identity_exists public_identity_exists
-
get_psi_activation_state -
service_registration_info
get_public_id_user_state -
user_registration_info
Cx LIR return_stored_scscf_name -
user_registration_info
get_server_capability_list -
operator_specific_data
terminating_services_related impu_exists
user_registration_info
at least_one_scscf_name_assigned private_identity_exists
private_user_identity_exists - impi_exists
user_identity_match - impi_exists
user_association - impu_exists
impu_barred - impu_exists
Cx UAR non_barred_implicit_impu - impu_exists
user_allowed_roam - impu_exists
user_allowed_register - impu_exists
return_stored_scscf_name user_registration_info -
atlst_impu_scscf_auth_pndng user_registration_info impu_exists
private_identity_exists - impi_exists
impu_exists - impu_exists
psi_exists - psi_exists
identity_association - imp(i)u_exists
is_distinct_impu - impu_exists
psi_activation_state service_registration_info -
return_stored_scscf user_registration_info -
store_scscf user_registration_info -
Cx SAR
set_unregistered_state user_registration_info -
set_registered_state user_registration_info -
associated_impu - impi_exists
impu_state user_registration_info -
set_not_registered_state user_registration_info -
is_hss_storing_scscf operator_specific_data -
download_user_profile - get_ims_profile
clear_scscf_name user_registration_info -
impi_exists - impi_exists
impu_exists - impu_exists
is_distinct_impu - impu_exists
user_association - imp(i)u_exists
Cx MAR get_auth_scheme_supported operator_specific_data -
return_stored_scscf user_registration_info -
get_auth_key_parameters operator_specific_data -
store_scscf_name user_registration_info -
set_auth_pending_flag user_registration_info -

Table 3.3: IMS HSS database API for Cx procedures

40
Procedure HSS database API Dynamic data eLDAP query
check_as_permission as_permission_list -
impu_exists - impu_exists
Sh UDR impi_exists - impi_exists
multiple_impi_association - impi_exists
download_user_data repository -
Sh PNR remove_subs_data sh_subscription_notify_info -
check_as_permission as_permission_list -
impu_exists - impu_exists
Sh PUR impi_exists - impi_exists
is_distinct_impu - impu_exists
is_transparent_data_under_update repository -
check_as_permission
impu_exists
impi_exists as_permission_list -
get_sh_sub_notif_info - impu_exists
Sh SNR verify_service_data_exists - impi_exists
associate_as_notification - impu_exists
associate_as_notification_update repository -
deassociate_as_notification
download_user_data

Table 3.4: IMS HSS database API for Sh procedures

41
Chapter 4

Evaluation and testing

Evaluation of the HSS / HLR prototype and the performance tests conducted for the components and end-to-end
tests is described in this section.
Test framework for the performance evaluation is briefly described in the Section 4.1. Components developed as part
of the prototype, third-party components (Erlsom, Erlang Diameter Base Application) and end-to-end tests can be
conducted using the test framework. Please refer to Section 2.7 about third-party tools used in this thesis work.
Test data required to run the Diameter Cx, Sh procedures, HLR database API are provided by the Identity Server.
This involves conducting performance tests, the subscription data generation is explained in the Section 4.2.
Performance measurements for Erlang Diameter Cx, Sh Application components, end-to-end Diameter tests, end-to-
end RPC tests are covered in the Section 4.4.
The Section 4.5 provides details about the GSM HLR performance for the typical HLR database API calls primarily
mapped onto the eLDAP queries.
Performance analysis of the observed performance for Erlang Diameter applications are analyzed, bottle-necks are
identified in each of the tests. Performance analysis information is covered in the Section 4.6. Advantages and
drawbacks observed for the Erlang Diameter library for the Cx, Sh applications is highlighted.
Capacity requirements to serve 10000 IMS subscribers by a single FE HSS is derived and explained in the section
section:capacity.
Scalability of the FE HSS which is integrated with a BE node is noted in the Section 4.8. FE HSS scalability discussions
refer to the concurrent thesis work, to learn about the BE performance in terms of throughput, memory usage and
the number of subscribers handled [28]. Scalability of the system is discussed by extrapolating the numbers for 50000
IMS subscribers served using the FE HSS cluster and BE node in the Section 4.8.
Section 4.9 carries out discussion about the load balancing mechanisms which can be deployed when a FE HSS cluster
along with BE nodes is deployed.

4.1 Test Framework

The test framework to test the components of the FE HSS /HLR is shown in figure 4.1. This topology is used to
do most of the performance testing of the FE HSS and BE LDAP [28]. The Identity Server is run on the same
machine as the Basho-bench client. Hardware configuration can be referred for the Basho-bench client and the
FE HLR/HSS server in the Section 3.7.
The Identity Server basically provides random pair of IMPU and IMPI or only random IMPU from a Mnesia database
which contains the same identities as stored in the BE LDAP backed Berkley Database (BDB). The performance of
the Identity Server is as observed in the table 4.1. Latency and the throughput observed was sufficiently higher than
the requirements to run the FE HSS /HLR component and end-to-end tests. As result the Identity Server was not
affecting the test runs run by the Basho-bench client on the same machine.

42
 Mean
Throughput
Host Workers Rate latency
(ops/sec)
(ms)
Basho-bench client 250 100 17800 1.2
Basho-bench client 500 500 40270 6
Basho-bench client 500 Max 41800 8

Table 4.1: Identity server performance.

Any of the developed FE components can be run on FE HLR/HSS machine, examples are the Diameter components,
the complete HSS, the hlr_db_api part of the HLR. The topology allows drivers to be created and run at Basho-bench
client to test any code running at FE HLR/HSS. Example basho-bench driver and configuration can be found in the
Appendix B. The Basho-bench client machine can run I-CSCF, S-CSCF or AS and FE HLR/HSS machine can run
the HSS node to perform end-to-end tests.
The OpenLDAP server backed by the BDB is run on the BE OpenLDAP machine. The BE OpenLDAP machine is
run in non-replication, non-mirror mode for the evaluation of the FE HSS/HLR.

Identity Mnesia
Server (RAM)

Mnesia
Basho bench client FE HLR/HSS BE OpenLDAP BDB
(RAM)

Figure 4.1: Test framework

4.2 Test data

Test data for the FE HSS / HLR performance tests were generated by populating the static subscriber database for
10000 subscribers. The same identity-set as in the static subscriber LDAP database was replicated into a in-memory
Mnesia database handled by the Identity Server. The subscriber data as depicted in the figure 3.1 consisted of both
IMS and GSM subscribers.
An IMS subscriber had 2 distinct IMPIs and 4 IMPUs. This resulted in generation of 8 distinct identity associations.
For 10000 subscribers, 80000 identities were generated for IMS. GSM subscriber has an IMSI and a MSISDN. This
resulted in 20000 identities for 10000 GSM subscribers.
Identity Server served these unique identities for both GSM and IMS. The Identity Server was run on the Client
machine (please refer to the client machine hardware configuration in the table 3.2). RPC call to the Identity Server
by the Basho-bench client (please refer to the figure 4.1) resulted in random retrieval of identit(y)ies / identity-pairs
which were used as parameters to the IMS Diameter Cx and Sh applications and GSM HLR database API testing.
The test-data in the LDAP static subscriber database was configured to test most of the subscription related parameters
pertaining to each of the procedures.
The Identity Server performance (refer 4.1) was sufficient to conduct performance tests of both IMS procedures
and GSM HLR database API. Even though Identity Server was run on the same machine as the client machine
(which executed Basho-bench tests) the performance of the Identity Server was not an hindrance to conduct any of
performance tests at the required rate as the performance of the Identity Server to fetch the random identities was
very high as compared to the maximum number of operations/sec expected for each of the test runs.

43
4.3 Test scenarios
Performance testing and evaluation are conducted for the below mentioned scenarios.

• IMS HSS
– Erlang Diameter library - Diameter Cx, Sh applications
– End-to-end via Diameter over TCP
– End-to-end via RPC
• GSM HLR database API

4.4 Performance measurements

This chapter contains performance measurements for Erlang Diameter library component and end-to-end scenarios.
The results are analyzed in the Section 4.6.
The tables in the following sections shows performance measured by the metrics listed below.

Throughput is the observed numbers of operations executed per second.

Mean latency is the mean latency in milliseconds observed between a request and reply for the test duration.

CPU utilization is observed by running the top command. The measurements are in percentage and the values are
for the 4 core machines (please refer to hardware specifications in the table 3.2).
Memory utilization is measured by the use of the top tool and is the percentage of system memory used by the
tested application at given host.

Operations/sec is the desired (expected) number of operations per second configured for each of the Basho-bench
tests (number_of _concurrent_workers × rate).
Scheduler utilization is measured by Observer and shows wall time per scheduler.[25, 22]. Utilization is measured
by percentage and number of schedulers in use. Erlang uses one scheduler per physical core.

4.4.1 Diameter

Diameter over TCP transport

Diameter tests with results as tabulated in table 4.2 were run between the I-CSCF client , S-CSCF client over Cx
interface and HSS, AS over Sh interface and HSS. TCP was used as the transport protocol to send the diameter
application messages between the Diameter clients and Diameter server.
Diameter client (I-CSCF or S-CSCF or AS) as depicted in the figure 4.1 uses the Identity Server to obtain the required
identities (IMPU or/and IMPI) and the FE HSS serves as the Diameter server. The Basho-bench client runs both the
Identity Server and the Diameter client requests. The replies to each of the Diameter message are returned by the
stubbed Diameter replies by the FE HSS. This results in performance testing of the Erlang Diameter library provided
as part of the R15B release. Diameter Cx procedures UAR, LIR, MAR, SAR and Sh procedures UDR, SNR and PUR
performance results will be analyzed in the Section 4.6.1.

44
 FE HSS
Memory Scheduler
Interface Operations Throughput Latency CPU
utilization utilization
/ Procedure /sec (ops/sec) (ms) utilization
(%) % (cores)
(%)
Cx/UAR 500 500 1 65 1 10-12 (1 core)
1000 910 5 96.5 1 18-20 (1 core)
2000 1000 95 100 1 25-30 (1 core)
3000 1000 195 99.5 1 20-25 (1 core)

Cx/LIR 500 500 1 50 1 10-12 (1 core)

1000 910 5 97 1 18-20 (1 core)
2000 1100 85 99.5 1 15-25 (1 core)
3000 1050 190 100.6 1 18-25 (1 core)

Cx/SAR 500 500 1 68 1 10-12 (1 core)

1000 890 12 99 0.9 18-20 (1 core)
2000 880 130 99.6 1 18-20 (1 core)
3000 890 245 100 1 18-20 (1 core)

Cx/MAR 500 500 1 55 1 10-12 (1 core)

1000 900 15 100 1 18-22 (1 core)
2000 900 130 100 1 18-22 (1 core)
3000 890 245 100.5 1 18-20 (1 core)

Sh/PUR 500 500 3 58 0.9 10-12 (1 core)

1000 650 50 82 0.9 15 (1 core)
2000 650 200 80 0.9 15 (1 core)
3000 650 350 83 1 15 (1 core)

Sh/UDR 500 500 2 52 1 10-12 (1 core)

1000 900 10 100 1 15-20 (1 core)
2000 910 110 100 1 15-20 (1 core)
3000 900 235 98 1 15-20 (1 core)

Sh/SNR 500 500 2.25 65 1 10-12 (1 core)

1000 890 12 100 1 15-20 (1 core)
2000 890 125 99.6 1 15-20 (1 core)
3000 810 250 100 1 15-20 (1 core)

Table 4.2: Diameter performance results over TCP transport.

Diameter over SCTP transport

Diameter over SCTP performance is tabulated as shown in the table 4.3. Same test-setup as used for running diameter
over TCP was used to run Diameter over SCTP. Diameter over SCTP performance results are analyzed in the Section
4.6.1.

45
 FE HSS
Memory Scheduler
Interface Operations Throughput Latency CPU
utilization utilization
/ Procedure /sec (ops/sec) (ms) utilization
(%) % (cores)
(%)
Cx/UAR 500 490 2 54 1 10-12 (1 core)
1000 810 15 85 1 15-20 (1 core)
2000 810 130 82 1 15-20 (1 core)
3000 810 260 82 1 15-20 (1 core)

Cx/LIR 500 495 2 54 1 10-12 (1 core)

1000 825 15 84 1 15-20 (1 core)
2000 825 130 85 1 15-20 (1 core)
3000 825 255 85 1 15-20 (1 core)

Cx/SAR 500 490 2 54 1 10-12 (1 core)

1000 810 18 85 0.9 15-20 (1 core)
2000 810 18 85 0.9 15-20 (1 core)
3000 810 260 85 1 15-20 (1 core)

Cx/MAR 500 490 1 54 0.9 10-12 (1 core)

1000 810 20 85 0.9 15-20 (1 core)
2000 810 140 85 0.9 15-20 (1 core)
3000 810 260 85 1 15-20 (1 core)

Sh/PUR 500 490 2 54 1 10-12 (1 core)

1000 810 55 85 1 15-20 (1 core)
2000 810 210 85 1 15-20 (1 core)
3000 810 360 86 1 15-20 (1 core)

Sh/UDR 500 490 2 54 1 10-12 (1 core)

1000 810 18 85 1 15-20 (1 core)
2000 810 130 85 1 15-20 (1 core)
3000 810 260 86 1 15-20 (1 core)

Sh/SNR 500 490 2 54 1 10-12 (1 core)

1000 810 20 85 0.9 15-20 (1 core)
2000 810 140 85 1 15-20 (1 core)
3000 810 260 86 1 15-20 (1 core)

Table 4.3: Diameter performance results over SCTP transport.

4.4.2 End-to-end Diameter

End-to-end diameter results are formulated in the table 4.4. End-to-end Diameter performance test involves the
Basho-bench clients (I-CSCF, S-CSCF and AS) as Diameter clients which make Diameter calls to the Diameter server
FE HSS over TCP transport. FE HSS serves the Diameter requests by invoking the required call-backs which results
in the execution of the corresponding Cx/Sh procedure call. FE HSS machine (please refer to the topology figure
4.1) hosts the procedure workers, operator, maintenance functionality, HSS database API(both eLDAP components
and Mnesia operation handling) as described in the IMS system architecture (please refer to the IMS HSS system
architecture figure 3.5).
FE memory utilization and FE CPU utilization is due to the Cx/Sh procedure execution, HSS database API handling
(eLDAP workers, managers and mnesia in memory database) and Erlsom for transforming Erlang records into required
XML strings as specified by the schema. Scheduler utilization is as observed by the observer tool for the FE HSS
Erlang node.
BE CPU utilization is due to the slapd serving the LDAP requests.
Performance results for end-to-end diameter results are analyzed in the Section 4.6.2.

46
 Mean FE Memory FE CPU BE CPU Scheduler
Ops Throughput
Procedure Latency utilization utilization utilization utilization
/sec (ops/sec)
(ms) (MB) (%) (%) % (cores)
Cx/UAR 500 325 52 665 185 10 20-25 (2 cores)
1000 325 210 652 185 10 20-25 (2 cores)
2000 325 510 635 183 10 20-25 (2 cores)

Cx/LIR 500 425 45 651 195 7 20-25 (2 cores)

1000 425 135 649 190 8 20-25 (2 cores)
2000 425 370 651 185 8 20-25 (2 cores)

Cx/SAR 500 200 236 705 184.1 10 30-38 (2 cores)

1000 200 570 705 186.1 10 30-38 (2 cores)
2000 200 1250 705 185.9 10 30-38 (2 cores)

Cx/MAR 500 185 155 668 180 6 30-35 (2 cores)

1000 190 410 670 182 5 30-35 (2 cores)
2000 180 930 654 180 5 30-35 (2 cores)

Sh/PUR 500 275 75 360 190 10 20-25 (2 cores)

1000 275 250 340 195 10 20-25 (2 cores)
2000 275 590 368 190 10 20-25 (2 cores)

Sh/UDR 500 310 60 428 205 10 25-30 (2 cores)

1000 310 220 422 208 10 25-30 (2 cores)
2000 310 550 411 200 10 25-30 (2 cores)

Sh/SNR 500 300 70 526 216 9 25- 30 (2 cores)

1000 290 250 540 220 8 25- 30 (2 cores)
2000 280 610 567 217 8 25- 30 (2 cores)

Table 4.4: End-to-end Diameter performance results.

4.4.3 End-to-end RPC

End-to-end RPC performance is tabulated below. RPC tests are performed to by-pass the diameter stack.
RPC calls are made by the Diameter clients such as I-CSCF, S-CSCF and AS to the Cx and Sh procedures hosted
by the FE HSS. Diameter protocol is not used by the Diameter clients to communicate with FE HSS instead the
RPC calls result in direct invocation of the corresponding procedures. Static data is served by the BE LDAP and the
dynamic data is served by the Mnesia.
FE memory utilization and FE CPU utilization is due to the procedure code execution, HSS database API and Mnesia
operations performed. Scheduler utilization is as observed by the observer tool for FE HSS Erlang node.

BE CPU utilization is due to slapd serving the LDAP requests.

Performance metrics observed is for the end-to-end operations performed when the basho client (I-CSCF , S-CSCF
and AS) invokes (via RPC) the Cx/Sh interface procedure call in the FE HSS. Identity Server provides the identities
required for the Cx/Sh procedures as depicted earlier in the figure 4.1.
Performance of the end-to-end RPC testing is analyzed in the Section 4.6.3.

47
 Mean FE Memory FE CPU BE CPU Scheduler
Ops Throughput
Procedure Latency utilization utilization utilization utilization
/sec (ops/sec)
(ms) (MB) (%) (%) % (cores)
Cx/UAR 500 480 2.5 700 220 15 15-20 (4 cores)
1000 880 3 687 340 30 35-40 (4 cores)
2000 1821 5 675 390 59 85-90 (4 cores)

Cx/LIR 500 500 2.2 692 190 7 10-15 (4 cores)

1000 980 2.2 718 265 22 35-30 (4 cores)
2000 1884 3 717 362 33 65-70 (4 cores)

Cx/SAR 500 480 4 782 357 25 60-65 (4 cores)

1000 675 45 792 399 40 100 (4 cores)
2000 600 240 808 399 37 100 (4 cores)

Cx/MAR 500 475 3 370 315 15 45-50 (4 cores)

1000 850 10 529 393 26 85-90 (4 cores)
2000 850 130 654 398 27 100 (4 cores)

Sh/PUR 500 495 3.3 370 75 15 25-30 (4 cores)

1000 944 3.8 450 150 25 45-50 (4 cores)
2000 1767 11 565 192 50 85-90 (4 cores)

Sh/UDR 500 459 3.1 560 38 15 25-30 (4 cores)

1000 960 3.4 492 65 26 45-50 (4 cores)
2000 1780 9 516 87 52 90-95 (4 cores)

Sh/SNR 500 500 3 563 37 16 25-30 (4 cores)

1000 965 3.45 684 65 24 55-60 (4 cores)
2000 1750 12.5 727 85 50 95-100 (4 cores)

Table 4.5: End-to-end RPC performance results.

4.5 GSM HLR database API

The GSM HLR database API performance results for 1600 operations/sec are tabulated. The known_subscriber API
is basically check_imsi_exists call, get_imsi_given_msisdn call results in the call check_msisdn_exists and the
check_bs_provisioned results in the call for get_gsm_profile. Most of the APIs in the HLR database API were
conducted for similar eLDAP calls (please refer to the table 3.1 for HLR database API mapping) . (More information
on performance of eLDAP calls for GSM API can be found in the concurrent thesis work report [28]).

FE HLR FE HLR BE FE HLR

Mean
Ops Throughput memory CPU CPU scheduler
API latency
/sec (ops/sec) utilization utilization utilization utilization
(ms)
(MB) (%) (%) % , (cores)
known_subscriber 1600 1480 0.8 91 62.5 5 20, (2 cores)
get_imsi_given_msisdn 1600 1480 0.7 91 62.5 5 20, (2 cores)
check_bs_provisioned 1600 1440 0.8 207 50 5 25, (2 cores )

Table 4.6: GSM HLR database API performance results.

The results show that throughput of more than 1400 ops/sec with less than 1 milli-second latency for the HLR database
API for 1600 ops/sec. Higher memory usage observed for the check_bs_provisioned API as compared to the other
two API calls tabulated is due to larger GSM profile results.

48
4.6 Performance analysis
The analysis of the performance results (please refer section 4.4 for measurements information) for Erlang Diameter
library, End-to-end Diameter performance, End-to-end RPC performance in the IMS domain and the GSM HLR
database API component are presented in this section.
Performance analysis of the Diameter Cx and Sh applications are presented in the Section 4.6.1. This section provides
performance analysis of Erlang Diameter Cx and Sh applications tested over TCP and SCTP as transports. These
performance tests are conducted with stub Diameter Cx and Sh procedure request/response messages to evaluate the
performance of Diameter protocol stack in isolation.
Section 4.6.2 provides performance analysis of the end-to-end Diameter tests results of the Section 4.4.2.
End-to-end RPC performance analysis of the results in the Section 4.4.3 is done in the Section 4.6.3.

4.6.1 Diameter

Figure 4.2: Diameter Cx TCP performance analysis

Figure 4.3: Diameter Sh TCP performance analysis

The results from the table 4.2 can be visualized in the figures 4.2 and 4.3
Observation in the figure 4.2 and 4.3 for TCP as transport protocol shows that for any given diameter Cx /Sh procedure
call on the FE HSS machine results in

• Throughput throttling when more than 1000 operations/sec are requested. This observation provides an hint
that the single diameter_watchdog process which handles every diameter incoming message as the bottle-neck
process. Pin-pointing the bottle-neck process in the diameter stack however needs more investigation.

49
 • Latency increases due to the inefficient incoming message handling by the diameter_watchdog process at more
than 1000 operations/sec. This results in Diameter stack virtually unusable even in moderate loads of more than
1000 operations/sec.
• CPU utilization increases when there is an increase of number of operations from 500 to 1000. Throughput
increase also reflects in the increase of CPU utilization from 500 to 1000. After 1000 operations/sec there is no
increase in CPU utilization as the bottle-neck is in handling of incoming diameter messages.
• Memory utilization is not high in the FE HSS Erlang node as there is no state stored for any of the procedures
and stub diameter messages replied over the Diameter Cx/Sh interface. No database API‘s are used since stub
diameter messages are returned as the aim is to conduct performance test of the diameter protocol stack.
• Scheduler utilization is low and one of the four scheduler threads are utilized in low percentages.

Figure 4.4: Diameter Cx SCTP performance analysis

Figure 4.5: Diameter Sh SCTP performance analysis

Diameter SCTP performance results can be observed in the table 4.3. The same performance results can be visualized
in the figure 4.4 and 4.5 for Diameter Cx and Diameter Sh procedures respectively.
Socket options for SCTP had to be tweaked to get better SCTP performance. In the diameter_sctp module, following
options were modified

• {active, once} caused performance problems , when the {active, once} (to receive one SCTP packet at a
time and this option requires re-setting the option every time a packet is received) was changed to {active,
true} to actively receive packets which are received at the port. More investigation into {active, once} as
SCTP socket option causing problems should be done while TCP does not have performance problems with
respect to {active, once} as socket option.
• {recbuf, integer() > 0} is by default 1500 bytes, receiving default window size was not enough to sustain
higher number of operations/sec. When the option was tweaked to {recbuf, 65536} was able to provide the
required receiver kernel socket buffer size for SCTP.

50
 • sctp_nodelay was set to true , this option results in low throughput but not at the cost of increased latency.
The default setting was false which caused the client queries to time-out in order to aggregate more data chunks
into a single packet (to get more throughput). More information about the sctp_nodelay option can be found
here [23].

As observed from the tables 4.2 and 4.3, the latencies when SCTP is used as transport are slightly higher and
throughput is slightly lower with SCTP socket options tweaked as mentioned above. Lower performance of SCTP as
transport layer for the same diameter messages can be attributed due to the overhead incurred by SCTP in framing
messages. Further performance analysis of SCTP as transport needs to be done to draw concrete conclusions.
The performance analysis of the diameter stack over TCP and SCTP as transport indicates a bottle-neck in the
diameter stack which needs investigation and performance enhancement if the HSS were to handle moderate and high
load over 1000 operations/sec.

Advantages

• Provides utilities to for encoding and decoding of AVP. diameterc utility is helpful for transforming the dictionary
files into Erlang source code [20].
• Has support for SCTP and TCP transport protocols.
• Developing RFC complaint and specification complaint Diameter applications is made easy as pretty neat inter-
faces to the peer modules, handling of connections and services are provided.

Drawbacks

• As discussed in this section, Erlang Diameter version 1.1 library released as part of R15B has issues with respect
to handling high number of concurrent requests (more than 1000 operations/sec).
• Few issues were observed when using the add_transport API [21]. When the SCTP transport protocol was not
configured as part of Erlang installation, the add_transport API returned {ok, <reference>} successfully.
This error scenario can be better handled with standard {error, eprotonosupport} message.

4.6.2 End-to-end diameter

Figure 4.6: End-to-end Diameter Cx over TCP performance analysis

51
 Figure 4.7: End-to-end Diameter Sh over TCP performance analysis

The table 4.4 results in the following inference and the same can be visualized in the graphs 4.6 and 4.7.

• Throughput remains in no-increase pattern as the the number of operations per sec increases. This is due to the
Erlang Diameter stack performance issues as indicated in the Section 4.6.1. Diameter protocol is the bottle-neck
when end-to-end performance tests using Diameter are conducted. High CPU intensive Diameter calls such as
SAR, MAR (have more processing and hence introduce more delay) have low throughput when compared to the
other light-weight procedures such as LIR which neither have Erlsom operations nor the authentication vector
generation operation.
• Mean latency increase is observed mainly due to throttling in the diameter stack as the number of concurrent
worker operations/sec increase. As seen latency is high for CPU intensive operations (SAR, MAR in relative
with LIR. Similarly CPU intensive operations such as SNR, UDR and PUR have similar mean latency.
• Memory utilization is high for the procedures such as SAR as they need more than one dynamic data records,
more than two BE LDAP calls and Erlsom operations to write a Diameter Cx profile XML string. This is
evident by observing SAR operation at 500 operations/sec and PUR at 500 operations/sec (which has no Erlsom
operations and have few BE LDAP calls). UAR, LIR even with no Erlsom operations have dynamic records to
be read and initialized in some cases, have high memory utilization and few BE LDAP calls.
• FE CPU utilization and Scheduler utilization cannot be analyzed further as the bottle-neck in diameter does
not allow high number of concurrent diameter requests to be made and processed. Scheduler utilization though
shows an increase in the number of cores used by one when compared to diameter performance test alone due
to other CPU operations and the other scheduler thread is busy.
• BE CPU utilization is not high as there are no high concurrent requests made due to the bottle-neck in diameter
stack.

4.6.3 End-to-end RPC

The table 4.5 provides the following inference and can be seen in the graphs 4.8 and 4.9.

Figure 4.8: End-to-end RPC Diameter Cx performance analysis

52
 Figure 4.9: End-to-end RPC Diameter Sh performance analysis

• Throughput increases linearly for procedures such as Diameter Cx/UAR, Diameter Cx/LIR as these procedures
have low CPU demands, reason being no XML string generation required in order to process these queries by
the HSS.
Sh/PUR, Sh/UDR and Sh/SNR have low Erlsom requirements and have high throughput as the number of
operations/sec requirement grows.
As discussed before in the Section 2.7.2 Erlsom uses considerable amount of CPU as the number of operations/sec
requirement grows for XML string generation. Procedures such as Cx/SAR have high requirements of Erlsom
as they need a complete Cx user profile to be parsed into the XML adhering to the schema specified [11].
This results in high CPU usage and hence these procedures when placed with high requirement of number of
operations/sec are bottle-necked by the CPU available.
In case of MAR procedure the high CPU utilization is due to authentication vectors generated. MAR is throttled
for CPU as shown in the table, the throughput does not increase after requests of more than 1000 MAR
operations/sec are requested.
• Mean latency as observed for procedures with high CPU utilization when bottle-necked for CPU results in
higher latencies , for example Diameter Cx SAR. High CPU utilization in case of MAR is due to quintuplet
authentication vector generation every time a Diameter MAR request is made as mandated by the specification
[16]. Procedures which are not throttled due to CPU constraints don’t have high latencies.
• FE memory utilization remains high for procedures which initialize the records user_registration_info,
service_registration_info, repository and use them in procedure execution.
The increase in memory utilization initially can be seen for PUR request as it initialize more repository records
with increase in high number of operations /sec.
The procedure SNR has to read subscription_notification_info and retrieve data from repository which
explains high memory usage with steady increase in the number of SNR operations/sec.
• FE CPU utilization increases as explained before, for Erlsom and authentication vector operations. These CPU
intensive operations at high number of operations/sec request result in throttling and hence almost utilizing the
CPU entirely as in case of SAR, MAR even for 1000 operations/sec request.
• BE CPU utilization increases when there is requirement for more number of LDAP requests per procedure
execution. This is seen in case of SAR at 1000 operations/sec. UAR , UDR procedures which is not constrained
by CPU places steady increase of load on the LDAP BE with increase in number of operations/sec.
• Scheduler utilization increases with increase in the number of operations/sec. All the scheduler threads are
utilized to the maximum in case of the SAR procedure even at 1000 operation/sec and in cases of SNR, UDR
at 2000 operations/sec as these procedures are less CPU intensive.

4.7 Capacity
The section covers the capacity of the HLR/HSS in terms of RAM requirements in order to the serve the Diameter
Cx LIR.
To serve dynamic data for procedures, Mnesia in-memory database was used. Mnesia in-memory database served the
procedural data required for both Diameter Cx, Sh interfaces and MAP protocols.
The following records were mainly used for Diameter Cx and Sh procedures:

53
 • Each entry in user_registration_info table requires 3040 bytes. To serve a single public identity 3040 bytes
are needed which can be used by the Cx and Sh procedures. To serve 80000 users 232 MB of memory.
• Each entry in repository table requires 1450 bytes of memory. To serve a single public identity which has single
repository data item which can be subscribed(SNR), read(UDR) and updated (PUR). With this assumption to
serve Sh procedures with repository data for 80000 users 110.7 MB memory.
• Each entry in sh_subscription_notify_info table requires 2896 bytes. To serve a single public identity which
needs to subscribe to the repository data requires 2896 bytes. For serving 80000 users which subscribe to single
repository data item 221 megabyte (MB) memory.
• operator_specific_data requires 76 kB of memory.

The data for each entry in the respective mnesia tables were obtained by running the end-to-end RPC tests for 80000
distinct identities. Please refer to the Section 4.4.3 for more information on end-to-end RPC tests.
The total amount of RAM needed includes Mnesia table space, memory to run the Cx/ Sh procedures, HSS database
API (eldap workers) and Erlsom parsing memory needs.
As seen in the table 4.5 memory requirements for LIR procedure requires nearly 700 MB of memory for 80000 distinct
identities. The FE memory utilization as provided by the observer tool includes Virtual Machine (VM) memory
usage, procedural memory, eLDAP manager/worker processes and Mnesia in-memory database.
Discussion above about the memory requirements about Mnesia table user_registration_info is 232 MB for 80000
users. Number of eLDAP workers run were 640 eLDAP worker processes (16 eLDAP managers * 40 workers managed
by each eLDAP manager). Memory requirement for running 640 eLDAP workers which would be sufficient to serve
the LIR 2000 operations/sec is 262 MB. More information about the memory requirement of the eLDAP can be found
in the concurrent thesis report [28].
The procedure execution at the rate of 2900 operations/sec along with Erlang VM) requires 206 MB ((700MB - 262MB
(eldap_worker_memory) - 232MB (user_registration_info mnesia table)).
As observed in the Section 4.2, 8 distinct identity associations per subscriber is the test data. 80000 distinct identities
served here correspond to 10000 IMS subscribers. To server 10000 subscribers, at the rate of 2900 LIR operations/sec
with given identity configuration mentioned, FE needs 700 MB of RAM.

4.8 Scalability
As discussed in the Section 4.7 a FE IMS HSS serving LIR can be depicted as a block shown below. LIR is chosen
procedure since the number of LDAP BE query is a trivial one to one mapping.

Figure 4.10: IMS HSS FE LIR block.

A LIR operation with a public user identity request would require one eLDAP query (check_public_user_identity_exists
per procedure execution. (refer to hss_db_api to eLDAP query mapping for each of the Cx and Sh procedures in the
table 3.3).
The BE LDAP throughput, memory and capacity aspects as shown in the figure 4.11 are covered in detail as part of
the concurrent thesis work [28].

Figure 4.11: IMS HSS BE block.

54
With FE block and BE block as depicted above, a single BE can serve 11 FE blocks as shown in the figure 4.12.
The BE can provide 33590 ops/sec for 50000 subscribers with the same throughput performance for the BE block
shown in the figure 4.11.
Each FE block as shown in the figure 4.10 has RAM memory enough to support the 50000 distinct IMS subscribers.
To fully utilize the BE throughput of 33590 ops/sec 11 FE blocks (each with 2900 ops/sec) can serve 50000 IMS
subscribers.
With given hardware configurations of FE and BE system (without replication in fully-cached mode) can serve 50000
IMS subscribers.
To serve 10000 IMS subscribers, as discussed in the Section 4.7, 232 MB of memory is needed for storing the
user_registration_info Mnesia table, for 50000 IMS subscribers 1160 MB of memory for Mnesia table is needed
and the 640 eLDAP workers would be sufficient while the procedure memory would not increase as the FE HSS is
bound by high CPU utilization (please refer to the table 4.5 for observing end-to-end RPC performance). Therefore
the memory requirements to serve 50000 IMS subscribers LIR requests at the rate of 2900 ops/sec would be sum
of 1160 MB (Mnesia table user_registration_info) 206MB of procedure worker memory and 262 MB memory
requirement for eLDAP, resulting in a total of near 1628 MB.

Figure 4.12: FE scalability

4.9 Load balancing

In order to provide load balancing feature among the available FE HSS nodes, it is necessary to identify the mechanism
through which a FE HSS module can be identified to serve a given subscription request. One such mechanism is load
balancing through a subscription analyzer function which can be deployed as shown in the figure 4.13.

55
 Figure 4.13: Load balancing:subscription location analyzer

The subscription location analyzer acts as primary interface to the I-CSCF, S-CSCF and AS over Diameter Cx and
Diameter Sh interfaces respectively. Any diameter request originating from these components would be first consumed
by the subscription location analyzer, based on the domain name component of the request originating, the FE HSS
node would be identified. This requires analyzing the Diameter requests, which means application layer packet analysis
to re-direct the request to the appropriate FE HSS node.

The advantages of the using subscription location mechanism to load balance the available FE HSS would be based on
the traffic analysis, redundant nodes to serve a particular domain can be added. The number of available unique nodes
will depend on the number of domains (location) supported by the given HSS. The number of redundant nodes for a
given FE HSS node would depend on the traffic and the capabilities of the FE HSS node. With load-balancing shown
above, with a single node as stand-by for each of the given FE HSS node, a total of 2×N nodes would be required for
N FE HSS nodes for minimum fault tolerance.
The de-merits of this approach would be a subscription location analyzer, which would require high CPU utilization as
the Diameter messages need to be analyzed at the application layer to obtain the domain information and subsequent
routing of the diameter packet to the respective FE HSS node. Though redundant nodes for subscription analyzer
minimizes CPU utilization on given node, this would not be low-cost solution.
One another mechanism is IP based load balancing, where the packet can be re-directed based on the IP sub-net. This
is one of the common methods used to load balance.

56
Chapter 5

Conclusion

This chapter concludes by providing summary of the thesis work done and future enhancements identified in-order to
make prototype a deploy-able product.
Section 5.1 summarizes the features developed in-order to meet the objectives of the thesis work.
Issues identified in components, testing scenarios, third-party tools and the prototype are identified as future enhance-
ments. Nice-to-have features in the third-party tools which would enhance usability or performance of the tools have
been identified and noted in the Section 5.2.

5.1 Summary
Following objectives of the thesis were met:

• Provide HSS Front-end (FE) server for a common HLR / HSS.

• Evaluate real-time characteristics of the prototype.

• Suggest improvements for components, third-party tools used and the prototype.

In meeting the objectives of the thesis, the prototype designed and developed serves as proof-of-concept for the following
features

• Specification compliance
The developed IMS HSS prototype provides implementation of the procedures of Diameter Cx interface namely
the UAR, LIR, SAR and MAR. With the implementation of these procedures, location management, user-data
management and authentication can be handled by the IMS HSS. The I-CSCF can make location related queries,
S-CSCF can perform user-data management related queries, authentication queries pertaining to the subscriber,
it is currently responsible.
Diameter Sh procedures UDR, PUR, SNR and PNR are implemented. This allows the AS to perform user-
data related queries such as user-data read, updating user-data, subscribing to the user-data updates, receive
if any notifications on the subscriptions to the updated user-data. Specification compliance is the basic step
which ensures operator develop and build on the prototype in-order to transform it into a deploy-able product.
Specification compliance provides all the necessary benefits of adhering to The 3rd Generation Partnership
Project (3GPP).
• Integrated subscription model.
The necessity to avoid duplication of subscriber data is prime importance if the operator has to grow his
subscriber numbers and provide large number of services accessible effectively via different technologies. In this
thesis work, IMS and GSM subscribers were considered, hence the duplication of subscriber data had to be
looked into the HSS and HLR. A consolidated LDAP DIT for both GSM and IMS subscribers was designed
which can be extended for other telecommunication technologies such as General Packet Radio Services (GPRS).
Consolidated LDAP DIT was the basis of the LDAP schema design for the concurrent thesis work. LDAP DIT
designed provides an insight into how subscriber data duplication can be avoided.

58
 Integration of the FE IMS HSS server with the BE LDAP realized the static subscriber data access for the IMS
HSS clients. GSM HLR database API have been provided which used the common BE for static subscriber data
and dynamic data (procedural data) required for both GSM and IMS was served using the Mnesia database.
• Classification of data
Data classification lead to clear division of subscriber data (maintained by the LDAP BE) and procedure data
(maintained by the Mnesia in-memory database). As result LDAP which is highly-proficient with read intensive
requests was confirmed as the database access protocol to be investigated. (please refer to LDAP efficiency in the
concurrent thesis report [28]). Mnesia as in-memory distributed database was used to handle the dynamic data
classified. The dynamic data was partitioned into Erlang records, which were stored as Mnesia table entries.
• Performance analysis
FE performance has been analyzed and bottle-neck components in the third-party components such as Erlang
Diameter library, Erlsom and Basho-bench has been highlighted.
– Erlang Diameter stack performance analysis done was crucial. This highlighted the bottle-neck in perfor-
mance caused. If the prototype has to be developed as deploy-able large-scale product, Diameter message
processing at the rate of 1000 operations/sec is clearly not sufficient. An hint to bottle-neck component of
the Erlang Diameter stack has been provided, which requires further investigation.
– Erlsom usage as XML string generating tool was noted. CPU utilization issues when the concurrent requests
are higher than 2000 operations/sec was identified. An highly-efficient XML generating tool is very much
necessary in-order to provide specification complaint implementation of the procedures. The schema for
XML format of user-data has been specified by the 3GPP.
– Basho-bench as test-tool was investigated. By conducting performance analysis of the Basho-bench with
null driver, this revealed the discrepancies in the results. Yield inconsistency of the Basho-bench needs to
be investigated.
– Performance analysis along with evaluation of real-time characteristics included discussion about capacity
requirements to serve 10000 IMS subscribers. This was realized by conducting performance evaluation of
the prototype for 10000 IMS subscribers.
– Scalability discussion for 50000 IMS subscribers was discussed and evaluated (please refer here for scalability
discussion, Section 4.8). Scalability discussion was based on the capacity requirements to serve 10000 IMS
subscribers by the FE HSS and the BE LDAP performance results.
– Load-balancing features for the prototype can be referred in the Section 4.9, which is one of the primary
requirements when the HLR / HSS product would be deployed to serve in large scale. Subscription location
analyzer and the more common IP layer load-balancing mechanisms were discussed.
Discussions about capacity, scalability and load-balancing features based on the performance analysis of the
prototype provide an insight into realization of the product which can be deployed in the large-scale environment.
• Testing
Basho-bench as test tool served the purpose of conducting performance tests, stress testing. The test-tool as
framework allowed testing each of the components in isolation, end-to-end scenarios were analyzed. Basho-bench
test-drivers were written for testing each of the components, third-party tools and end-to-end scenarios.

5.2 Future work

This section identifies the future work to be carried out, in-order to make the prototype a have the some of the features
of a deploy-able product. Issues highlighted for few of the components, third-party tools and prototype have to be
investigated as part of the future work.

• Erlang Diameter
– Diameter stack needs performance improvement with respect to handling of incoming diameter messages.
diameter_watch_dog process needs to be modified in-order to handle highly concurrent incoming diameter
messages. This is of prime concern if the IMS HSS has to handle more than 1000 operations/sec which is
very basic for deployment of the HSS.
– Issues with Diameter SCTP socket options needs to be looked into (please refer Section 4.6.1 for SCTP socket
issues). SCTP as transport for Diameter messages (Erlang Diameter library) is an important feature of the
Erlang Diameter stack, as SCTP would be preferred transport protocol in telecommunication applications.

59
 – add_transport API needs to convey the correct user message in case the underlying transport requested is
not supported [21]. This would help Diameter application developers considerably in debugging transport
layer related issues.
• Subscriber data generation
Generated subscriber data has been configured for worst case scenarios for both storage and from procedure logic
perspective. Different configuration of subscriber data with respect to identity association needs to be done.
• Integration - Tieto Signaling System 7 (SS7) stack
GSM HLR database API has not been integrated to the HLRprocedure logic and consequently to the MAP
interface of the tieto SS7 stack. This was not done due to time constraints of the thesis period.
• More performance testing
Scaling and load-balancing aspects as discussed in the Section 4.8 and Section 4.9 respectively have been proposal
observed based on single FE HSS node performance.
In-order to deploy the product, features such as scalability, resilience and load-balancing have to be tested by
conducting horizontal and vertical scaling of resources. Proposed Subscription location analyzer functionality for
load-balancing has to be developed and performance tests for the subscription location analyzer module needs
to be conducted. Performance due to scaling of resources, testing resilience of the system and load-balancing are
vital in-order to transform prototype into a deploy-able product.
• Concurrent mixed procedure testing
Concurrent mixed ratio of procedure requests from a single HSS client such as I-CSCF or an AS has been done.
However, testing of the HSS with mixed ratios of the Diameter Cx, Sh procedures from different clients such
as AS and CSCF elements simultaneously was not conducted. As this testing scenario required more number
of IMS HSS clients, in-order to issue concurrent requests to the IMS HSS over the Diameter Cx and Diameter
Sh interface simultaneously. This is typical of a real-world deployment. Performance of the HSS in this typical
real-world scenario needs to be conducted and analyzed.
• Automated testing
Automation script development for testing of the prototype could not be done due to time constraints. Con-
figuring the test environment, subscriber generation based on required scenarios and stress testing for a given
critical resource would all be nice to have features and would test the system effectively.
• Third-party tools
– Basho-bench
∗ Yield / throughput inaccuracies need to be rectified, this would result in more accurate test results.
∗ Better interface to pass Erlang VM parameters so that VM parameters required can be easily configured
for testing would be nice to have feature.
∗ Reduce memory requirements per worker and develop features to obtain statistics about CPU utiliza-
tion, Input Output (IO) usage.
These enhancements would make Basho-bench a better performance, stress testing tool.
– Erlsom
Erlsom provides XML string generation via Data Binder mode, which is validated against a given XML
schema. As observed before with Erlsom performance tests, any measure to reduce CPU utilization would
benefit the performance of user-data management procedures of Diameter Cx and Sh interface. Erlsom
XML string generation performance would enhance the performance of the prototype.

60
Appendix A

Sequence Diagrams

A.1 Diameter Cx procedure sequence diagrams

Figure A.1: LIR/LIA sequence diagram.

62
Figure A.2: UAR/UAA sequence diagram.

63
Figure A.3: SAR/SAA sequence diagram.

64
Figure A.4: MAR/MAA sequence diagram.

65
Figure A.5: RTR/RTA sequence diagram.

Figure A.6: PPR/PPA sequence diagram.

66
A.2 Diameter Sh procedure sequence diagrams

Figure A.7: PUR/PUA sequence diagram.

67
Figure A.8: UDR/UDA sequence diagram.

68
Figure A.9: SNR/SNA sequence diagram.

69
Figure A.10: PNR/PNA sequence diagram.

70
Appendix B

Starting Basho-bench for testing

In the Basho-bench installed directory

• To start Basho-bench for end-to-end RPC tests for Cx procedures.

Please open the Basho-bench configuration file rpc_hss_cx.config
{ mode , { rate , 10 } } .
{ duration , 2 } .
{ report_interval , 10 } .
{ concurrent , 50 } .
{ driver , hss_cx_driver } .

{ key_generator , { uniform_int , 80000 } } .

{ hss , ’ hss@sarajevsko . mobilearts . local ’} .

{ mss , ’ mss@jupiler . mobilearts . local . ’} .

{ operations , [ { lir , 1 } ] } .

{ code_paths , [ " / home / hss / praveen / code / ims / launch / " ,

" / home / hss / praveen / code / ims / hss / " ,
" / home / hss / praveen / code / ims / scscf / " ,
" / home / hss / praveen / code / ims / icscf / " ,
" / home / hss / praveen / code / ims / operator / " ,
" / home / hss / praveen / code / ims / utils / " ,
" / home / hss / praveen / code / erlsom / "
]}.
Listing B.1: rpc_hss_cx.config

Example for running Basho-bench for LIR procedure with 50 concurrent workers at the rate of 10 operations/sec.
Setting the key_generator value to { uniform_int , 80000 } results in picking of the key-value in uniform
distribution manner from 1 to 80000 , which is used by the Mnesia Subscriber Server (MSS) to return the
public-identity for LIR procedure.
Required procedure to be run is LIR which can be set as value of the property operations in the config file.
• The corresponding driver file is hss_cx_driver.erl is as listed below
- module ( hss_cx_driver ) .
- export ( [ new /1 , run /4 ] ) .
- include ( " basho_bench . hrl " ) .

- record ( state , { hss , mss } ) .

new ( _Id ) ->

case net_kernel : start ( [ ’ hss_cx_driver ’ , longnames ] ) of
{ ok , _ } ->

72
 ? INFO ( " ~ p net kernel started as ~ p ~ n " , [ self () , node () ] )
;
{ error , { already_started , _ } } ->
ok ;
{ error , Reason } ->
? FAIL_MSG ( " failed to start net_kernel for ~ p : ~ p ~ n " , [ ?
MODULE , Reason ] )
end ,
inet_db : set_lookup ( [ dns ] ) ,
inet_db : add_ns ( { 192 ,168 ,211 ,10 } ) ,
HSS = ba sh o_ be nc h_ co nf ig : get ( hss ) ,
MSS = ba sh o_ be nc h_ co nf ig : get ( mss ) ,
? INFO ( " ~ p connect ~ p ? ~ p ~ n " , [ self () , HSS , net_kernel : connect (
HSS ) ] ) ,
? INFO ( " ~ p connect ~ p ? ~ p ~ n " , [ self () , MSS , net_kernel : connect (
MSS ) ] ) ,
{ ok , # state { hss = HSS , mss = MSS } } .

run ( uar , KeyGen , _ValGen , State ) ->

{ PrivateIdentity , PublicIdentity } = rpc : call ( State # state . mss ,
mss , pick_identity_pair , [ KeyGen () ] ) ,
% % io : format (" UAR ~ p ~ p ~ n ~ p ~ n " , [ PublicIdentity ,
PrivateIdentity , icscf : rpc_uar ( State # state . hss ,
PublicIdentity , PrivateIdentity ) ] ) ,
icscf : rpc_uar ( State # state . hss , PublicIdentity , PrivateIdentity ) ,
{ ok , State } ;

run ( lir , KeyGen , _ValGen , State ) ->

PublicIdentity = rpc : call ( State # state . mss , mss ,
pick_public_identity , [ KeyGen () ] ) ,
% % io : format (" LIR ~ p ~ n ~ p ~ n " , [ PublicIdentity , icscf : rpc_lir (
State # state . hss , PublicIdentity ) ] ) ,
icscf : rpc_lir ( State # state . hss , PublicIdentity ) ,
{ ok , State } ;

run ( mar , KeyGen , _ValGen , State ) ->

{ PrivateIdentity , PublicIdentity } = rpc : call ( State # state . mss ,
mss , pick_identity_pair , [ KeyGen () ] ) ,
% 5 io : format (" MAR ~ p ~ p ~ n ~ p ~ n " , [ PublicIdentity ,
PrivateIdentity , scscf : rpc_mar ( State # state . hss ,
PublicIdentity , PrivateIdentity ) ] ) ,
scscf : rpc_mar ( State # state . hss , PublicIdentity , PrivateIdentity ) ,
{ ok , State } ;

run ( sar , KeyGen , _ValGen , State ) ->

{ PrivateIdentity , PublicIdentity } = rpc : call ( State # state . mss ,
mss , pick_identity_pair , [ KeyGen () ] ) ,
% % io : format (" SAR ~ p ~ p ~ n ~ p ~ n " , [ PublicIdentity ,
PrivateIdentity , scscf : rpc_sar ( State # state . hss ,
PublicIdentity , PrivateIdentity ) ] ) ,
scscf : rpc_sar ( State # state . hss , PublicIdentity , PrivateIdentity ) ,
{ ok , State } .
Listing B.2: hss_cx_driver.erl

• To run the Basho bench driver corresponding the configuration listed above B.1, in the Basho -bench installed
directory.
./ basho_bench config / rpc_hss_cx . config

73
Appendix C

Erlang configuration

Erlang/OTP R15B01 was compiled from source using the following options.

-- enable - smp - support -- enable - threads - enable - native - libs -- enable - sctp

74
Bibliography

[1] Mobile Arts website. http://mobilearts.com/.

[2] 3GPP. ITU Q.713. http://www.itu.int/rec/T-REC-Q.713-200103-I, 2011. Q.713 : Signalling connection
control part formats and codes .

[3] 3GPP. TS 08.58 . http://www.3gpp.org/ftp/Specs/html-info/0858.htm, 2011. Base Station Controler - Base

Transceiver Station (BCS-BTS) Interface Layer 3 Specification.
[4] 3GPP. TS 23.002 V11.1.0. http://www.3gpp.org/ftp/Specs/html-info/23002.htm, 2011. Network architec-
ture.
[5] 3GPP. TS 23.003 V11.0.0. http://www.3gpp.org/ftp/Specs/html-info/23003.htm, 2011. Numbering, ad-
dresses and identification.
[6] 3GPP. TS 23.012 V10.1.0. http://www.3gpp.org/ftp/Specs/html-info/23012.htm, 2011. Location manage-
ment procedures.
[7] 3GPP. TS 23.016 V10.0.0. http://www.3gpp.org/ftp/Specs/html-info/23016.htm, 2011. Subscriber data
management. Stage 2.
[8] 3GPP. TS 23.018 V11.1.0. http://www.3gpp.org/ftp/Specs/html-info/23018.htm, 2011. Basic call handling.
Technical realization.
[9] 3GPP. TS 23.228 V11.3.0. http://www.3gpp.org/ftp/Specs/html-info/23228.htm, 2011. IP Multimedia
Subsystem (IMS). Stage 2.

[10] 3GPP. TS 29.002 V11.1.0. http://www.3gpp.org/ftp/Specs/html-info/29002.htm, 2011. Mobile Application

Part (MAP) specification.
[11] 3GPP. TS 29.228 V11.2.0. http://www.3gpp.org/ftp/Specs/html-info/29228.htm, 2011. IP Multimedia
(IM) Subsystem Cx and Dx interfaces. Signalling flows and message contents.

[12] 3GPP. TS 29.229 V11.0.0. http://www.3gpp.org/ftp/Specs/html-info/29229.htm, 2011. Cx and Dx inter-

faces based on the Diameter protocol. Protocol details.
[13] 3GPP. TS 29.328 V11.2.0. http://www.3gpp.org/ftp/Specs/html-info/29328.htm, 2011. IP Multimedia
(IM) Subsystem Sh interface. Signalling flows and message contents.

[14] 3GPP. TS 29.329 V11.2.0. http://www.3gpp.org/ftp/Specs/html-info/29329.htm, 2011. Sh Interface based

on the Diameter protocol. Protocol details.
[15] 3GPP. TS 35.205 V10.0.0. http://www.3gpp.org/ftp/Specs/html-info/35205.htm, 2011. An example algo-
rithm set for the 3GPP authentication and key generation functions f1, f1*, f2, f3, f4, f5 and f5*.
[16] 3GPP. TS 32.102 V10.0.0. http://www.3gpp.org/ftp/Specs/html-info/33102.htm, 2012. Security architec-
ture.
[17] Brad Appleton. A Software Design Specification Template. http://www.cmcrossroads.com/bradapp/docs/
sdd.html, 07 2012.
[18] Dave Smith. Basho Bench Wiki. http://wiki.basho.com/Benchmarking.html.

[19] Ericsson AB. Diameter reference manual. http://www.erlang.org/doc/apps/diameter/index.html.

[20] Ericsson AB. diameterc. http://www.erlang.org/doc/man/diameterc.html.

76
[21] Ericsson AB. diameterc. http://www.erlang.org/doc/man/diameter.html#add_transport-2.
[22] Ericsson AB. Erlang scheduler wall time. http://www.erlang.org/doc/man/erlang.html#system_flag_
scheduler_wall_time.
[23] Ericsson AB. gen_sctp. http://www.erlang.org/doc/man/gen_sctp.html.

[24] Ericsson AB. Mnesia reference manual. http://www.erlang.org/doc/man/mnesia.html.

[25] Ericsson AB. Observer User guide. http://www.erlang.org/doc/apps/observer/observer_ug.html.
[26] Fraunhofer Fokus, FHoSS. FOKUS Home Subscriber Server (FHoSS). http://www.fokus.fraunhofer.de/en/
fokus_testbeds/open_ims_playground/components/osims/fhoss/index.html, 07 2012.

[27] Fraunhofer Fokus, OSIMS. OSIMS - The FOKUS Open Source IMS Core. http://www.fokus.fraunhofer.de/
en/fokus_testbeds/open_ims_playground/components/osims/index.html, 07 2012.
[28] Erik Grafström. Resilient and optimized ldap database implementation for a large scale hlr / hss. Master‘s
thesis, Department of Information Technology, Uppsala University, Mobile Arts, Stockholm, 02 2012. This work
is referred to as concurrent thesis work in the report.

[29] Miikka Poikselkä, Georg Mayer. The IMS: IP Multimedia Concepts and Services, 3rd Edition. Wiley, 2009.
[30] Nokia Siemens Networks. Subscriber Data Management, Strategic data consolidation. Nokia Siemens Networks,
2008.
[31] Open IMS, Fraunhofer Institute. Source code downloadr. http://www.openimscore.org/download, 07 2012.

[32] OpenLDAP Foundation. OpenLDAP Software 2.4 Administrator’s Guide. Overlays. http://www.openldap.org/
doc/admin24/overlays.html.
[33] P. Calhoun and J. Loughney and E. Guttman and G. Zorn and J. Arkko. Diameter Base Protocol. http:
//tools.ietf.org/html/rfc3588, 2003.

[34] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V.
Paxson . Stream Control Transmission Protocol. http://www.ietf.org/rfc/rfc2960.txt, 2000.
[35] Michael Stonebraker. The case for Shared Nothing. Database Engineering, 9:4–9, 1986.
[36] Torbjörn Törnkvist. ELDAP Github repository. https://github.com/etnt/eldap.

[37] Vance Shipley. The 3Gdb Home Subscriber Server(HSS). http://www.3gdb.org/doc/overview-summary.html,

07 2012.
[38] Vance Shipley. The 3Gdb Home Subscriber Server(HSS). http://hss.googlecode.com/svn/trunk/
hss-read-only, 07 2012.

[39] Willem de Jong. Erlsom website. http://erlsom.sourceforge.net/erlsom.htm.

77