IT 12 048

Examensarbete 30 hpOktober 2012

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

PraveenKumar Bhadrapur

Institutionen för informationsteknologiDepartment of Information Technology

2

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 scalecommon HLR/HSS"

PraveenKumar Bhadrapur

With rapid growth in the use of telecommunication services, subscribers enjoyvalue-added services via different telecommunication technologies. Thetelecommunication companies need to get a single view of the subscriber data inorder to profile them (for example:profitable subscribers) and reduce operationalcosts by the virtue of maintaining common subscriber data. A Home LocationRegister (HLR) in Global System for Mobile Communication (GSM) domain andHome Subscriber Server (HSS) in IP Multimedia Subsystem (IMS) domain storesubscriber data.

A subscriber may use both GSM and IMS services. The 3rd Generation PartnershipProject (3GPP) has specified separate standard specifications for HLR and for HSS. Asa result, in many cases there is duplication of subscriber data in both of them.Minimizing duplication in subscriber data can be accomplished by developing acommon HLR/HSS. This would result in providing single view of the subscriber data inthe GSM and IMS services.

This thesis work investigates the possibility to implement a common HLR/HSSproduct by adding a HSS Front-end (FE) server and an IMS subscriber database to analready existing HLR implementation consisting of a HLR FE server and a GSMsubscriber database.

The FE HSS/HLR prototype was designed and developed using Erlang /Open TelecomPlatform (OTP). The prototype developed is capable of handling Diameter queriesfrom the Application Server (AS) and Call Control State Function (CSCF) in the IMSdomain and provides HLR database access in the GSM domain. Performance analysisof the third-party tools, components and the prototype was carried out to evaluatereal-time characteristics.

Tryckt av: Reprocentralen ITC

Sponsor: Mobile Arts ABIT 12 048Examinator: Lisa KaatiÄmnesgranskare: Justin PearsonHandledare: Jonas Falkevik

4

Acknowledgements

I have to thank few people who have helped complete my thesis successfully. First of all, I would like to thankJonas Falkevik, Software Designer, Mobile Arts AB supervisor for my thesis work. Jonas was of great help withtechnical ideas and providing necessary feedback for the completion of thesis work. I would like to thank Mobile ArtsAB, Stockholm for providing the required infrastructure and encouragement throughout the thesis duration at theirpremises.

I would like to thank Master‘s program thesis coordinator Olle Eriksson at Uppsala university. Justin Pearson, SeniorLecturer 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 liketo express gratitude to my mother late Smt. Savitri Bhadrapur, my father Shri. Gurusiddappa Bhadrapur and mybrother Pradeep Kumar Bhadrapur.

1

Contents

