HSS Front-End implementation for a large scale common HLR/HSS

(1)

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

(2)

2

(3)

Teknisk- naturvetenskaplig fakultet UTH-enheten

Besöksadress:

Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0

Postadress:

Box 536 751 21 Uppsala

Telefon:

018 – 471 30 03

Telefax:

018 – 471 30 00

Hemsida:

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

Abstract

"HSS Front-End implementation for a large scale common HLR/HSS"

PraveenKumar Bhadrapur

With rapid growth in the use of telecommunication services, subscribers enjoy value-added services via different telecommunication technologies. The

telecommunication companies need to get a single view of the subscriber data in order to profile them (for example:profitable subscribers) and reduce operational costs by the virtue of maintaining common subscriber data. A Home Location Register (HLR) in Global System for Mobile Communication (GSM) domain and Home Subscriber Server (HSS) in IP Multimedia Subsystem (IMS) domain store subscriber data.

A subscriber may use both GSM and IMS services. The 3rd Generation Partnership Project (3GPP) has specified separate standard specifications for HLR and for HSS. As a result, in many cases there is duplication of subscriber data in both of them.

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 the GSM and IMS services.

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.

Sponsor: Mobile Arts AB IT 12 048

Examinator: Lisa Kaati

Ämnesgranskare: Justin Pearson Handledare: Jonas Falkevik

(4)

4

(5)

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

(6)

1

(7)

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

(9)

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

(10)

5

(11)

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

(12)

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

(13)

VLR Visitor Location Register VM Virtual Machine

XML Extensible Markup Language XSD XML Schema Definition

eMLPP enhanced Multi-Level Precedence Pre-Emption

(14)

9

(15)

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 technologies 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.

(16)

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

utilities/

common libraries incoming _dialog_

handler

outgoing _dialog_

handler

HLR

HLR LOGIC HLR_DB_API

LDAP

MNESIA Legend

Re-used Thesis work Concurrent 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

(17)

Interrogating Call Session Control Function (I-CSCF), Serving Call Session Control Function (S-CSCF) entities interact 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].

(18)

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 applications and APIs used in the system.

13

(19)

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.

(20)

(21)

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.

(22)

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

(23)

IMS subscription Private user identity

Public user identity

Service 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 base protocol

Diameter Cx

Diameter Sh

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.

(24)

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 pertaining 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

(25)

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 configuration 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 concurrent workers

Rate

(ops/sec) Throughput Yield (%)

CPU utilization

(%)

Memory utilization

(%)

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.

(26)

• 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.

Schema Expected Operations/sec

Observed Throughput

(ops/sec)

Latency (ms)

CPU utilization

(%)

Memory utilization

(%)

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

(27)

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].

(28)

(29)

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.

(30)

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

(31)

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].

HSS Front-End implementation for a large scale common HLR/HSS

Examensarbete 30 hp Oktober 2012

HSS Front-End implementation

for a large scale common HLR/HSS

PraveenKumar Bhadrapur

Institutionen för informationsteknologi

Abstract

"HSS Front-End implementation for a large scale common HLR/HSS"

Acknowledgements

Contents

List of Figures

List of Tables

Glossary

Chapter 1

Introduction

1.1 Purpose

1.2 Scope

1.3 Out of scope

1.4 Related work

1.5 Document organization

Chapter 2

Technical background

2.1 IMS

2.2 IMS subscription model

2.3 Diameter

2.4 GSM

2.5 Abstract data-structure for GSM subscriber data

2.6 Mnesia

2.7 Third-party tools

Chapter 3

Design and implementation

3.1 LDAP DIT design

3.2 System Overview

3.3 Design considerations