RESILIENT AND OPTIMIZED LDAP DATABASE IMPLEMENTATION FOR A LARGE SCALE HLR/HSS - ERIK GRAFSTRÖM - DIVA
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
UPTEC IT 12 018
Examensarbete 30 hp
November 2012
Resilient and optimized LDAP
database implementation for a
large scale HLR/HSS
Erik Grafström
Abstract
Resilient and optimized LDAP database
implementation for a large scale HLR/HSS
Erik Grafström
Teknisk- naturvetenskaplig fakultet
UTH-enheten Telecommunications databases have high requirements
on availability and real-time performance. The database
Besöksadress: implementation must be able to handle millions of active
Ångströmlaboratoriet
Lägerhyddsvägen 1 subscribers and thousands of concurrent database
Hus 4, Plan 0 requests.
Postadress: The purpose of this thesis is to evaluate if LDAP which is
Box 536
751 21 Uppsala a directory-based database technology can be used to
serve consolidated subscriber data in a
Telefon: telecommunications network. A LDAP database service
018 – 471 30 03 with a fault-tolerant and resilient server topology, an
Telefax: Erlang-based LDAP client and test framework has been
018 – 471 30 00 developed to evaluate LDAP in GSM and IMS networks.
Hemsida: The performance of the developed components is
http://www.teknat.uu.se/student
analyzed in terms of throughput, latency, capacity and
hardware requirements. The analysis concludes that
LDAP is feasible as a technology for consolidating and
serving subscriber data in the telecommunications
domain and that Erlang is a powerful tool for
development and testing.
Handledare: Jonas Falkevik
Ämnesgranskare: Tore Risch
Examinator: Arnold Pears
ISSN: 1401-5749, UPTEC IT 12 018
Sponsor: Mobile Arts
Tryckt av: Reprocentralen ITCAcknowledgements
I would like to thank Mobile Arts for giving me the opportunity to do this thesis at their premises and their support.
I would like to thank Jonas Falkevik for his supervision and helping out with resources and troubleshooting.
I would like to thank Tore Risch for reviewing my thesis work.
I would like to thank Erik Hansson for proofreading my report and being the opponent of my presentation.
iContents
1 Introduction 1
1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Document organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5.1 Previous Mobile Arts thesis work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5.2 Proprietary products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5.3 OpenLDAP evaluations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5.4 OpenLDAP compared to other products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5.5 Evaluation of large scale directory services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5.6 MySQL Cluster Carrier Grade Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5.7 Lucent subscriber data consolidation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5.8 SDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5.9 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5.10 Open source HLR and HSS implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5.11 Other papers and presentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2 Technologies and tools 9
2.1 LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1 LDAP server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.2 LDAP client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 OpenLDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 Syncrepl replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2 Multi-Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.3 MirrorMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.4 Syncrepl proxy mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.1 Subscriber management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.2 Call routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.3 GSM subscription model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.1 Subscriber management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.2 Call routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.3 IMS subscription model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5 CAP theorem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6.1 Erlang/OTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6.2 ELDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.6.3 SLAMD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6.4 Basho Bench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6.5 Other tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3 Implementation 27
3.1 System overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2 LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.1 DIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.3 Query examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3 ELDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
ii3.3.1 eldap_manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.2 eldap_worker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.3 eldap_fsm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3.4 Internal data representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4 HLR/HSS front-end integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4 Test setup 42
4.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1.1 Tamintest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1.2 Sarajevsko . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1.3 Jupiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1.4 Mirror1, Mirror2, Replica1 and Replica2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1.5 Koda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2 Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.1 Tamintest test topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.2 Syncrepl test topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3 Test data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3.1 Subscriber generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3.2 MSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4 Test cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4.1 MSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4.2 ELDAP components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4.3 ELDAP FSM components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.4.4 SLAMD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5 Test results and analysis 47
5.1 MSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2 Basho Bench analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3 SLAMD Tamintest test topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.4 SLAMD Syncrepl test topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.5 Tamintest test topology OpenLDAP database back-end evaluation . . . . . . . . . . . . . . . . . . . . 51
5.6 OpenLDAP analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.7 OpenLDAP capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.8 ELDAP components Tamintest test topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.9 ELDAP components Syncrepl test topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.10 ELDAP components analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6 Conclusions and future work 61
A System analysis 62
A.1 Advantages and disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
A.1.1 OpenLDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
A.1.2 ELDAP components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
A.1.3 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
A.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
A.2.1 OpenLDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
A.2.2 ELDAP components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
A.2.3 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
B Litterature overview 66
B.1 Books . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
B.2 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
B.3 RFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
B.4 Other . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
C OpenLDAP configuration examples 69
C.1 Tamintest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
C.2 Mirror1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
C.3 Mirror2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
C.4 Replica2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
D Other 75
iiiD.1 Internal Erlang records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
D.2 Erlang configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
D.3 Koda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
D.4 Evaluation of other testing tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
List of Figures
2.1 Example DIT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Ladder diagram of LDAP client searching for entry on LDAP server. . . . . . . . . . . . . . . . . . . . 11
2.3 OpenLDAP Multi-Master topology with three nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 OpenLDAP MirrorMode topology with two nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5 OpenLDAP syncrepl proxy mode topology with one master and two replica nodes. . . . . . . . . . . . 13
2.6 Simplified overview of the subscriber management and call routing parts of a GSM network. . . . . . . 14
2.7 GSM location update signaling sequence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.8 GSM cell roaming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.9 GSM call setup signaling sequence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.10 GSM subscription models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.11 Simplified overview of the subscriber management and call routing parts of a IMS network. . . . . . . 18
2.12 IMS subscriber registration signaling sequence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.13 IMS partial call setup signaling sequence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.14 IMS subscription model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.15 R digram of Bench Bench run with ets_driver and example configuration. . . . . . . . . . . . . . . . . 25
3.1 Overview of the LDAP server and client architecture with HLR and HSS integration. . . . . . . . . . . 28
3.2 Telecommunications LDAP server topology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Overview of the designed LDAP DIT of static subscriber data. . . . . . . . . . . . . . . . . . . . . . . 29
3.4 UML diagram of LDAP objects and attributes related to the subscribers group. . . . . . . . . . . . . . 31
3.5 UML diagram of LDAP objects and attributes related to the IMS services group. . . . . . . . . . . . . 33
3.6 UML diagram of LDAP objects and attributes related to the profiles group. . . . . . . . . . . . . . . . 34
3.7 The eldap_fsm FSM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.8 Example usage of ELDAP components, a HLR/HSS searches for an IMPU. . . . . . . . . . . . . . . . 41
4.1 Tamintest test topology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2 Syncrepl test topology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.1 15 minute Basho Bench run using scenario B on Tamintest test topology. . . . . . . . . . . . . . . . . 53
5.2 Comparison of SLAMD results between OpenLDAP hosts. . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.3 Basho Bench run visalizing handling of LDAP server faults. . . . . . . . . . . . . . . . . . . . . . . . . 59
5.4 Comparison of performance of ELDAP components using different topologies. . . . . . . . . . . . . . . 60
List of Tables
2.1 Multi-Master advantages and disadvantages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 MirrorMode advantages and disadvantages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Syncrepl proxy mode advantages and disadvantages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1 eldap_worker request matrix. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
iv4.1 Hardware specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.1 MSS measurements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2 Performance of Basho Bench driver basho_bench_driver_null. . . . . . . . . . . . . . . . . . . . . . 48
5.3 Tamintest test topology GSM SLAMD results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.4 Tamintest test topology IMS SLAMD results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.5 Syncrepl test topology GSM SLAMD results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.6 Syncrepl test topology IMS SLAMD results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.7 Tamintest test topology LDAP scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.8 Results for different OpenLDAP settings using Tamintest test topology. . . . . . . . . . . . . . . . . . 52
5.9 Tamintest OpenLDAP capacity for IMS scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.10 Tamintest test topology eldap_fsm_gsm_driver results for IMSI and MSISDN operations. . . . . . . 55
5.11 Tamintest test topology eldap_fsm_ims_driver results for IMPI and IMPU operations. . . . . . . . . 55
5.12 Tamintest test topology eldap_gsm_driver results for IMSI and MSISDN operations. . . . . . . . . . 55
5.13 Tamintest test topology eldap_gsm_driver results for GSM profile operations. . . . . . . . . . . . . . 55
5.14 Tamintest test topology eldap_ims_driver results for IMPI and IMPU operations. . . . . . . . . . . 56
5.15 Tamintest test topology eldap_ims_driver results for IMS profile operations. . . . . . . . . . . . . . . 56
5.16 Syncrepl test topology eldap_fsm_gsm_driver results. . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.17 Syncrepl test topology eldap_fsm_ims_driver results. . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.18 Syncrepl test topology eldap_gsm_driver results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.19 Syncrepl test topology eldap_ims_driver results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.20 Syncrepl test topology eldap_gsm_driver with non optimized number of workers. . . . . . . . . . . . 58
5.21 Syncrepl test topology eldap_ims_driver with non optimized number of workers. . . . . . . . . . . . 58
vGlossary
3GDB The 3Gdb Home Subscriber Server
3GPP The 3rd Generation Partnership Project
ACID Atomicity Consistency Isolation Durability
ACL Access Control List
ADSL Asymmetric Digital Subscriber Line
AN Access Network
ASN.1 Abstract Syntax Notation One
AS Application Server
ATM Asynchronus Transfer Mode
AXE Automatic Cross-Connection Equipment
BAIC Barring of All Incoming Calls
BAOC Barring of All Outgoing Calls
BDB Berkeley Database
BE
BICRoam Barring of Incoming Calls when Roaming outside home PLMN Country
BOICExHC Barring of Outgoing International Calls except those directed to the home PLMN Country
BOICExHZ Barring of Outgoing International Calls except those directed to the home PLMN Zone
BOIC Barring of Outgoing International Calls
BSC Base Station Controller
BSL Basic Service List
BTS Base Transceiver Station
CAMEL Customised Applications for Mobile networks Enhanced Logic
CAP Consistency Availability Partition tolerance
CD Call Deflection
CFB Call Forwarding on mobile subscriber Busy
CFNRc Call Forwarding on mobile subscriber Not Reachable
CFNRy Call Forwarding No Reply
CFU Call Forwarding Unconditional
CLI Command-line Interface
CNF Conjunctive Normal Form
CNSA Core Network Service Authorization
CN Core Network
CPU Central Processing unit
CSCF Call Session Control Function
CSV Comma-separated values
DBMS Database management system
DB DataBase
DIT Directory Information Tree
DNF Disjunctive Normal Form
DN Distinguished Name
DoS Denial-of-Service
EGEE Enabling Grids for E-Science in Europe
ELDAP Erlang LDAP client
ETS Erlang Table Storage system
FSM Finite State Machine
G-MSC Gateway Mobile Switching Center
GPRS General Packet Radio Service
GSM Global System for Mobile Communication
GUP Generic User Profile
viHDB Hierachical Berkeley Database
HDD Hard Disk Drive
HLR Home Location Register
HP Hewlett-Packard
HSS Home Subscriber Server
HTTP Hypertest Tranfser Protocol
I-CSCF Interrogating Call Session Control Function
IBM International Business Machines Corporation
ICCID Integrated Circuit Card Identifier
IFC Initial Filter Criteria
IMAP Internet Message Access Protocol
IMPI IP Multimedia Private Identity
IMPU IP Multimedia Public Identity
IMSI International Mobile Subscriber Identity
IMS IP Multimedia Subsystem
IOPS Input/Output Operations Per Second
IPv6 Internet Protocol version 6
IP Internet Protocol
ITU International Telecommunication Union
K Authentication key Ki
LAI Location Area Identity
LCS Location services
LDAP Lightweight Directory Access Protocol
LDIF LDAP Data Interchange Format
LIR Location-Information-Request
LRU Least Recently Used
MAA Multimedia-Auth-Answer
MAP Mobile Application Part
MAR Multimedia-Auth-Request
MFA Module Function Argument
MSC Mobile Switching Center
MSISDN Mobile Subscriber ISDN Number
MSS Mnesia Subscriber Server
MS Mobile Station
NAI Network Access Identifier
NDB Network Database
OAM Operation, Administration and Maintenance
ODB Operator Determined Barring
OID Oracle Internet Directory
OTP Open Telecom Platform
P-CSCF Proxy Call Session Control Function
PID Process Identifier
PLMN Public Land Mobile Network
POP Post Office Protocol
PSI Public Service Identity
RADIUS Remote Authentication Dial-In User Services
RAID Redundant Array of Independent Disks
RAM Random Access Memory
RDN Relative Distinguished Name
RFC Request For Comment
RPC Remote Procedure Call
RPM Rotations Per Minute
S-CSCF Serving Call Session Control Function
SAA Server-Assignment-Answer
SAR Server-Assignment-Request
SASL Simple Authentication and Security Layer
SDM Subscriber Data Management
SGSN Serving GRPS Support Node
SID Subscriber Identity
SIM Subscriber Identity Module
viiSIP Session Initiation Protocol
SLAMD SLAMD Distributed Load Generation Engine
SLAPD Standalone LDAP Deamon
SMTP Simple Mail Transfer Protocol
SOAP Simple Object Access Protocol
SPT Service Point Trigger
SQL Structured Query Language
SS7 Signaling System 7
SSD Solid-state Drive
SS Supplementary Services
T-MSC Terminating Mobile Switching Center
TCP Transmission Control Protocol
TLS Transport Layer Security
TMSI Temporary Mobile Subscriber Identity
TP Trigger Point
TS Technical Specification
UAA User-Authorization-Answer
UAR User-Authorization-Request
UDC User Data Convergence
UDR User Data Repository
UE User Equipment
UML Unified Modeling Language
UMTS Universal Mobile Telecommunications System
URI Uniform Resource Identifier
URL Uniform Resource Locator
UUID Universally Unique Identifier
V-MSC Visting Mobile Switching Center
VLR Visitor Location Register
VM Virtual Machine
XDM XML Documents Management
XML Extensible Markup Language
viiiChapter 1
Introduction
Mobile phones have been around for decades, the commercialization of Global System for Mobile Communication
(GSM) in 1991 initiated a growth of mobile phone usage. In 2011 the International Telecommunication Union (ITU)
estimated that there were almost 6 billion [104] active mobile phone subscriptions in the world. Ericsson is predicting
50 billion [42] connected devices by 2020. All cellphones contain a Subscriber Identity Module (SIM) card which
contains unique subscriber identities, service information and authentication keys. To enable subscribers to make and
receive calls there must be some network entitity maintaining a register of active subscribers and their current location
and number.
The 3rd Generation Partnership Project (3GPP) [1] is a standardization organization which produces Technical Spec-
ifications (TSs) that defines functional entities and their interworking in telecommunication networks. These TSs are
used by its partners such as telecommunication equipment manufacturers and telecommunication operators to build
national or international telecommunication networks.
Two of the entities which have been specified by 3GPP is the the Home Location Register (HLR) and Home Subscriber
Server (HSS) [2]. The HLR is the central subscriber database in GSM networks and the HSS is an evolved version of
the HLR used in IP Multimedia Subsystem (IMS) networks. Both entities handles call routing, subscriber registration
and system services such as call forwarding. The main difference between a HLR and HSS is the organization of the
subscriber register and the interworking with other networked entities.
The HLR and HSS are specified as separate network entities with no standardized interworking to help with subscriber
management from an telecommunications operator view. This creates a challenge for the operators since the HLR and
HSS are required to handle millions of subscribers on a daily basis with real-time requirements. Subscribers will not
be pleased if the operator is unable to set up a call within a couple of seconds.
1.1 Purpose
The purpose of this thesis is to intregrate subscriber data needed by HLR and HSS into one common repository. To
do this, Lightweight Directory Access Protocol (LDAP) is investigated as a back-end technology to serve the static
portions of subscriber data for both HLR and HSS. Static subscriber data is data which does not change dynamically
in a telecommuncations network such as subscriber identities, service profiles and authentication information. This
data is only changed by the operator when new subscribers are added or when a subscriber changes its directory
number och subscribed services.
The static subscriber data are to be integrated into one common LDAP directory where HLR and HSS front-ends
access the static data using the LDAP protocol. An LDAP client is to be developed to allow front-ends to access
the static subscriber data needed to handle registration and routing requests coming from subscriber equipment. The
front-ends maintain a repository of dynamic data which consists of the subscribers current location and registration
status.
The idea behind a common directory is to simplify subscriber management for the operator, reduce data duplication
in the telecommunications network and improve the availability and reliability of static subscriber data. The make
sure that the subscriber data is always available, a fault-tolerant LDAP server topology is to be defined.
This thesis work is supposed to provide a baseline for concurrent and future thesis work at Mobile Arts. The work done
in this thesis is integrated with thesis HSS Front-End implementation for a large scale common HLR/HSS which aims
1at creating Erlang prototypes of the HLR and HSS front-end components [95]. The front-end thesis components uses
Mnesia [41], which is an Erlang-based database component, to maintain dynamic subscriber data such all subscribers
current network location and registration status. The back-end developed in this thesis provides the front-end with
information such as identity associations, authentication keys and and information about subscribed services such as
voice and data.
The LDAP back-end developed in this thesis provides resilient and optimized read-only static subscriber data repository
via a specialized LDAP server topology for the concurrent front-end thesis. The thesis work also provides an Erlang
LDAP client which is used by the front-end thesis to query static subscriber data when subscribers requests services.
The developed LDAP server and client components are be evaluated using the following domain specific non-functional
requirements:
• Millions of subscribers
• Real-time requirements
• 99.9995% availability
1.2 Scope
To be able to integrate subscriber data, GSM and IMS concepts are to be researched and the specifications understood.
An LDAP schema integrating both HLR and HSS subscription information is to be developed. The LDAP server setup
must be is to be resilient, fault-tolerant and optimized for telcommunications use. To be able to test and integrate
with other system components, an Erlang-based LDAP client is to be developed.
Infrastructure and tests are to be developed and maintained to evaluate the functional and non-functional aspects of
the devoped components such as real-time characteristics, scalability, resilience and capacity. The work is also to be
evaluated from a telecommunication network operators view in terms of maintenance and hardware requirements.
The thesis work is not supposed to cover all telecommunications services specified by 3GPP. Only essential services
such as subscriber registration and call routing are in scope of this thesis. Handling dynamic subscriber data using
the developed LDAP directory is not part of the thesis work. Though these topics are not in scope, how to extend
and improve the thesis work is discussed as future work.
1.3 Method
OpenLDAP, Erlang/OTP, Basho Bench and SLAMD are used as the core development tools. Request For Comments
(RFCs), 3GPP specifications, whitepapers and previous work at Mobile Arts are used as a baseline for design and
implementation.
1.4 Document organization
This document is divided into the following chapters.
Introduction covers the background, purpose and methodology of the thesis work. Related work is summarized.
Technologies and tools describes the used technologies, concepts and tools.
Implementation gives an in-depth explanation of the design and implementation of the LDAP schema, topology
and client.
Test setup covers the hardware, data and test cases used to evaluate LDAP server and client components in certain
topologies.
Test results and analysis describes the test results and discusses observed trends.
Conclusion concludes the thesis work and introduces future work.
Appendices contains further analysis, litterature overview and configuration examples.
21.5 Related work The following sections describe the related work which has been done regarding HLR and HSS implementation and integration, OpenLDAP and LDAP evaluation. Most HLR and HSS implementations are proprietary products but some open source implementations are highlighted. Some work has been done to evaluate OpenLDAP performance, even in the telecommunications domain. The idea of creating a unified central repository of subscriber data to be used by telecommuniaction network components has been a key point of research for 3GPP in the last couple of years. 1.5.1 Previous Mobile Arts thesis work Previous thesis work at Mobile Arts has evaluated different back-ends for a HLR. One thesis evaluated CouchDB [102] as the back-end which stores static subscriber data. Another thesis evaluated Mnesia [41] for storing both dynamic and static subscriber data. This thesis investigates LDAP as the back-end and the previous implementations highlights advantages and disadvan- tages with the other techniques provides a baseline design of subscriber data which is related to this thesis work. 1.5.2 Proprietary products All of the major telecom companies provides HLR and HSS solutions. A few examples are highlighted in the following sections. Ericsson Ericsson is a Swedish telecommunications company founded in 1876 and has around 104000 employees. Ericsson served 1.7 billion [40] subscribers with their HLR product in 2009. Most of Ericssons software use NDB [33] which is a low-level distributed database system. Ericsson also provides a HSS product in its IMS portfolio [36]. The Ericsson HLR was one of the first commercial HLR products and is now widely used and has been reviewed to understand telecommunications requirements which are to be evaluated in this thesis. Huawei Huawei is a Chinese telecommunications company founded in 1988 and has around 140000 employees. Huawei sells both HLR and HSS products as a converged SingleSDB [61] solution. Huaweis HLR [58] is capable of serving hundreds of millions of subscribers. The HSS [59] is compatible with convergence standards and supports SOAP to interface with provisioning systems. As with the Ericsson product, the Huawei products gives an insight of the capacity and data convergence requirements of the HLR and HSS which are used to evaluate the developed LDAP back-end. 1.5.3 OpenLDAP evaluations Symas deployment OpenLDAP was used in a telecommunications deployment in 2005 [55]. The customer had the following requirements: • 3000 queries per second •
The deployed OpenLDAP installation was capable of 16600 queries per second with 3400 out of them being write queries and less than 0.1 millisecond latency on a 150 million entry database. The OpenLDAP developers were not satisfied with the performance and implemented a new lightweight connection dispatcher, better memomory management and the Clock page replacement algorithm was used instead of LRU for the database caches [55]. The same tests were run a year later and throughput was increased to 22000 queries per second (with 4800 writes) on the same hardware. Replication via Syncrepl and dynamic configuration was introduced in OpenLDAP 2.4 to provide better options for high availability, fault-tolerance and performance. This Symas evaluation has been instrumental in understanding how OpenLDAP handles telecommunications require- ments and what has been done in OpenLDAP 2.4 for further improve OpenLDAP in telecommunications scenarios which is used in this thesis work. HP deployment Wolfgang Hummel presented Large Scale High Performance OpenLDAP - A real production world experience [110] at LDAPCon 2011. The presentation is one of the rare occurences where OpenLDAP is discussed in the telecommunica- tions environment in the last few years. Previous discussions of OpenLDAP performance had been limited to mailing list discussions and tests in the late 90s and the Symas deployment in 2005. The presentation covers the deployment and benchmarking of a real world deployment for a telecommunications company. The subscriber data was kept in two databases with 35 million subscriber profiles each. The data was served by 2 master servers and 2 read-only servers. The requirements from the telecommunications company were as follows: • Read operations with
This evaluation of OpenLDAP showed that OpenLDAP scales up properly with more hardware and handles with
telecommunication requirements well. It explains how different topologies perform and the results have been used as
a baseline for this thesis work.
OpenLDAP 2.1.21 benchmarks
Andreas Krennmair and Rainer Lischka evaluated OpenLDAP 2.1.21 performance in in their Testing OpenLDAP for
Performance [25] paper. Their paper describes a number of benchmark scenarios and evaluated performance on a
single server. Exhaustive testing on multiple servers were not run since the benchmarking tool was unable to handle
referrals for write operations. The schema was simple and the maximum amount of objects in the database during
tests was 100000. The paper highlights the following items:
• OpenLDAP handles multiple connections up to a ceratin limit
• Indices decreases write performance but increases read performance
• Mixed read/write tests highlights poor write performance (especially in 90/10 ratio)
• Testing OpenLDAP is time-consuming
• Bulk insertion of entries is slow
• Setting up slaves increases performance and the number of clients which can be served linearly
This evalation is very much related to this thesis work since it provides a reference of advantages and disadvantages
of OpenLDAP which is evaluated in this thesis.
OpenLDAP 2.0.27 evaluation
Ehm, Field and Schulz at CERN evaluated the scalability and performance of OpenLDAP in the EGEE Information
System deployment [44]. The system served 251 sites and 1428 service. The team evaluated performance with or
without indices enabled, increased number of connections and query size. The following conclusions were drawn:
• OpenLDAP scales well with the number of cores available
• Indices improves read performance by nearly two orders of magnitude
• Response time under load is stable
• OpenLDAP’s performance would be acceptable if the dataset is doubled
This evaluation indicated that the behaviour of OpenLDAP was stable under high load and that indices should be
used, which is used as a baseline assumption for this thesis work.
OpenLDAP 1.2 evaluation
The Measurement and Analysis of LDAP Performance [112] article is one of the first and in-depth evaluations of
OpenLDAP performance and behaviour done in 2000. The paper describes the testbed and tests are analyzed in
terms och throughput and latency. Different directory sizes, number of clients and cache settings are evaluated as
well as vertical scalability (CPU and memory). OpenLDAPs slapd process is profiled and analyzed in terms of
encoding/decodign, database lookups and communication. The following observation were made:
• Session re-use is an efficient way of increasing throughput
• Disabling Nagles algorithm reduced latency
• Entry caching is effective, even if the directory is not fully cached
• Increases in directory and entry size decreases overall performance.
A couple of important trends were analyzed in this evaluation which affected the design and use of OpenLDAP caches
in this thesis work.
51.5.4 OpenLDAP compared to other products
Howard Chu compared OpenLDAP, FedoraDS, ApacheDS and OpenDS in 2007 [57] and concluded that OpenLDAP
was significantly faster in all aspects (authentication rate, search rate, latency and database load times).
Symas compared OpenLDAP and Fedora DS in 2007 [99] and showed that OpenLDAP has lower database load time,
higher authentication and search rates than Federa Directory Server.
Thornton, Mundy and Chadwick analyzed 7 LDAP server products in 2003 [34]. OpenLDAP performed wery well
compared to products by Microsoft, IBM and Novell.
Norbert Klasen compared OpenLDAP to Microsoft and Novell alternatives in 2001 [82] and concluded that OpenLDAP
would need more work to compete in performance and features.
All of these comparisions are related to the thesis work since they confirm that OpenLDAP is the fastest open source
LDAP server. They introduce a baseline of tests needed to evaluate OpenLDAP performance which is a major part
of the thesis work.
1.5.5 Evaluation of large scale directory services
In a series of whitepapers during the last couple of years, Oracle has showed that LDAP can be used in large scale
deployments using their Oracle Internet Directory (OID) product. OID [92] is an LDAP-capable middle-ware which
uses Oracles renowned database back-end. All of the Oracle tests were conducted with SLAMD, see Section 2.6.3
for more details about SLAMD. The following sections describe the most interesting OID whitepapers which are
related to this thesis work. They cover handling of large directory sizes and how to efficiently test and evaluate LDAP
performance with SLAMD which is re-used in this thesis.
2 billion entry directory
In 2008 [93], Oracle showed that the OID is capable of handling 2 billion entries in its LDAP directory. The test
results are impressive just as the amount of hardware needed to run OID testbed. OID was capable of serving 101000
searches per second, 14000 modifications per second and 16000 clients with minor performance degradation. One
major flaw with the search test conducted is that all serches were sequential.
500 million entry directory
In 2011 [91], Oracle used Facebook as an example to showcase the performance and features of the OID. Oracles
Exadata Database machine and version 11g of OID was used. The system was capable of around 433684 random
searches per second while handling 100000 concurrent clients. Random write throughput was shown to be as low as
12059 operations per second.
1.5.6 MySQL Cluster Carrier Grade Edition
The proprietary MySQL Cluster Carrier Grade Edition [90] product fullfills all telecom requirements and is endorsed
by telecommunication operators such as Telenor and Virgin mobile. It can be used as an OpenLDAP back-end [100],
inheriting all of the scalability and performance advantages of MySQL Cluster Carrier Grade Edition.
MySQL Cluster is based on NDB technology which was developed by Mikael Ronström at Ericsson in 1997 [79].
Ronström analyzed the database requirements of the overall telecommunications platform at the time which was a
mixture of GSM deployments and UMTS research. The database had to be reliable, scalable, fast and able to maintain
large amount of data.
The developed NDB technology was tested in Ericssons AXE research group with promising results. The techonology
could also be used in other domains. NDB was incorporated into MySQL Cluster in 2004 and Ronstrom has conducted
a series of performance tests since the inception of MySQL cluster. A test was conducted in May 2012 where 8 powerful
Xeon nodes attained a throughput of 71 million read transactions per second and 19.5 million update transactions per
second on a 30 node cluster.
This product is related to the thesis work since it shows how OpenLDAP could be set up together with MySQL Cluster
Carrier Grade Edition to improve its telecommunications performance as an alternative to the standard OpenLDAP
database options.
61.5.7 Lucent subscriber data consolidation
Lucent evaluated LDAP as a back-end component of a telecommunications database back-end where subscriber data
is converged into a central Datagrid [30] repository. The article describes the problem of decentralized repositories
of subscriber data. The Datagrid solution would provide a central LDAP repository capable of managing subscriber
data for converged 2G/3G and 4G networks. The article concludes with the following points:
• Allows for creation of richer network services based on the variety of subscriber data kept in Datagrid
• Unified management of subscriber data across the network services reducing operational expenses
• Reduced cost of data mining
This evaluation is related to this thesis work since it shows how LDAP can be used to consolidate data is part of the
purpose of the common LDAP back-end investigated in this thesis.
1.5.8 SDM
The major telecommunications companies provdes Subscriber Data Management (SDM) products and services, where
the key point is that suscriber data is gathered in one central open repository. A description of the offerings follows.
Nokia SDM [81] provides a unified subscriber data layer accross appliactions.
Ericsson User Data Management [37] provides a UDC solution for 2G/3G/4G and fixed networks.
Huawei SingleSDB [60] provides a UDC compliant solution for nodes such as the HLR and HSS.
These SDM products are related to the thesis work since the back-end LDAP database is supposed consilidate subscribe
data in on central register to minimize data duplication among HLR and HSS components.
1.5.9 3GPP
3GPP has specified two alternatives for data consolidation in a telecommunications network, GUP and User Data
Convergence (UDC). A description of the techonologies follows.
GUP [9] is a generic representation of subscriber data. SOAP is specified as the protocol to use when requesting
data from the GUP repository [14]. A GUP consists of GUP components, one example is the HSS component
which is a XML view of HSS data.
UDC [10] is a complete overhaul of how subscriber data is handled in a telecommunications network. UDC consists
of two components, the User Data Repository (UDR) which is the database component and application front-
ends which handles 2G/3G/4G queries. An example would be a HSS quering the UDR for subscriber profile
information when the subscriber attaches to the network.
The main concern when UDC was designed was to remove the old concept of storing subscriber data and
executing application logic in the same node (HLR and HSS core design). This would reduce maintenence costs
and further improve the availability of subscriber data. The LDAP protcol is chosen to enable searches, updates
and creation of data in the UDR [16]. Ericsson is one of the big suppliers which use UDC to converge 2G, 3G,
LTE, Wi-Fi and IMS users profile information and database services [37].
This 3GPP work has been used to understand the network requirements when consolidating subscriber data as in this
thesis. It also shows how far the standardization of data consilidation have progressed.
1.5.10 Open source HLR and HSS implementations
The section covers the freely available open source HLR and HSS implementations.
7OpenSS7 HLR
The OpenSS7 [88] project has designed and implementad a high performance HLR. The HLR is designed to support all
of the standardized interworking and handling up 15 million subscribers with carrier grade performance and availability
requirements. The project shows that "anyone" can implement a fully featured HLR since the 3GPP specifications are
public.
Osmocom HLR
The Osmocom [94] team has implemented a HLR as part of their network-in-a-box OpenBSC software platform. It is
a simple sqlite database which maintains equipment and subscriber information.
3GDB
3GDB [108] is an Erlang-based HSS implementation which consists application logic and a Mnesia database which
contains subscriber information and registrations status.
FOKUS
The Fraunhofer FOKUS institute runs several IMS related projects. One of them is Open IMS Core [46] which
provides a complete IMS framework where IMS applications can be developed and evaluated. Open IMS Core consists
of Java implementations of HSS, I-CSCF, S-CSCF and P-CSCF. The HSS uses a MySQL database back-end which
maintans subscriber registration status and subscriber profiles. The MySQL back-end is designed from the 3GPP IMS
specifications and the interworking is implemented as per specification. LDAP is considered as one of the alternatives
to replace the MySQL back-end [47].
All of these implementations are relevant to this thesis since they all have a database design and implementation to
review and evaluate even if none of them are based on LDAP.
1.5.11 Other papers and presentations
An overview of the evolution of telecommunications databases is covered in an article by Vrábel, Vargic, and Kotuliak.
The paper [21] explains the current problems and the proposed solutions such as XML Documents Management (XDM)
and GUP.
The paper LDAP Schema Design [26] by Andrew Findlay gives and exhaustive walkthrough of how to design and
implement a LDAP DIT and schema.
Giovanni Baruzzi cover LDAP schema design in his presentation Design of a Directory Information Tree [51]. The
material discusses the requirements and design process and best practices in schema design.
Capan and Skomeršić evaluated LDAP as an authentication back-end for SIP registrar servers via RADIUS [63]. The
evaluation covered performance and scalability and concluded that LDAP is viable as an authentication back-end.
Andreas Diehl and Franz-Josef Banet’s paper A Flexible Object-Oriented Data Model for a Centralized Subscriber
Profile Database [24] gives an example of how subscriber data and profile data can be modeled for centralized storage.
The approach is similiar to the contemporary work by 3GPP on UDC.
Two Huawei engineers discuss the necessity of consolidating subscriber data in their papers FMC HSS - The IMS Brain
[97] and Convergent data center for future network [111]. Both papers illustrate the issue of decentralized subscriber
data storage and management and provides examples of how to design a data layer capable of all telecommunications
services.
These papers have been used to further understand how LDAP can be used and how GSM and IMS data can be
organized which is a major part of this thesis work.
8Chapter 2
Technologies and tools
This chapter covers LDAP, OpenLDAP, GSM and IMS technologies with examples of concepts and techniques used
in the thesis.
2.1 LDAP
Lightweight Directory Access Protocol (LDAP) [66] is a protocol for accessing directory services. It was created as a
simple alternative to the more complex X.500 protocol for accessing X.500 directory services over TCP/IP. An LDAP
server maintains a directory of data which an LDAP client can query using the ASN.1 encoded protocol. LDAP
version 3 was standardized in 2006 and enhanced the extensibility and security mechanisms of the protocol.
LDAP selected for this thesis because of its powerful search filter syntax and the directory database implementation
which fits the basic design of a telecommunication subscriber register.
2.1.1 LDAP server
The server maintains a Directory Information Tree (DIT), an example DIT of pear.com is shown in Figure 2.1. The
DIT models a company by the use of structural object classes. In this case pear is a Domain Component and child
of the com Domain Component. pear has two Organizational Units, employees and servers. These objects classes are
defined as structural object classes which define the hierarchy of the directory.
pear.com has two employees (Erik and John) and one server (mail) which are put in under employees and sev-
ers respetively in the DIT. The entry erik is an instance of the object class Person. Each instance of Person
has a set of required attributes such as uid, name, office number and password. One of these attributes is cho-
sen as the Relative Distinguished Name (RDN) and together with its parent objects it will create a unique DN,
uid=erik,ou=employees,dc=pear,dc=com.
The LDAP schema specifies these objects and attributes and their relation. The LDAP server stores the entries in a
database to be queried by a LDAP client.
This is what is used in the thesis, a LDAP server topology is configured and a LDAP client is developed to query a
directory of both GSM and IMS subscribers.
9Figure 2.1: Example DIT.
2.1.2 LDAP client
The LDAP protocol defines the following client operations;
Bind authenticates a session
Unbind closes a session
Search searches for entries
Modify modifies a certain entry
Add adds a new entry
Delete deletes an entry
ModifyDN modifies a DN
Compare compare attributes
Abandon aborts operation
Extended is used for extended operations, one example is interactive password change
StartTLS initiates a TLS session
An Erlang-based LDAP client component is developed in this thesis which handles connections, encoding and decoding
av ASN.1 LDAP Search operations.
Figure 2.2 shows a search query sequence after a TCP connection has been established between a LDAP client and
server. The search query contains the following parameters.
base="ou=employees,dc=pear,dc=com" specifies that the search should start at the employees organizational unit
in the DIT.
scope=singleLevel specifies that the scope of the search is one level below of employees in the DIT.
filter="uid=erik" specifies that only entries with uid attribute matching erik should be returned.
attributes=* specifies that all attributes of the matched object is to be returned.
10Figure 2.2: Ladder diagram of LDAP client searching for entry on LDAP server.
The search result returned by the client could look like Listing 2.1 which is in LDIF format.
dn : uid = erik , ou = employees , dc = pear , dc = com
uid : erik
name : Erik
office : 4711
password : secret
Listing 2.1: LDAP client output.
2.2 OpenLDAP
OpenLDAP [87] is an open source suite of a LDAP server, client and libraries. The main component is slapd which is
a LDAP version 3 compatible server which is used to serve the back-end directory developed in this thesis. The CLI
tools and reference client are used to populate the developed directory and test client-server requests. The OpenLDAP
foundation provides excellent libraries and documentation [87]. How to run and configure OpenLDAP is covered in
its Administrator’s Guide [87] or in books such as Mastering LDAP [76].
OpenLDAP supports several database back-ends where bdb and hdb are the default alternatives. Berkeley Database
(BDB) [89] is a key/value database currently maintained by Oracle. HDB is an improved version of BDB which
handles rename operations more efficiently [84]..
Other back-ends such as ndb (to be used with MySQL Cluster), mdb (in-memory database), ldap (proxying requests),
sql (to be used with any SQL DBMS) can be used in specialized setups.
OpenLDAP supports Simple Authentication and Security Layer (SASL) and Transport Layer Security (TLS) security
mechanisms. Fine grained access control is handled by ACLs. OpenLDAP supports dynamic configuration by the use
of seprate configuration directory which allows administrators to reconfigure slapd while it is running.
OpenLDAP utilizes several caches, both in slapd and its database back-end such as BDB. Attributes can be indexed
to improve search performance.
OpenLDAP uses overlays [85] to provide services such as access/audit logging, attribute constraints, referential in-
tegrity, dynamic groups and password policies. One of the most useful overlays is the sync provider (Syncrepl).
OpenLDAP offers several replication strategies such as Multi-Master, MirrorMode and Syncrepl proxy mode via Syn-
crepl [86, 49]. OpenLDAP provides high availability, fault-tolerance and resilience via the first two strategies since
data is available and consistent even if all but on node fails. Syncrepl will autmatically synchronize the nodes if they
were crashed and restared, even if the consumer database was lost in the crash.
OpenLDAP is used to implement and serve the developed integrated GSM and IMS subscriber data directory.
112.2.1 Syncrepl replication
OpenLDAP refers to its replication and synchronization technique as syncrepl which is specified in RFC 4533 and
replaces previous inadequate techniques. Syncrepl is a consumer-based technique which uses the sync operation to
maintain a copy of the masters DIT. Syncrepl is stateful and supports both pull and push-based synchronization. The
techique does not use history logs, but instead uses syncronization cookies which uniquely identifies modifications of
objects. Syncrepl can be used together with access logs to provide information about what has been changed, enabling
consumers to identity which attributes has been changed and only modify that attribute. This is called delta-syncrepl
and reduces the amount of data sent between servers.
Syncrepl is used in this thesis to setup mirror nodes for resilience, fault-tolerance and to scale horizontally with replica
nodes.
2.2.2 Multi-Master
2 to n nodes can be configured as provider and consumer of each other in a Multi-Master configuration. An example
topology with 3 nodes (mirror1, mirror2 and mirror3) in Multi-Master configuration be seen in Figure 2.3 and its main
advantages and disadvantages are compared in Table 2.1. The LDAP client can connect to any of the master nodes
and do read/write operations.
Figure 2.3: OpenLDAP Multi-Master topology with three nodes.
Advantages Disadvantages
High availability -
No single point of failure Cost of replication and nodes
Continued operation in case of node failure Eventual consistency
Master nodes can be spread geographically Network partitioning
Table 2.1: Multi-Master advantages and disadvantages.
Mult-Master is not used in this thesis because of the consistency issues. It has been tested but uses more complex
configuration.
2.2.3 MirrorMode
As seen in Figure 2.4 two mirror nodes (mirror1 and mirror2) are set up as providers and consumers of each other in
MirrorMode configuration. A front-end is used to redirect writes to the active node and will automatically switch if
one node fails and then synchronize when the failed node starts up again. Some of the advantages and disadvantages
of MirrorMode are covered in Table 2.2.
12Figure 2.4: OpenLDAP MirrorMode topology with two nodes.
Advantages Disadvantages
High availability Only one node accepting writes
Continued operation in case of node failure Need of fail-over mechanism
Mirror nodes can be spread out geographically -
Table 2.2: MirrorMode advantages and disadvantages.
MirrorMode is used in this thesis to provide resilience and fault-tolereance. It is also the bet suited topology since
updates to data is only done by the opererator which minimizes the amount of replication traffic compared to Multi-
Master.
2.2.4 Syncrepl proxy mode
Syncrepl proxy mode can be used to create a read-only replica node. By using the chaining overlay, the replica can
follow referrals and update entries at a master node. Figure 2.5 shows an example topology with one master and
two read-only replicas replica nodes. LDAP client 1 binds to proxy1.operator.com and if there is a write operation
requested it will be chained to the master node master1.operator.com. The advantages and disadvantages of this setup
is shown in Table 2.3
Figure 2.5: OpenLDAP syncrepl proxy mode topology with one master and two replica nodes.
13Advantages Disadvantages
High availability Single point of failure (master1)
High performance Congestion at master node
Replica nodes can be spread out geographically Network partitioning
Table 2.3: Syncrepl proxy mode advantages and disadvantages.
Syncrepl proxy mode is used in the thesis to set up read-only replicas which enables horizontal scalability.
2.3 GSM
Global System for Mobile Communication (GSM) is a collection of functional network entities, see Figure 2.6 for a
simplified overview of the components required for base signaling such as attaching to a network and making a call
[2]. The entities are grouped into the Core Network (CN) and Access Network (AN). The Mobile Station (MS) is the
end-user device which is identified by its Subscriber Identity Module (SIM) which contains Integrated Circuit Card
Identifier (ICCID), International Mobile Subscriber Identity (IMSI), Authentication key Ki (K), Temporary Mobile
Subscriber Identity (TMSI), Location Area Identity (LAI), messages and contacts.
Figure 2.6: Simplified overview of the subscriber management and call routing parts of a GSM network.
The AN consists of two nodes, the Base Transceiver Station (BTS) and the Base Station Controller (BSC). The BTS
is the cell tower which handles radio signaling to and from the MSs. The BTS is controlled by the BSC which manages
hundreds of BTSs, handling radio channel allocation and handovers between BTSs. The BSC forwards requests from
MSs to a certain MSC in the CN using protocols specified by 3GPP.
The CN consists of four entities, Visting Mobile Switching Center (V-MSC), Gateway Mobile Switching Center
(G-MSC), Terminating Mobile Switching Center (T-MSC) and Home Location Register (HLR). The main func-
tionality of a Mobile Switching Center (MSC) is subscriber management and call handling. The V-MSC and T-MSC
has a local VLR which is a register of subscribers served by this certain MSC. The HLR provides services such as call
routing, subscriber roaming and forwarding services for all known subscribers in an operator network. The interfaces
between the CN entities use MAP, which is a protocol specified by 3GPP. GSM uses SS7 as a bearer for all signaling,
which is specified by ITU.
The GSM concepts have been analyzed to determine the type of requests and use cases which are needed to test the
developed LDAP back-end.
2.3.1 Subscriber management
When a subscribers attaches (MS is powered on in radio coverage), a location update message comes from the AN with
details about the subscriber and network. To allow the subscriber to register the MSC sends a location update request
14to the HLR as seen in Figure 2.7. The HLR will look up the subscriber and if it is currently registered in another
VLR it will send a cancel location message to the old VLR. The HLR will then respond with a insert subscriber data
message to the new VLR with all subscriber details such as Mobile Subscriber ISDN Number (MSISDN) which enables
the MSC to fully serve the subscriber.
Authentication is not shown in the example, it is handled by the VLR which will request authentication vectors from
the HLR when need. These vectors are used to challenge the MS to authenticate itself and the VLR will only continue
the registration procedure if the authentication respone was correct.
Figure 2.7: GSM location update signaling sequence.
Subscriber roaming is handled by the HLR. In compliance with the signaling sequence in Figure 2.7 the HLR is
involved when subscribers roam into other geographical cell areas managed by other BTSs and BSC. An example
can be seen in Figure 2.8. If a subscriber moves from the Polacksbacken cell area into Boländerna a location update
sequence will be initiated by MSC-2 and the VLR in MSC-1 will be instructed to remove its information about the
subscriber since it is now served by MSC-2
The subscriber management scenario highlights the type of data the HLR and the developed LDAP schema is required
to handle.
15You can also read