1 Introduction 101.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.3 Out of scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.4 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.4.1 3Gdb Home Subscriber Server (HSS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.4.2 Open Source IMS Core (OSIMS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.4.3 Resilient and optimized Lightweight Directory Access Protocol (LDAP) database implementa-

tion for a large scale Home Location Register (HLR)/ HSS . . . . . . . . . . . . . . . . . . . . 131.5 Document organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Technical background 162.1 IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2 IMS subscription model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3 Diameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.4 GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.5 Abstract data-structure for GSM subscriber data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.6 Mnesia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.7 Third-party tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.7.1 Basho-bench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.7.2 Erlsom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.7.3 eLDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 Design and implementation 243.1 LDAP Directory Information Tree (DIT) design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.3 Design considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.4 Data design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.5 IMS HSS architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.5.1 Supervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.6 GSM HLR database Application Programming Interface (API) . . . . . . . . . . . . . . . . . . . . . . 343.7 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.8 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.9 IMS system components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.9.1 I-CSCF Diameter agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.9.2 S-CSCF Diameter agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.9.3 AS Diameter agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.9.4 HSS subscription manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.9.5 Operator interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.10 IMS Interfaces overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.10.1 Diameter agent API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.10.2 HSS subscription handler API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.10.3 HSS database API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4 Evaluation and testing 424.1 Test Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.2 Test data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.3 Test scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.4 Performance measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.4.1 Diameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

2

4.4.2 End-to-end Diameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.4.3 End-to-end RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.5 Global System for Mobile Communication (GSM) HLR database API . . . . . . . . . . . . . . . . . . 484.6 Performance analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.6.1 Diameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.6.2 End-to-end diameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.6.3 End-to-end RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.7 Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.8 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.9 Load balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5 Conclusion 585.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

A Sequence Diagrams 62A.1 Diameter Cx procedure sequence diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62A.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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2 IP Multimedia Private Identity (IMPI) and IP Multimedia Public Identity (IMPU) relationship. . . . 182.3 Relation between Diameter applications and Diameter base protocol. . . . . . . . . . . . . . . . . . . . 182.4 GSM Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1 LDAP DIT of HLR/HSS static subscriber data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2 HLR/HSS system overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.3 HSS dynamic data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.4 HLR dynamic data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.5 IMS HSS architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.6 IMS HSS supervision structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.7 IMS components supervision structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.1 Test framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.2 Diameter Cx Transmission Control Protocol (TCP) performance analysis . . . . . . . . . . . . . . . . 494.3 Diameter Sh TCP performance analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.4 Diameter Cx Stream Control Transmission Protocol (SCTP) performance analysis . . . . . . . . . . . 504.5 Diameter Sh SCTP performance analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.6 End-to-end Diameter Cx over TCP performance analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 514.7 End-to-end Diameter Sh over TCP performance analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 524.8 End-to-end Remote Procedure Call (RPC) Diameter Cx performance analysis . . . . . . . . . . . . . . 524.9 End-to-end RPC Diameter Sh performance analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.10 IMS HSS Front-end (FE) LIR block. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.11 IMS HSS Back-end (BE) block. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.12 FE scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.13 Load balancing:subscription location analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

A.1 Location Information Request (LIR)/Location Information Answer (LIA) sequence diagram. . . . . . . 62A.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. . . . . . . . . 64A.4 Multimedia-Auth Request (MAR)/Multimedia-Auth Answer (MAA) sequence diagram. . . . . . . . . 65A.5 Registration-Termination Request (RTR)/Registration-Termination Answer (RTA) sequence diagram. 66A.6 Push-Profile Request (PPR)/Push-Profile Answer (PPA) sequence diagram. . . . . . . . . . . . . . . . 66A.7 Profile-Update-Request (PUR)/Profile-Update-Answer (PUA) sequence diagram. . . . . . . . . . . . . 67A.8 User-Data-Request (UDR)/User-Data-Answer (UDA) sequence diagram. . . . . . . . . . . . . . . . . . 68A.9 Subscribe-Notifications-Request (SNR)/Subscribe-Notifications-Answer (SNA) sequence diagram. . . . 69A.10 Push-Notification-Request (PNR)/Push-Notification-Answer (PNA) sequence diagram. . . . . . . . . . 70

List of Tables

2.1 Basho-bench null configuration test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2 Erlsom performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1 GSM HLR database API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.2 Hardware specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.3 IMS HSS database API for Cx procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.4 IMS HSS database API for Sh procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.1 Identity server performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.2 Diameter performance results over TCP transport. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.3 Diameter performance results over SCTP transport. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.4 End-to-end Diameter performance results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.5 End-to-end RPC performance results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.6 GSM HLR database API performance results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4

5

Glossary

3GPP The 3rd Generation Partnership ProjectAAA Authentication, Authorization and AccountingACID atomicity, consistency, isolation, durabilityADD Automatic Device DetectionAMF Authentication Management FieldAN Access NetworkAPI Application Programming InterfaceAS Application ServerAVP Attribute Value PairBDB Berkley DatabaseBE Back-endBSC Base Station ControllerBSG Basic Service GroupBSSMAP Base Station System Management Application PartBSS Base Station SubsystemBTS Base Transceiver StationCAMEL Customised Applications for Mobile networks Enhanced LogicCEA Capabilities-Exchange-AnswerCER Capabilities-Exchange-RequestCFB Call Forwarding on mobile subscriber BusyCFNRc Call Forwarding on mobile subscriber Not ReachableCFNRy Call Forwarding No ReplyCFU Call Forwarding UnconditionalCLIP Calling Line Identification PresentationCLIR Calling Line Identification RestrictionCNAP Calling Name PresentationCN Core NetworkCOLP Connected Line identification PresentationCPU Central Processing unitCSCF Call Control State FunctionCS Circuit SwitchCUG Closed User GroupDIT Directory Information TreeDTAP Direct Transfer Application PartFE Front-endG-MSC Gateway Mobile Switching CentreGPRS General Packet Radio ServicesGSM Global System for Mobile CommunicationHLR Home Location RegisterHSS Home Subscriber ServerI-CSCF Interrogating Call Session Control FunctionIANA Internet Assigned Numbers AuthorityIETF Internet Engineering Task ForceIMPI IP Multimedia Private IdentityIMPU IP Multimedia Public IdentityIMSI International Mobile Subscriber IdentityIMS IP Multimedia SubsystemIM IP MultimediaIO Input Output

6

IP Implementation ProposalLDAP Lightweight Directory Access ProtocolLIA Location Information AnswerLIR Location Information RequestLMSI Local Mobile Station IdentityMAA Multimedia-Auth AnswerMAP/C Mobile Application Part CMAP/D Mobile Application Part DMAP Mobile Application PartMAR Multimedia-Auth RequestMB megabyteMCC Mobile Country CodeMC MulticallMGC Media Gateway ControllerMG Media GatewayMSC Mobile-service Switching CenterMSISDN Mobile Subscriber ISDN NumberMSS Mnesia Subscriber ServerMS Mobile StationNAI Network Access IdentifierNGN Next Generation NetworkOAM Operation, Administration and MaintenanceOP Operator Variant Algorithm Configuration FieldOSIMS Open Source IMS CoreOS Operating SystemOTP Open Telecom PlatformP-CSCF Proxy Call Session Control FunctionPNA Push-Notification-AnswerPNR Push-Notification-RequestPPA Push-Profile AnswerPPR Push-Profile RequestPSI Public Service IdentityPS Packet SwitchPUA Profile-Update-AnswerPUR Profile-Update-RequestRAM Random Access MemoryRFC Request For CommentRPC Remote Procedure CallRTA Registration-Termination AnswerRTR Registration-Termination RequestS-CSCF Serving Call Session Control FunctionSAA Server-Assignment AnswerSAR Server-Assignment RequestSCCP Signaling Connection Control PartSCTP Stream Control Transmission ProtocolSCUDIF Service Change and UDI/RDI FallbackSIM GSM Subscriber Identity ModuleSIP Session Initiation ProtocolSNA Subscribe-Notifications-AnswerSNR Subscribe-Notifications-RequestSS7 Signaling System 7SS Supplementary ServicesSVN SubversionTCP Transmission Control ProtocolTMSI Temporary Mobile Subscriber IdentityUAA User-Authorization AnswerUAR User-Authorization RequestUDA User-Data-AnswerUDR User-Data-RequestURI Uniform Resource Identifier

7

VLR Visitor Location RegisterVM Virtual MachineXML Extensible Markup LanguageXSD XML Schema DefinitioneMLPP enhanced Multi-Level Precedence Pre-Emption

8

9

Chapter 1

Introduction

In the field of telecommunication, extensive technological advancements have resulted in numerous services. Thenumber of subscribers accessing telecommunication services increased rapidly over recent past. Due to the increasein the subscriber number and the number of services accessed via several technologies by the subscribers, effectivesubscriber data management became vital in-order to sustain higher order growth. Subscriber data management isone of the primary issues a multi-service telecommunication operator has to face. Strategic data consolidation incase of subscriber data in-order to learn about the customer preferences for different services and telecommunicationsolutions 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 datamanagement of the GSM and IMS subscribers, the telecommunication operator has to obtain the single view of thesubscriber 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 possibilityof 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. Asubscriber can be both a GSM subscriber and an IMS subscriber. Separate standards specifications for HLR andfor HSS by 3GPP implies that in many cases the same subscriber data must be stored both in Home LocationRegister (HLR) and in Home Subscriber Server (HSS). A common HSS/HLR product would minimize the amount ofsubscriber data that gets duplicated. This would help in ensuring a telecommunication operator obtain a single viewof 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 MobileApplication 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 beused 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 theLightweight 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 (pleaserefer 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 towardsthe 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 bythe common Back-end (BE) server. The common BE server uses Lightweight Directory Access Protocol (LDAP) toprovide resilient, highly-scalable database infrastructure. Details about the BE server is covered by the concurrentthesis 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 wouldbe 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 accomplishthe task of providing common subscriber data to both GSM and IMS subscribers, concurrent thesis titled Resilientand optimized LDAP database implementation for a large scale HLR/HSS will be used as reference. More detailsabout 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-orderto access the static GSM subscriber data. The dynamic data access needed is provided by the in-memory Mnesiadatabase.

IMS scope

IMS HSS needs to serve data look-up queries just as in case for GSM HLR. The IMS HSS clients are the CallControl State Function (CSCF) entities and Application Server (AS). The IMS HSS clients interact with the HSS viaDiameter protocol. Diameter is a peer-to-peer Authentication, Authorization and Accounting (AAA) protocol. Moreinformation 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 HSSvia 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 thecommon 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 outof 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 wasgood initial reference as it had some sample implementations of some of the features of the HSS. OSIMS provided aperspective of usage of HSS as a research prototype which is adhering to the 3GPP specifications [27]. Concurrentthesis work was done in co-ordination with the thesis work, this helped ease the integration of the FE HSS/HLR tothe BE LDAP access.

1.4.1 3Gdb HSS

3Gdb HSS provides a good overview about IMS HSS design and has minimal reference implementation [37]. 3GdbHSS work describes the IMS system, provisioning, subscription management, services, operator interface and simpleMnesia database design for handling procedures over Cx and Sh Diameter interface. The 3Gdb HSS implementationhas no support for Diameter protocol and public service identities are not considered. The reference implementationis 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 havenot 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 CallSession Control Function (P-CSCF) and HSS undertaken by the Fraunhofer institute for research purpose. The motivebehind 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 performanceof the CN elements has not been the main motive and hence no performance metrics about the implementation areprovided [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, authenticationfeatures, 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 takenup by Erik Grafström during the same period. The thesis work required close cooperation with concurrent thesis workand required infrastructural support from Mobile Arts, Stockholm.

The concurrent thesis work will provide static subscriber data backed by the LDAP database. Concurrent thesissupports database resilience, fault tolerance by using replication techniques provided by the OpenLDAP and concurrentmanagement of static subscriber data [32]. This thesis work will provide LDAP management tools necessary for theoperator 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/ IMSsubscriber data in highly concurrent manner. Access to OpenLDAP server was primarily through eLDAP (Erlangimplementation of LDAP client) [36].

1.5 Document organization

This document is composed of several chapters which covers different aspects of the design. The glossary containscollection 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 sectionprovides brief overview of the IMS, GSM networks and their architectures, subscriber concepts of GSM and IMSand 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 underconsideration for implementation of the common HLR / HSS are highlighted.

• Design considerations for the prototype development are discussed. Constraints involving the third-partytools is highlighted.

• Data design discusses the ideas behind the static/dynamic data convention and explains the relation betweendata items and how the subscriber data is structured.

• System architecture contains the IMS HSS architecture, supervision structure and GSM HLR database APIimplemented 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 GSMHLR database APIs. Test data generated helped conduct performance testing of the components andsystem.

• Performance measurements.• Performance analysis of the measurements observed carried out in-order to identity the bottle-necks in thesystem.

• 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 toolsand 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 arecovered. 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 restrictedto 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 baseprotocol can be extended. Erlang Diameter Library provided as part of R15B release will be used for implementationof 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 telecommunicationapplications.

Section 2.7 provides information about the advantages and issues with third-party tools used in this thesis namely theErlsom, Basho-bench as testing tool and refers to eLDAP as third-party tool which was used in the concurrent thesiswork [28].

2.1 IMS

IMS is set of requirements and specifications as defined by 3GPP to provide a unifying architecture for ImplementationProposal (IP)-based services over both packet-switched and circuit-switched networks. IMS uses standard IP protocolsas 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 Internetapplications, services and protocols. The intention of IMS network is to provide convergence and access to variousservices 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 enhancedtelecommunication usage.

As shown in the figure 2.1 IMS architecture basically composes of the service/application layer, IMS layer and thetransport layer. Service/application layer essentially consists of various AS. An AS can be SIP server serving multipleIP 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 pointfor an IMS network, S-CSCF element provides the required serving capabilities for an IMS subscriber in the homenetwork and I-CSCF acts as the contact, forwarding point to each of the operator’s network. The services applicationsare hosted by the AS.

16

IMS HSS manages subscriber, service data and is the main database for an IMS network. In an IMS network, HSSserves requests from the S-CSCF and the I-CSCF over the Diameter Cx interface. An I-CSCF can request an IMS HSSfor the identity of the S-CSCF currently serving a given public identity. S-CSCF can request to download user-profilesfrom IMS HSS. AS can request for user-data download over Diameter Sh interface from the HSS. These interactionsover Diameter Cx, Sh interface can be referred in the figure 2.1. These are few of the many instances where HSS hasto serve the subscriber data, location related, authentication information of the identities. Functionalities expectedfrom 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. IMSsubscription 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 generatean 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 theform of SIP Uniform Resource Identifier (URI) or telephone URI. An example IMPU in the SIP URI format could besip:james@it.uu.se.

IMS service profile is basically collection of service and user related data [11]. The IMS service profile is defined andmaintained by the IMS HSS.

Relationship between the IMS user identities can be visualized via the following figure 2.2 [9].

17

IMS subscription Private user

identity

Public user

identity

Public user

identity

Public user

identity

Service

Profile

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 identitiesare registered at the same time and similarly for de-registration. Some of the implicitly registered can be associatedwith different services profile than the other in the same group. Sharing of the service profiles among the implicitgroups is allowed. A single public identity can also be shared among two or more private identities. More informationcan 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 overthe 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 isof 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 andenhanced 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 theDiameter base protocol. Each such application is identified by the application-identifier. For example, InternetAssigned 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 ofAttribute Value Pair (AVP)s. AVP are used to deliver data and every Diameter message is composed of the severalAVPs, some of which are mandatory [33]. Diameter applications can added their own AVPs if they are not defined aspart of the base protocol.

Diameter client can be a P-CSCF, which could perform access control. Diameter server can be a HSS which providesAAA requests for the realm under consideration. A HSS has to support Diameter applications Cx, Sh in addition tothe 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 implementationversion 1.1 [19]. Further in this thesis report, wherever Diameter discussions regarding the implementation are carriedout 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 severaldifferent frequencies for a given cell area. BTS provides necessary signaling to BSC over Abis interface and media tothe CN. MS connect to the BTS over the Um interface. BSC handles number of BTS. It handles the administration ofBTS, cell data and location related data. BTS and BSC form the Base Station Subsystem (BSS). The Abis interfaceused 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 areused 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 ApplicationPart (BSSMAP), Direct Transfer Application Part (DTAP) protocols use SCCP as underlying protocol, all of theseprotocols 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 ApplicationPart (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 MobileSubscriber Identity (TMSI) and handles location management, call related procedures and temporary subscriber datafor 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 subscriberdata. HLR provides necessary interface to retrieve the subscriber data for a VLR over the MAP D interface. GatewayMobile Switching Centre (G-MSC) interfaces over MAP C interface to interrogate the HLR for subscriber informationand 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 hierarchicaltree rooted with International Mobile Subscriber Identity (IMSI) of a given GSM subscriber. The data which isretrieved 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 henceneeds confidentiality over the Um interface. TMSI is generally allocated by VLR for this purpose. IMSI is used forauthentication 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 typicalused for call-routing purpose. MSISDN is allocated such that it can be used as SCCP global-title address, which isessential 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 agiven subscriber. Basic services consist of Tele-services and Bearer-services. Several BSG have been defined for theTele-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 theRandom 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 therespective tables in the Mnesia database. This close interoperability of Mnesia with Erlang/OTP with data-structuressuch as Erlang records and for querying, the list comprehensions makes Mnesia a viable option for usage in our thesiswhich 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 ofthe HLRHSS prototype.

2.7.1 Basho-bench

Basho-bench provides a test framework for testing a huge number of highly concurrent Erlang processes which notonly 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 processor a component. Basho-bench was used extensively to test the FE components such as Erlsom, eLDAP, Diametercomponents 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 testand 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 tooltests the the basho-bench performance with minimum overhead.

Table 2.1 has results for the basho_bench_driver_null test.

Number ofconcurrentworkers

Rate(ops/sec) Throughput Yield

(%)

CPUutilization

(%)

Memoryutilization

(%)1000 10 9900 99 45 272000 10 19530 97.65 45 523000 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 withminor error rate.

• Max rate, does not show the exact number of operations/sec possible. Some of the test runs revealed thatCentral 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 around1MB of memory.

• More information about test results such as CPU utilization, memory utilization and io for both the basho-benchclient 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 andthe 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 validatedagainst a schema has been tabulated in table 2.2 [39]. The schema for each of the interface Cx and Sh interface hasbeen specified in technical specification TS:29.228 and TS:29.328 respectively [11] [13] . Schema‘s serve as modelsagainst which the generated the XML will be validated against. Minimal data was used to fill the required XMLrecords which was written as XML string. All the tests tabulated below had schema‘s pre-compiled into models. Thisis done as it reduces the CPU computation required every time the schema‘s are compiled into models and the sameoptimization has been used in the implementation of HLR / HSS. Rate at which each basho-bench concurrent workeris 10 ops/sec. (worker - here is the driver code which transforms an Erlang record into an XML string as specifiedby the schema). Number of concurrent workers in each of the tests has varied from 50, 100, 200 giving number ofoperations per sec values 500, 1000, 2000 respectively.

Schema ExpectedOperations/sec

ObservedThroughput(ops/sec)

Latency(ms)

CPUutilization

(%)

Memoryutilization

(%)Cx 500 500 0.6 80 2.5

1000 1000 0.6 150 42000 2000 0.8 215 7.6

Sh 500 500 1.15 105 2.51000 1000 1.2 185 4.12000 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 testmachine is delivered and with less variation in latency. The CPU utilization goes up considerably and memoryutilization increases slightly.

21

Considerable increase in CPU utilization by the Erlsom with respect to operations/sec is of prime concern since theprocedures which use Erlsom extensively such as Cx/SAR , Sh/UDR, Sh/PUR, Sh/SNR will be bottle-necked forCPU 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 tobe read later for validation when XML strings are written by the Erlsom. This optimization reduces CPU computationconsiderably. 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 almostlinear, 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 thesiswork 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 basedon 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 bedesigned. LDAP functional block from the FE HLR/HSS perspective is essentially eLDAP API interface provided bythe concurrent thesis work 1.4.3

Section 3.3 reflects on why Erlang/OTP was preferred language for implementation and classification of data betweenthe FE and BE. Erlang Diameter library, hardware constraints, need of Erlsom as third-party library are constraintswith 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 brieflyexplained. The Mnesia tables and fields considered here are sufficient for the procedures of Diameter Cx, Sh interfacein 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 overCx and Sh interface, the procedure worker components, the HSS database API components and the HSS subscriptionmanager 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 inthe 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 subscriptionhandling 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 andclassify 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-idSID = 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 generatinga common-set of service profiles which could be associated with most of subscribers, a large amount of data duplicationis avoided. Each service profile would have both GSM and IMS service profile. By mapping the members of the groupSubscribers to the group Profiles, the data to be managed would be significantly lesser than associating each subscriberto a profile.

The number of service profiles would increase only if the operator would have set of services are newly added or anew combination of services in a profile is requested. Service profiles are combination of the members from the groupServices. Since each service is uniquely identified by private service identity, a reference to the object of the service inthe profile is necessary and sufficient to create an association. Similarly an association between the object of subscriberand 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 subscribersby the use of a FE and BE where the FE handles the procedure logic and dynamic data and the BE serves thestatic subscriber data. This enables the use of specialized technologies, LDAP in the BE is optimized for a heavy readintensive environment while Mnesia in the FE serves well as in-memory database and Erlang/OTP provides concurrentmessaging 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 theIMS 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 GSMdynamic subscriber data.

The common LDAP backend is comprised of a LDAP client and the LDAP server with its database of static subscriberdata 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 callsas specified by 3GPP.

The HLR/HSS supports a subset of the IMS and GSM subscription models. (Please refer Section 2.2 and Section 2.5for 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 theprocedures to serve subscribers. The FE handles dynamic subscriber data such as current location, registration statusand service status. The BE (please refer concurrent thesis work in the Section 1.4.3 for more information) handles thestatic 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 ofdifferent 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 toimplement a highly concurrent and fault-tolerant HLR/HSS. OTP provides required platform to implement proceduresas described by the specifications. The Mnesia database is used to serve dynamic data since Mnesia provides in-memorylow-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 dataand component design on 3GPP specifications. Implementation of procedures according to the specificationswas primary requirement which has been met.

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

26

• Erlsom library was needed for some of the Diameter Cx and Sh procedures in-order to generate XML stringaccording to the schema specified in the specification TS:29.228 and TS:29.328 [39] [11] [13]. More details onErlsom 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 measurementsof 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 andfigure 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 whichis set at start-up and mostly read while running. The data items in the operator data Mnesia tables enable the HSSto 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(nestedrecords) as highlighted are sub-objects of the (outer nested records) black objects. Sub-records are contained withinthe records. These records are needed to enable user registration and service registration over the Cx interface andsubscription 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_listas_permission_list is operator data which contains permissions for each AS in the operator network. Allowedoperations 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_dataoperator_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 authenticationvectors 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 theuser 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 generatingauthentication vectors.

user_registration_infouser_registration_info has a wild-carded IMPU or a distinct IMPU as key. This table is used when servingrequests 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_infoservice_registration_info has wild-carded PSI as the key. It is used to retrieve information regarding thecurrent state (psi_activation_state) of a given PSI, the assigned S-CSCF and the private_service_ identityassociated 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_infosh_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 andas_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.6in 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 aresent.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.

repositoryrepository has wild-carded or distinct PSI or wild-carded or distinct IMPU as the key. It contains a list ofrepository_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_datarepository_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 containsmainly 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 dataseen in figure 3.4b. The grey objects(nested records) as highlighted are sub-objects of the (outer nested records) blackobjects. Sub-records are contained within the records. GSM network data is accessed over the MAP using MAP/Cand MAP/D procedures and the operator data contains operator specific configuration data required to set up andrun a GSM network.

(a) Operator data.

(b) Network data.

Figure 3.4: HLR dynamic data.

The contents of the tables are as follows.

operator_informationoperator_information has operator_id as key. This table contains the GSM operator information such as theoperating VLR list , HLR list, MSC list, supported services by MSC, pre-paging support, Automatic DeviceDetection (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_statussubscriber_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 MSmnrf 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_inforoaming_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_profiless_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 ofprovisioned_ss_features.ss_registration_data contains registration information for a given IMSI applicable for all the provisioned SS.

provisioned_ss_featuresprovisioned_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 onmobile 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_datass_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.

bsgA 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_statusSS 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 subscriptionfor 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 serviceprovider or the MS.activation_state is set to either active and quiescent or active and operative when the SS is activated, notactive when the SS is deactivated.induced_state is set as induced by the HLR for some of the SS where it is applicable.

authentication_infoA 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_datachallenge_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. Thestate of the system across sessions responsible for handling the procedures is stored only in Mnesia or LDAP. Thiswould lead to each and every process in the system have only its state. As result, when a process crashes, it wouldresult 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 whichprovides transactional operations on the data it stores. Dynamic data records, the Mnesia tables are explained inmore detail in section 3.4.

Reading static data from the LDAP database is highly efficient 1.4.3. Mnesia database serves well in handling sessiondata for each of the Cx and Sh procedures. Data read by the procedure workers can utilize the read data in efficientmanner, 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 memorytill the procedure worker completes execution, this is a design trade-off. Appropriate pre-fetching of data by thehss_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 subsequentLDAP queries, as procedures usually need the attributes from the same LDAP data object to proceed executing. Forexample, a search query for a given IMPU on imsUser objectClass would result in returning all the attributes of theobjectClass imsUser which could be reused by the procedure logic by storing the data in its own state (refer to theLDAP schema in the concurrent thesis report [28]). Similarly, data fetched by reading from the Mnesia transactionscan 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 designprefers reduced number of database look-ups for the reasons described above.

31

Legend

Cx HSS Server Call

Sh HSS Server Call

i-cscf_diameter_agent

icscf_diameter_client

icscf_diameter_server

icscf_diameter_client_cb

icscf_diameter_server_cb

s-cscf_diameter_agent

scscf_diameter_client

scscf_diameter_server

scscf_diameter_client_cb

scscf_diameter_server_cb

as_diameter_agent

as_diameter_client

as_diameter_server

as_diameter_client_cb

as_diameter_server_cb

Cx HSS Client Call

Sh HSS Client Call

Erlang Message

IMS Control Plane

IMS Service Plane

hss_cx_diameter_agent

hss_cx_diameter_client_cb

hss_cx_diameter_server

hss_cx_diameter_server_cb

hss_cx_diameter_server_workers

hss_cx_diameter_client_workers

hss_db

hss_sh_diameter_client_cb

hss_sh_diameter_server

hss_sh_diameter_server_cb

hss_sh_diameter_agent

hss_sh_diameter_server_workers

hss_sh_diameter_client_workers

operator_interface

hss_cx_query_select_pull

hss_cx_put_pull

hss_cx_location_query

hss_cx_authdatareq

hss_sh_pull

hss_sh_update

hss_sh_subs_notif

hss_cx_deregister

hss_cx_update_subscr_data

hss_sh_notif

Mnesia

LDAP Server

hss_sh_diameter_client

hss_cx_diameter_client

eldap_manager

HSS

hss_subscription_manager

hss_nt_data_

subs_server

hss_subs_handler

hss_t_data_

subs_server

hss_db_apihss_db_api

mnesia_worker

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 Diameteragents (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 infigure 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 figure3.5.

Diameter applications can be configured to have separate call-back modules or the same call-back can be configuredto handle both Diameter applications Cx, Sh (As previously mentioned in the Section 2.3, Diameter application hererefers to the Diameter protocols Cx, Sh extended over the common Diameter base protocol). Reason for choosingseparate call-backs for each of the application is to have modularity and understand the performance characteristicsof 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, theDiameter agent, I-CSCF could register a Diameter Cx application as service and AS, a Diameter Sh application asa Diameter service. The corresponding application (Cx or Sh) would be started as service by the HSS Diameteragent. The Erlang Diameter stack provides connection setup over TCP or SCTP transport protocols. After theconnection set up between two Diameter agents, the client Diameter agent (for example an I-CSCF) can send Diametercommands 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 receivedDiameter command/request received spawns a procedure worker process. The procedure worker process spawnedexecutes 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 Erlangcode. Diameter Sh application messages can be similarly passed on, between the Diameter agents configured as eithera server or client.

32

To execute the procedure logic, each of the workers interact with the hss_db module. The hss_db_api process isspawned per process request. The hss_db_api process would spawn mnesia_worker process. hss_db_api processinteracts with the eldap_managerprocess to get the eldap_worker process to make LDAP queries. This would resultin high number of concurrent processes performing dynamic data operations on the Mnesia tables and static dataoperation via LDAP for each of the procedure worker requests (refer to [28] for more information on the eLDAPworker process management). After necessary procedural logic execution, an answer message would then be sent bythe corresponding Diameter call-back module process. Detailed sequence diagrams for each of the Diameter messagecan be found in Appendix A. The sequence diagrams in Appendix A reflects the data access requirements for eachof the Diameter message without the notion of caching data from Mnesia or LDAP in the gen_server state. Thesequence 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 theoperator. The operator can perform subscriber management operations such as network initiated termination ofregistration and updating subscriber data over the Diameter Cx interface. Other operator tasks such as handlingMnesia configuration manager are performed. The details about the operator interface in more detail can be found insection 3.9.5.

hss_db module consists of hss_db_api process which invokes a LDAP query for static subscriber data or a Mnesiaquery for dynamic subscriber data. A Mnesia query would be passed to a Mnesia worker and it would on successfulupdate notify the hss_subscription_manager. A LDAP query would be passed to the eLDAP manager and theresult would be passed back. More details about the API can be found in Section 3.10.3. Process design pattern forhss_db_api is gen_server.

hss_subscription_manager module is responsible for handling the update user-data/user-state by Cx and Sh interfaceworkers. hss_subscription_manager determines if an update of user data or user state for subscribed transparentor non-transparent should trigger the notification procedures described in 3GPP TS 29.328. [13] More details aboutexact 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 processesbased on the configuration for restart-strategies. Supervision provides clean way of restarting applications if the workerprocesses 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 CxDiameter 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 ShDiameter 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 supervisionof 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 ASDiameter server (as_diameter_server) and the AS Diameter client (as_diameter_client).

(a) IMS I-CSCF supervision struc-ture.

(b) IMS S-CSCF supervision struc-ture.

(c) IMS AS supervision structure.

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. TheHLR 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 tothe static data from the LDAP database and dynamic data provided by Mnesia [24]. Please refer to the concurrentwork thesis report [28] for static LDAP database access details. Details about Mnesia table design for GSM can befound in the section 3.4.

The below table provides an overview of the mapping of the MAP procedures, hlr_db_api calls to the correspondingeLDAP 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

update_locationcancel_locationinsert_sub_data

known_subscriberget_network_access_mode

get_vlr_numberis_subscriber_allowed_roam_plmn

update_routeing_informationdelete_routeing_information

reset_flag_ms_purgedhlr_add_functionality_supportedhlr_pga_functionality_supported

check_ss_requiredget_hlr_number

clear_mnrf

--

roaming_info-

roaming_inforoaming_info

subscriber_statusoperator_informationoperator_informationsubscriber_status

operator_informationsubscriber_status

check_imsi_existscheck_imsi_exists

-get_gsm_profile

--------

send_routeing_informationprovide_roaming_number

known_subscriberget_imsi_given_msisdn

number_changedderive_requested_bscheck_bs_provisionedcheck_ts_provisionedis_operator_baic

is_operator_bic_roamis_operator_bic_roamhzis_baic_bs_provisioned

is_roaming_abroad_activated_bsis_acr_activated_bsis_cfu_bs_active

increment_number_fowardingsis_cfnrc_bs_activeget_gmsc_number

hlr_supports_domain_selectioncheck_prepaging_supported_hlr

get_roaming_data

----------

ss_profiless_profiless_profiless_profiless_profile

operator_informationoperator_informationoperator_information

roaming_info

check_imsi_existscheck_msidsn_existscheck_imsi_existscheck_imsi_existsget_gsm_profileget_gsm_profileget_gsm_profileget_gsm_profileget_gsm_profileget_gsm_profile

---------

purge_ms known_subscriberset_flag_ms_purge_non_gprs

-subscriber_status

check_imsi_exists-

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.2and the other was hosting the HSS/HLR prototype.

Machine CPU RAM HDD spaceHSS/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 inAppendix C.

The HSS/HLR machine run Cent OS 5.5 , Erlang/OTP R15B01 compiled from source with the configuration shownin 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 overCx interface with HSS and AS over Sh interface with the HSS are covered. The interaction among the componentsare highlighted in the figure 3.5.

Section 3.9.1 details about the Diameter UAR, LIR message processing by the Cx Diameter server agenthss_cx_diameter_agent.

Section 3.9.2 details about the Diameter SAR, MAR message processing by the Cx Diameter server agenthss_cx_diameter_agent.

Section 3.9.3 details about the Diameter PUR, SNR and UDR message processing by the Sh server Diameter agenthss_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 thedata can be either to the transparent data / non-transparent data by Cx procedures or Sh procedures. Transparentdata here refers to syntactic understanding of the data, but not semantically by the HSS. Non-transparent data isboth understood semantically as well as syntactically [13] by the IMS HSS. hss_subscription_manager triggers thesubscription 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 asshown 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 workerprocess. The reply from the hss_cx_diameter_server_cb UAA is sent back to the icscf_diameter_client_cbmodule. 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 tothe specifications [11].

LIR/ LIA interaction is shown in the figure A.1, the hss_cx_location_query worker handles the LIR/ LIA Diametercommand.

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 workerprocess. The reply from the hss_cx_diameter_server_cb SAA is sent back to the scscf_diameter_client_cbmodule. 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 workerprocess. The reply from the hss_cx_diameter_server_cb MAA is sent back to the scscf_diameter_client_cbmodule. 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 arehandled by the scscf_diameter_agent and call-back scscf_diameter_server_cb for each request is spawned. Thereplies PPA and RTA are sent by the scscf_diameter_server_cb to the hss_cx_diameter_client_cb. PPR/PPAsequence 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_serverafter 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 workerprocess. 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_agentDiameter stack and callback as_diameter_server_cb module is spawned each request. PNA is sent by the as_diameter_server_cbto 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 updateon non-transparent data from the mnesia worker process in hss_db module spawn a hss_subs_handler process. Thehss_subs_handler process would verify if the non-transparent data update subscription is been currently supportedby performing a dirty read on hss_subscription_configuration. If the non-transparent data category subscriptionis supported, the hss_subs_handler process would trigger the notification procedure hss_sh_notif worker processin 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_serverprocess 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_workersmodule 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 theoperator interface is able to manage resources such as the number of eLDAP client connections and the Mnesiaconfiguration parameters.

mnesia_configuration_manager process has procedures to create schema, initialize Mnesia nodes, create/reset/deleterequired 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 ofthe IMS components role can be a Diameter client or a Diameter server. General Diameter agent APIs are discussedin 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 theeLDAP 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 wouldresult in starting a Diameter service for the client Diameter agent. Service here refers to the locally implementedpeer module, which specifies the Diameter applications (Ex: Diameter Cx Application) it supports and thecapabilities 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’, [? DIAMETER_APP_ID_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 dictionarymodule which specified how to encode and decode the application messages and AVPs and call-back modulewhich handles the incoming the diameter messages for the given Diameter application. Erlang Diameter libraryprovides 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’ - Valueof 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 Diameterserver 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 andRemote 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 , ServerLocalIPAddr },{port , Port}]}];

TransportOptions for connecting transport (Diameter client).

[{ transport_module , sctp | tcp },{ transport_config , [{ip , ClientLocalIPAddr },

{raddr , RemoteServerIPAddr },{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 aDiameter Cx client can send RTR, PPR Diameter messages to the S-CSCF Diameter server and as a DiameterSh 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 configurationpassed while starting the service.RequestMessage is the Diameter message passed, it consists of list of mandatory AVPs, optional AVPs andconditional AVPs. List of the AVPs to be passed for Diameter message pertaining to the Diameter Cx applicationcan 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 subscribedand 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 DiameterCx 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 calledto verify if the updated data is allowed for subscription. If the updated data is allowed for subscription, initiate_notification(UpdatedData,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 transparentdata for given the service indication (which identifies the type of service) by the PUR request or in some cases of SNRrequests.

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 bothstatic 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 dynamicdata accesses.

39

Procedure HSS database API Dynamic data eLDAP query

Cx LIR

check_public_identity_existsget_psi_activation_stateget_public_id_user_statereturn_stored_scscf_nameget_server_capability_list

terminating_services_relatedat least_one_scscf_name_assigned

-service_registration_infouser_registration_infouser_registration_infooperator_specific_datauser_registration_info

public_identity_exists----

impu_existsprivate_identity_exists

Cx UAR

private_user_identity_existsuser_identity_match

user_associationimpu_barred

non_barred_implicit_impuuser_allowed_roam

user_allowed_registerreturn_stored_scscf_name

atlst_impu_scscf_auth_pndng

-------

user_registration_infouser_registration_info

impi_existsimpi_existsimpu_existsimpu_existsimpu_existsimpu_existsimpu_exists

-impu_exists

Cx SAR

private_identity_existsimpu_existspsi_exists

identity_associationis_distinct_impu

psi_activation_statereturn_stored_scscf

store_scscfset_unregistered_stateset_registered_stateassociated_impu

impu_stateset_not_registered_state

is_hss_storing_scscfdownload_user_profile

clear_scscf_name

-----

service_registration_infouser_registration_infouser_registration_infouser_registration_infouser_registration_info

-user_registration_infouser_registration_infooperator_specific_data

-user_registration_info

impi_existsimpu_existspsi_exists

imp(i)u_existsimpu_exists

-----

impi_exists---

get_ims_profile-

Cx MAR

impi_existsimpu_exists

is_distinct_impuuser_association

get_auth_scheme_supportedreturn_stored_scscf

get_auth_key_parametersstore_scscf_name

set_auth_pending_flag

----

operator_specific_datauser_registration_infooperator_specific_datauser_registration_infouser_registration_info

impi_existsimpu_existsimpu_exists

imp(i)u_exists-----

Table 3.3: IMS HSS database API for Cx procedures

40

Procedure HSS database API Dynamic data eLDAP query

Sh UDR

check_as_permissionimpu_existsimpi_exists

multiple_impi_associationdownload_user_data

as_permission_list---

repository

-impu_existsimpi_existsimpi_exists

-Sh PNR remove_subs_data sh_subscription_notify_info -

Sh PUR

check_as_permissionimpu_existsimpi_exists

is_distinct_impuis_transparent_data_under_update

as_permission_list---

repository

-impu_existsimpi_existsimpu_exists

-

Sh SNR

check_as_permissionimpu_existsimpi_exists

get_sh_sub_notif_infoverify_service_data_existsassociate_as_notification

associate_as_notification_updatedeassociate_as_notification

download_user_data

as_permission_list---

repository

-impu_existsimpi_existsimpu_exists

-

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-endtests is described in this section.

Test framework for the performance evaluation is briefly described in the Section 4.1. Components developed as partof the prototype, third-party components (Erlsom, Erlang Diameter Base Application) and end-to-end tests can beconducted 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 primarilymapped onto the eLDAP queries.

Performance analysis of the observed performance for Erlang Diameter applications are analyzed, bottle-necks areidentified in each of the tests. Performance analysis information is covered in the Section 4.6. Advantages anddrawbacks 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 sectionsection:capacity.

Scalability of the FE HSS which is integrated with a BE node is noted in the Section 4.8. FE HSS scalability discussionsrefer to the concurrent thesis work, to learn about the BE performance in terms of throughput, memory usage andthe number of subscribers handled [28]. Scalability of the system is discussed by extrapolating the numbers for 50000IMS 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 clusteralong 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 todo most of the performance testing of the FE HSS and BE LDAP [28]. The Identity Server is run on the samemachine as the Basho-bench client. Hardware configuration can be referred for the Basho-bench client and theFE 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 databasewhich contains the same identities as stored in the BE LDAP backed Berkley Database (BDB). The performance ofthe Identity Server is as observed in the table 4.1. Latency and the throughput observed was sufficiently higher thanthe requirements to run the FE HSS /HLR component and end-to-end tests. As result the Identity Server was notaffecting the test runs run by the Basho-bench client on the same machine.

42

Host Workers Rate Throughput(ops/sec)

Meanlatency(ms)

Basho-bench client 250 100 17800 1.2Basho-bench client 500 500 40270 6Basho-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-benchclient to test any code running at FE HLR/HSS. Example basho-bench driver and configuration can be found in theAppendix B. The Basho-bench client machine can run I-CSCF, S-CSCF or AS and FE HLR/HSS machine can runthe 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 isrun in non-replication, non-mirror mode for the evaluation of the FE HSS/HLR.

Mnesia

(RAM) BDB

Mnesia

(RAM)

Basho bench client

Identity

Server

FE HLR/HSS BE OpenLDAP

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 for10000 subscribers. The same identity-set as in the static subscriber LDAP database was replicated into a in-memoryMnesia database handled by the Identity Server. The subscriber data as depicted in the figure 3.1 consisted of bothIMS 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. Thisresulted 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 Clientmachine (please refer to the client machine hardware configuration in the table 3.2). RPC call to the Identity Serverby the Basho-bench client (please refer to the figure 4.1) resulted in random retrieval of identit(y)ies / identity-pairswhich 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 parameterspertaining to each of the procedures.

The Identity Server performance (refer 4.1) was sufficient to conduct performance tests of both IMS proceduresand 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 ofperformance tests at the required rate as the performance of the Identity Server to fetch the random identities wasvery 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 arefor 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 thetested application at given host.

Operations/sec is the desired (expected) number of operations per second configured for each of the Basho-benchtests (number_of_concurrent_workers × rate).

Scheduler utilization is measured by Observer and shows wall time per scheduler.[25, 22]. Utilization is measuredby 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 Cxinterface and HSS, AS over Sh interface and HSS. TCP was used as the transport protocol to send the diameterapplication 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 requiredidentities (IMPU or/and IMPI) and the FE HSS serves as the Diameter server. The Basho-bench client runs both theIdentity Server and the Diameter client requests. The replies to each of the Diameter message are returned by thestubbed Diameter replies by the FE HSS. This results in performance testing of the Erlang Diameter library providedas part of the R15B release. Diameter Cx procedures UAR, LIR, MAR, SAR and Sh procedures UDR, SNR and PURperformance results will be analyzed in the Section 4.6.1.

44

Interface/ Procedure

Operations/sec

Throughput(ops/sec)

Latency(ms)

FE HSSCPU

utilization(%)

Memoryutilization

(%)

Schedulerutilization% (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 diameterover TCP was used to run Diameter over SCTP. Diameter over SCTP performance results are analyzed in the Section4.6.1.

45

Interface/ Procedure

Operations/sec

Throughput(ops/sec)

Latency(ms)

FE HSSCPU

utilization(%)

Memoryutilization

(%)

Schedulerutilization% (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 theBasho-bench clients (I-CSCF, S-CSCF and AS) as Diameter clients which make Diameter calls to the Diameter serverFE HSS over TCP transport. FE HSS serves the Diameter requests by invoking the required call-backs which resultsin the execution of the corresponding Cx/Sh procedure call. FE HSS machine (please refer to the topology figure4.1) hosts the procedure workers, operator, maintenance functionality, HSS database API(both eLDAP componentsand Mnesia operation handling) as described in the IMS system architecture (please refer to the IMS HSS systemarchitecture 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 requiredXML strings as specified by the schema. Scheduler utilization is as observed by the observer tool for the FE HSSErlang 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

Procedure Ops/sec

Throughput(ops/sec)

MeanLatency(ms)

FE Memoryutilization(MB)

FE CPUutilization

(%)

BE CPUutilization

(%)

Schedulerutilization% (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 hostedby the FE HSS. Diameter protocol is not used by the Diameter clients to communicate with FE HSS instead theRPC calls result in direct invocation of the corresponding procedures. Static data is served by the BE LDAP and thedynamic data is served by the Mnesia.

FE memory utilization and FE CPU utilization is due to the procedure code execution, HSS database API and Mnesiaoperations 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-CSCFand AS) invokes (via RPC) the Cx/Sh interface procedure call in the FE HSS. Identity Server provides the identitiesrequired 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

Procedure Ops/sec

Throughput(ops/sec)

MeanLatency(ms)

FE Memoryutilization(MB)

FE CPUutilization

(%)

BE CPUutilization

(%)

Schedulerutilization% (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 APIis basically check_imsi_exists call, get_imsi_given_msisdn call results in the call check_msisdn_exists and thecheck_bs_provisioned results in the call for get_gsm_profile. Most of the APIs in the HLR database API wereconducted for similar eLDAP calls (please refer to the table 3.1 for HLR database API mapping) . (More informationon performance of eLDAP calls for GSM API can be found in the concurrent thesis work report [28]).

API Ops/sec

Throughput(ops/sec)

Meanlatency(ms)

FE HLRmemoryutilization(MB)

FE HLRCPU

utilization(%)

BECPU

utilization(%)

FE HLRschedulerutilization% , (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 databaseAPI for 1600 ops/sec. Higher memory usage observed for the check_bs_provisioned API as compared to the othertwo 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 Diameterlibrary, End-to-end Diameter performance, End-to-end RPC performance in the IMS domain and the GSM HLRdatabase 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 providesperformance analysis of Erlang Diameter Cx and Sh applications tested over TCP and SCTP as transports. Theseperformance tests are conducted with stub Diameter Cx and Sh procedure request/response messages to evaluate theperformance 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 procedurecall on the FE HSS machine results in

• Throughput throttling when more than 1000 operations/sec are requested. This observation provides an hintthat the single diameter_watchdog process which handles every diameter incoming message as the bottle-neckprocess. 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 morethan 1000 operations/sec. This results in Diameter stack virtually unusable even in moderate loads of more than1000 operations/sec.

• CPU utilization increases when there is an increase of number of operations from 500 to 1000. Throughputincrease also reflects in the increase of CPU utilization from 500 to 1000. After 1000 operations/sec there is noincrease 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 proceduresand stub diameter messages replied over the Diameter Cx/Sh interface. No database API‘s are used since stubdiameter 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 visualizedin 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, followingoptions were modified

• {active, once} caused performance problems , when the {active, once} (to receive one SCTP packet at atime 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} asSCTP socket option causing problems should be done while TCP does not have performance problems withrespect to {active, once} as socket option.

• {recbuf, integer() > 0} is by default 1500 bytes, receiving default window size was not enough to sustainhigher number of operations/sec. When the option was tweaked to {recbuf, 65536} was able to provide therequired 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 chunksinto a single packet (to get more throughput). More information about the sctp_nodelay option can be foundhere [23].

As observed from the tables 4.2 and 4.3, the latencies when SCTP is used as transport are slightly higher andthroughput is slightly lower with SCTP socket options tweaked as mentioned above. Lower performance of SCTP astransport layer for the same diameter messages can be attributed due to the overhead incurred by SCTP in framingmessages. 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 thediameter stack which needs investigation and performance enhancement if the HSS were to handle moderate and highload over 1000 operations/sec.

Advantages

• Provides utilities to for encoding and decoding of AVP. diameterc utility is helpful for transforming the dictionaryfiles 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 respectto 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 notconfigured 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 theErlang Diameter stack performance issues as indicated in the Section 4.6.1. Diameter protocol is the bottle-neckwhen end-to-end performance tests using Diameter are conducted. High CPU intensive Diameter calls such asSAR, MAR (have more processing and hence introduce more delay) have low throughput when compared to theother light-weight procedures such as LIR which neither have Erlsom operations nor the authentication vectorgeneration operation.

• Mean latency increase is observed mainly due to throttling in the diameter stack as the number of concurrentworker operations/sec increase. As seen latency is high for CPU intensive operations (SAR, MAR in relativewith 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 isevident by observing SAR operation at 500 operations/sec and PUR at 500 operations/sec (which has no Erlsomoperations and have few BE LDAP calls). UAR, LIR even with no Erlsom operations have dynamic records tobe 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 doesnot allow high number of concurrent diameter requests to be made and processed. Scheduler utilization thoughshows an increase in the number of cores used by one when compared to diameter performance test alone dueto 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 diameterstack.

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 procedureshave low CPU demands, reason being no XML string generation required in order to process these queries bythe HSS.Sh/PUR, Sh/UDR and Sh/SNR have low Erlsom requirements and have high throughput as the number ofoperations/sec requirement grows.As discussed before in the Section 2.7.2 Erlsom uses considerable amount of CPU as the number of operations/secrequirement grows for XML string generation. Procedures such as Cx/SAR have high requirements of Erlsomas 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 ofoperations/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 throttledfor CPU as shown in the table, the throughput does not increase after requests of more than 1000 MARoperations/sec are requested.

• Mean latency as observed for procedures with high CPU utilization when bottle-necked for CPU results inhigher latencies , for example Diameter Cx SAR. High CPU utilization in case of MAR is due to quintupletauthentication 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 recordswith increase in high number of operations /sec.The procedure SNR has to read subscription_notification_info and retrieve data from repository whichexplains 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 CPUintensive operations at high number of operations/sec request result in throttling and hence almost utilizing theCPU 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 procedureexecution. This is seen in case of SAR at 1000 operations/sec. UAR , UDR procedures which is not constrainedby 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 areutilized to the maximum in case of the SAR procedure even at 1000 operation/sec and in cases of SNR, UDRat 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 DiameterCx LIR.

To serve dynamic data for procedures, Mnesia in-memory database was used. Mnesia in-memory database served theprocedural 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 bytesare 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 singlerepository data item which can be subscribed(SNR), read(UDR) and updated (PUR). With this assumption toserve 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 whichneeds to subscribe to the repository data requires 2896 bytes. For serving 80000 users which subscribe to singlerepository 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 80000distinct 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 databaseAPI (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 distinctidentities. The FE memory utilization as provided by the observer tool includes Virtual Machine (VM) memoryusage, 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 80000users. Number of eLDAP workers run were 640 eLDAP worker processes (16 eLDAP managers * 40 workers managedby each eLDAP manager). Memory requirement for running 640 eLDAP workers which would be sufficient to servethe LIR 2000 operations/sec is 262 MB. More information about the memory requirement of the eLDAP can be foundin 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 identitiesserved here correspond to 10000 IMS subscribers. To server 10000 subscribers, at the rate of 2900 LIR operations/secwith 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 chosenprocedure 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_existsper procedure execution. (refer to hss_db_api to eLDAP query mapping for each of the Cx and Sh procedures in thetable 3.3).

The BE LDAP throughput, memory and capacity aspects as shown in the figure 4.11 are covered in detail as part ofthe 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 blockshown 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 IMSsubscribers.

With given hardware configurations of FE and BE system (without replication in fully-cached mode) can serve 50000IMS subscribers.

To serve 10000 IMS subscribers, as discussed in the Section 4.7, 232 MB of memory is needed for storing theuser_registration_info Mnesia table, for 50000 IMS subscribers 1160 MB of memory for Mnesia table is neededand the 640 eLDAP workers would be sufficient while the procedure memory would not increase as the FE HSS isbound by high CPU utilization (please refer to the table 4.5 for observing end-to-end RPC performance). Thereforethe memory requirements to serve 50000 IMS subscribers LIR requests at the rate of 2900 ops/sec would be sumof 1160 MB (Mnesia table user_registration_info) 206MB of procedure worker memory and 262 MB memoryrequirement 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 mechanismthrough which a FE HSS module can be identified to serve a given subscription request. One such mechanism is loadbalancing 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 andDiameter Sh interfaces respectively. Any diameter request originating from these components would be first consumedby the subscription location analyzer, based on the domain name component of the request originating, the FE HSSnode would be identified. This requires analyzing the Diameter requests, which means application layer packet analysisto 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 onthe traffic analysis, redundant nodes to serve a particular domain can be added. The number of available unique nodeswill depend on the number of domains (location) supported by the given HSS. The number of redundant nodes for agiven FE HSS node would depend on the traffic and the capabilities of the FE HSS node. With load-balancing shownabove, with a single node as stand-by for each of the given FE HSS node, a total of 2×N nodes would be required forN 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 asthe Diameter messages need to be analyzed at the application layer to obtain the domain information and subsequentrouting of the diameter packet to the respective FE HSS node. Though redundant nodes for subscription analyzerminimizes 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. Thisis 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 tomake 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 havebeen 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 followingfeatures

• Specification complianceThe developed IMS HSS prototype provides implementation of the procedures of Diameter Cx interface namelythe UAR, LIR, SAR and MAR. With the implementation of these procedures, location management, user-datamanagement 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, receiveif any notifications on the subscriptions to the updated user-data. Specification compliance is the basic stepwhich 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 PartnershipProject (3GPP).

• Integrated subscription model.The necessity to avoid duplication of subscriber data is prime importance if the operator has to grow hissubscriber numbers and provide large number of services accessible effectively via different technologies. In thisthesis work, IMS and GSM subscribers were considered, hence the duplication of subscriber data had to belooked into the HSS and HLR. A consolidated LDAP DIT for both GSM and IMS subscribers was designedwhich 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 DITdesigned 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 IMSHSS clients. GSM HLR database API have been provided which used the common BE for static subscriber dataand dynamic data (procedural data) required for both GSM and IMS was served using the Mnesia database.

• Classification of dataData 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 intensiverequests was confirmed as the database access protocol to be investigated. (please refer to LDAP efficiency in theconcurrent thesis report [28]). Mnesia as in-memory distributed database was used to handle the dynamic dataclassified. The dynamic data was partitioned into Erlang records, which were stored as Mnesia table entries.

• Performance analysisFE performance has been analyzed and bottle-neck components in the third-party components such as ErlangDiameter 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 messageprocessing at the rate of 1000 operations/sec is clearly not sufficient. An hint to bottle-neck component ofthe 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 requestsare higher than 2000 operations/sec was identified. An highly-efficient XML generating tool is very muchnecessary in-order to provide specification complaint implementation of the procedures. The schema forXML 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 withnull driver, this revealed the discrepancies in the results. Yield inconsistency of the Basho-bench needs tobe investigated.

– Performance analysis along with evaluation of real-time characteristics included discussion about capacityrequirements to serve 10000 IMS subscribers. This was realized by conducting performance evaluation ofthe prototype for 10000 IMS subscribers.

– Scalability discussion for 50000 IMS subscribers was discussed and evaluated (please refer here for scalabilitydiscussion, Section 4.8). Scalability discussion was based on the capacity requirements to serve 10000 IMSsubscribers 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 primaryrequirements when the HLR / HSS product would be deployed to serve in large scale. Subscription locationanalyzer 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 theprototype provide an insight into realization of the product which can be deployed in the large-scale environment.

• TestingBasho-bench as test tool served the purpose of conducting performance tests, stress testing. The test-tool asframework allowed testing each of the components in isolation, end-to-end scenarios were analyzed. Basho-benchtest-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 featuresof a deploy-able product. Issues highlighted for few of the components, third-party tools and prototype have to beinvestigated 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 diametermessages. This is of prime concern if the IMS HSS has to handle more than 1000 operations/sec which isvery 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 socketissues). SCTP as transport for Diameter messages (Erlang Diameter library) is an important feature of theErlang 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 isnot supported [21]. This would help Diameter application developers considerably in debugging transportlayer related issues.

• Subscriber data generationGenerated subscriber data has been configured for worst case scenarios for both storage and from procedure logicperspective. Different configuration of subscriber data with respect to identity association needs to be done.

• Integration - Tieto Signaling System 7 (SS7) stackGSM HLR database API has not been integrated to the HLRprocedure logic and consequently to the MAPinterface of the tieto SS7 stack. This was not done due to time constraints of the thesis period.

• More performance testingScaling and load-balancing aspects as discussed in the Section 4.8 and Section 4.9 respectively have been proposalobserved 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 byconducting horizontal and vertical scaling of resources. Proposed Subscription location analyzer functionality forload-balancing has to be developed and performance tests for the subscription location analyzer module needsto be conducted. Performance due to scaling of resources, testing resilience of the system and load-balancing arevital in-order to transform prototype into a deploy-able product.

• Concurrent mixed procedure testingConcurrent 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 suchas AS and CSCF elements simultaneously was not conducted. As this testing scenario required more numberof IMS HSS clients, in-order to issue concurrent requests to the IMS HSS over the Diameter Cx and DiameterSh interface simultaneously. This is typical of a real-world deployment. Performance of the HSS in this typicalreal-world scenario needs to be conducted and analyzed.

• Automated testingAutomation 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 givencritical 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 configuredfor 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 XMLschema. As observed before with Erlsom performance tests, any measure to reduce CPU utilization wouldbenefit the performance of user-data management procedures of Diameter Cx and Sh interface. ErlsomXML 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 uniformdistribution manner from 1 to 80000 , which is used by the Mnesia Subscriber Server (MSS) to return thepublic-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 = basho_bench_config :get(hss),MSS = basho_bench_config :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 ()]),%5io: 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 installeddirectory.

./ 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 connectioncontrol part formats and codes .

[3] 3GPP. TS 08.58 . http://www.3gpp.org/ftp/Specs/html-info/0858.htm, 2011. Base Station Controler - BaseTransceiver 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 datamanagement. 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 MultimediaSubsystem (IMS). Stage 2.

[10] 3GPP. TS 29.002 V11.1.0. http://www.3gpp.org/ftp/Specs/html-info/29002.htm, 2011. Mobile ApplicationPart (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 basedon 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‘sthesis, Department of Information Technology, Uppsala University, Mobile Arts, Stockholm, 02 2012. This workis 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