Guide to Developing Subscriber Databases

with MySQL Cluster

Delivering Personalized Services on Next Generation Networks

A MySQL Technical Whitepaper

Copyright © 2009, Sun Microsystems

 Table of Contents Page #

1. Executive Summary..........................................................................................................................3
2. Introducing The MySQL Cluster Database..................................................................................... 4
3. Why Use MySQL Cluster CGE for Subscriber Databases?........................................................... 5
3.1.Benefits of MySQL Cluster to Subscriber Databases....................................................6
4. Linear Scalability in a Shared-Nothing, Distributed Database.....................................................7
4.1.Distribution Awareness in MySQL Cluster ....................................................................8
5. Creating Tables Partitioned by Subscriber-ID.............................................................................. 11
6. Improved Scalability with Distribution-Awareness...................................................................... 12
7. Conclusion...................................................................................................................................... 13
8. Additional Resources .................................................................................................................... 14
9. Glossary.......................................................................................................................................... 15

Copyright © 2009, Sun Microsystems Page 2

 1. Executive Summary
Call it integration. Call it convergence. Call it simply the next step in the evolution of the communications industry. But
Communications Service Providers (CSPs) and Telecoms Equipment Manufacturers are feeling the effect of new
trends and new technologies - both the new possibilities that they create and the challenges they present.
At the center of it all is the issue of data management. How well you manage your data determines how efficient you
can be, how flexible you can be, how nimbly you can create and offer new services, and how effectively you can mine
customer information for added insight.
In today's communications marketplace, the killer application to drive increased revenue and ARPU is the one most
valued by each individual subscriber – the reality is that personalization and targeting of unique services to individual
subscribers ultimately drives adoption and monetization.
The only way to deliver highly personalized communication services is to create and maintain a unified, 360 degree
view of the subscriber. Not just their identity and billing information, but also their service entitlements, preferences,
presence, usage patterns, contacts, device information, etc.
All of this subscriber information exists today, but is scattered across multiple data stores, including HLR/HSS, CRM
systems, network elements, AAA (RADIUS, DIAMETER, etc) systems, LDAP
Examples of Telecoms Applications using
servers and portals.
MySQL Cluster:
Consolidating this data into fewer centralized databases is critical to accelerate – Subscriber Databases (HLR/HSS)
service delivery, reduce operational expense and enhance personalization and – Telecoms Application Servers
targeting. – AAA & LDAP Databases
– IMS Services
In this paper we describe how MySQL Cluster Carrier Grade Edition (CGE) can
– Intelligent Network Nodes
be used to build scalable, highly available, geographically replicated Subscriber
Databases. We show how user-defined partitioning and distribution keys help a – IPTV & VoD
subscriber database to scale performance linearly with cluster size, while – Location & Presence Services
maintaining the benefits of a relational database, accessed via an industry – Application Stores & Portals
standard SQL API1. – Soft-Switches
– VoIP
Communications Service Providers’ (CSPs) subscriber systems have extreme
requirements on the underlying database, including:
– 99.999% availability
– Scalability to handle millions of subscribers
– Strict low latency bounds on data access.
In addition to these challenges, subscriber databases need to be easy to integrate into existing systems and run on
low-cost commodity off-the shelf (COTS) hardware.
MySQL Cluster CGE is a distributed, highly available real-time database, which is deployed in some of the most
demanding subscriber database systems found in the telecommunications industry. Every day, MySQL Cluster is
handling many millions of subscribers, providing unrivaled performance and quality of service, while meeting the need
for increasing scale as CSPs extend their reach globally.
By exploiting the distributed architecture and real time
“The selected database would need to initially handle the information of design of the MySQL Cluster database, and coupling
7 to 8 million subscribers and to subsequently scale to handle more these with advanced techniques to enable distribution
than 50 million subscribers! MySQL Cluster won the performance test awareness in applications, it is possible to build highly
hands-down and it fitted our needs perfectly. The combination of scalable and highly available real-time subscriber-
accessing data in memory and backing it up on disk makes MySQL
services on low cost commodity hardware and open
Cluster an ideal solution for our subscriber database platform.
Moreover, competing alternatives offered inferior performance at a source software.
higher cost”.
Alain Chastagner, Systems Manager, Alcatel-Lucent

1
In proprietary subscriber systems, data typically has to be offloaded to an external relational database in to perform complex SQL queries, e.g., for
accounting or other BSS purposes.

Copyright © 2009, Sun Microsystems Page 3

 2. Introducing The MySQL Cluster Database
MySQL Cluster is a real-time, distributed database combining the flexibility of a highly available relational database with
the low TCO of open source.

Featuring a “shared-nothing” distributed architecture with no single point of failure, MySQL Cluster is designed to
deliver 99.999% availability demanded by telecommunications services.

MySQL Cluster's real-time design delivers predictable, millisecond response times with the ability to service tens of
thousands of transactions per second. Support for in-memory and disk based data, automatic data partitioning with
load balancing and the ability to add nodes to a running cluster with zero downtime allows linear database scalability to
handle the most unpredictable telecoms services and applications.

MySQL Cluster is already proven in the toughest telecommunications environments delivering higher database
throughput and faster response times at 10x lower cost than proprietary clustered shared-disk databases2, with the
added benefit of running on commodity hardware and operating systems. Customers include Alcatel Lucent, Cisco,
Deutsche Telekom, Ericsson, Nokia Siemens Networks, Nortel, Telenor and UTStarcom.

Figure 1: The MySQL Cluster architecture eliminates any single point of failure

To learn more about the MySQL Cluster architecture, refer to the MySQL Cluster Architecture and New Features
whitepaper posted at:
http://www.mysql.com/why-mysql/white-papers/mysql_wp_cluster7_architecture.php

“Telenor has found MySQL Cluster to be the best

performing database in the world for our applications”.

Peter Eriksson, Manager of Network Provisioning,

Telenor

2
http://www.mysql.com/why-mysql/case-studies/mysql-cs-alcatel.php

Copyright © 2009, Sun Microsystems Page 4

 3. Why Use MySQL Cluster CGE for Subscriber Databases?
A subscriber database aims to consolidate relevant subscriber information, including among other things: address,
account status, profile, preferences, contacts, device data and the provisioned services. An illustrative example of
MySQL Cluster Carrier Grade Edition managing subscriber data for multiple communication services can be seen in
the figure below.

Figure 2: MySQL Cluster CGE powers the subscriber database used by multiple telecommunications services

Referring to the figure above, MySQL Cluster CGE implements specific capabilities to build highly scalable and reliable
subscriber services:
NDB API provides real-time access to data stored within the MySQL Cluster database. The NDB API is also easily
integrated with Subscriber-style APIs, such as LDAP, via a series of drivers developed by the leading open source
directory vendors and communities, including OpenDS and OpenLDAP3.
NDB API provides specialized features, which provide significant performance optimizations not available in the SQL
API or traditional ODBC / JDBC connectors. These include:
– Batching of operations inside transactions to optimize network usage, and significantly improve transactional
throughput
– An adaptive-send buffer at clients to optimize use of the network medium
– Distribution-aware transactions, through partitioning by key, distribution keys and controlling parallelism in
scans (discussed in detail in sections 4 and 5 of this Guide).
Real-Time SQL API using a MySQL Server is a simple and efficient means of enabling a range of applications to
access subscriber data stored in MySQL Cluster. Provisioning requests, AAA (Authentication, Authorization and
Accounting) protocols such as RADIUS and Diameter, in addition to a range of BSS applications can make use of the
SQL API to provide standard access to data stored in MySQL Cluster.

http://www.mysql.com/products/database/cluster/features.html#data_ldap
3

Copyright © 2009, Sun Microsystems Page 5

The MGM API is the management interface to MySQL Cluster, and can be used to monitor and maintain a cluster.
Typically systems such as a Home Subscriber Server control, monitor, analyze and manage a subscriber database
using the MGM API, and these systems, in turn, are integrated into an OSS.
Geographic Replication is supported through MySQL’s replication of an active cluster to a remote cluster, which may
be active or standby. As Geographic Replication in MySQL Cluster supports Conflict Resolution and Detection, most
users run active/active configurations where each cluster handles a sub-set of the traffic.
MySQL replication handles the catastrophic event of a site failure, where monitoring systems can fail-over subscriber-
related traffic from one site to another. Redundant MySQL servers can be installed to handle the failure of a replicating
MySQL server. MySQL servers implement replication using row-based replication, new in MySQL Server 5.1.
In addition to handling Disaster Recovery scenarios, MySQL Cluster's geographic replication capability can be used to
distribute data physically closer to the subscribers that are being served, thereby reducing affects of network latency
and improving response times.

3.1. Benefits of MySQL Cluster to Subscriber Databases

Some of the benefits of MySQL Cluster Carrier Grade Edition for subscriber databases include:
o Consolidation of many subscriber data sources
“Based on our previous experience and its extensive user base within
managed by different services to a unified the telecommunications industry, selecting MySQL to power the Open
database, where a single, consistent copy of the IMS Core project’s HSS was the obvious choice”.
subscriber data can be accessed by all services
and systems. This reduces new service Peter Weik, Senior Researcher,
introduction time and costs, as integrating new Fraunhofer Institute FOKUS
services require less interface development and
testing.
o High Performance with a Shared-Nothing, Parallel Database that provides real-time access to in-memory
subscriber data (2 to 5 millisecond latency for both reads and writes) and can be scaled by adding additional
resources on-line and by storing less frequently accessed data on disk.
o 99.999% availability which is achieved in three levels with MySQL Cluster CGE:
o Distributed, shared-nothing architecture with the database partitioned across multiple server hosts in the
cluster;
o Synchronous replication of data between multiple database nodes for purposes of redundancy;
o Recovery (check-pointed) data persisted to disk;
Availability levels can be further extended by implementing Geographic Replication, which serves to
replicate data off-site to a remote cluster.
o Self-Healing of data nodes with sub-second fail-over times, and an optimized node recovery protocol that
automatically resynchronizes data for MySQL Cluster data nodes after they have been restarted.
o Distribution-awareness enabled in MySQL Cluster Carrier Grade Edition with the partitioning of tables by
subscriber identifiers, and by using the subscriber identifier as part of the primary key when accessing data to
ensure that reads/writes are localized to the data node(s) containing the subscriber data. This topic is covered in
detail in the section entitled “Distribution Awareness in MySQL Cluster”
o Open Source licensing and distribution ensures that many users help improve the quality of MySQL software,
along with valuable feedback from MySQL Community. Transparency of the code also enables developers of
subscriber-based services to fully understand and optimize their applications for MySQL Cluster.
o Standards-based allows vendors of telecommunications solutions to easily integrate their subscriber
applications with MySQL Cluster CGE using their preferred database-independent Subscriber API, e.g. LDAP or
SQL. Access to subscriber data can be performed either on a database independent subscriber API or directly
using the native NDB API.
o Database size can be increased significantly using disk-based storage. It is possible to decide, per-table or
even per-column, which attributes reside in memory and which ones reside on disk. For example in IMS or portal
applications, BLOBs can be stored on disk.

Copyright © 2009, Sun Microsystems Page 6

 o Flexible relational database supports mature relational tools for analyzing and mining customer data via an
SQL interface to the MySQL Cluster database, or alternatively, to a replicated copy of the real time data held in
tables in a non-production database. Convergence means that you must have all of the data for your services
available centrally, allowing the BSS to analyze the data either online or by automatically archiving real-time data
to a data warehouse using Geographic Replication.
o Faster time to market for CSPs with existing relational models for subscribers and service data. MySQL Cluster
Carrier Grade Edition provides a smoother migration to a subscriber-centric model, compared to proprietary
approaches.

4. Linear Scalability in a Shared-Nothing, Distributed Database

Scalability of any system is measured by the ability to increase throughput in proportion to increases in resources
powering the system (i.e. as more hosts are added, or as memory / CPU resource is increase in existing hosts). As
telecommunications services become more feature-rich and gain adoption, the number of subscribers, and potentially
the amount of data stored for each subscriber, can grow rapidly. To ensure a good quality customer experience, it is
vital that the subscriber database is able to scale throughput (performance) while maintaining ultra-low response times
and continuous availability.

Figure 3: Achieving Near-Linear Scalability

In a shared-nothing, distributed database architecture, all data is partitioned, including indexes to data, using hash
indexes on the primary key, or a sub-component of the primary key. In this architecture, primary key operations (single-
tuple operations on subscribers) are extremely efficient. Increasing the number of primary key operations in a
transaction (i.e., increasing the batch size) typically brings linear improvements in performance, often up to network
bandwidth saturation limits.
In subscriber-centric databases, another data access pattern involves multiple-tuple subscriber-specific operations. To
improve the performance of this access pattern, MySQL Cluster offers user-defined partitioning to allow the
partitioning of tuples using subscriber identifiers. This enables index scans operations for subscriber-specific data to be
sent directly to the data node containing the subscriber-specific data, and allowing them to scale linearly with the
cluster’s size.
Both full table scans and joins do not have linear scalability properties. To improve system performance, it is best to
minimize their use. If they are scheduled in a controlled manner, full table scans and joins can still be included as
operations in a scalable, subscriber system. Additionally, the data from a MySQL Cluster database can be
automatically replicated to a near-real time copy stored in a different storage engine (on a different host) that is
designed to handle scans and joins much more efficiently.

Copyright © 2009, Sun Microsystems Page 7

For larger cluster configurations (of 16 data nodes and up), another factor to consider is the global maintenance and
recovery protocols (e.g., Global Checkpoints and Heartbeats4) that consume a very small fraction of network bandwidth
and which increase slightly with a cluster’s size (from a very low base). These protocols cause a small divergence from
full linear scalability for 16-node cluster’s and up. To put a cluster size in context, a four-node system on COTS quad-
core 64-bit hardware can easily process 125,000 replicated operations/second5 with a response time of less than 5
milliseconds.

4.1. Distribution Awareness in MySQL Cluster

Applications accessing MySQL Cluster CGE either via the NDB API or SQL must have:
– Replication transparency, meaning applications are not aware of how many replicas of the data are stored in a
cluster. The cluster automatically manages the synchronous replication of data based on the number of
replicas specified and the number of data nodes in the cluster;
– Partition transparency so applications do not know on which partition a particular tuple is stored;
– Access transparency which hides network details of how applications read/write data to the cluster.
Partition and access transparency allows developers to write applications that are independent of the cluster size. So, if
more data nodes are added to the cluster, applications continue to work as before.

Figure 4: Scalability impacted by absence of Distribution Awareness

As illustrated in the figure above, in a 4-Node cluster with no distribution awareness, there is a 50% chance of
transaction starting on a Data Node in the wrong Node Group (a node not containing the data), resulting in
unnecessary inter-node group communications. In this example, the transaction is a batch6 of two operations (a read

4
See the MySQL Cluster Documentation: http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster.html
5
http://blogs.sun.com/hasham/entry/mysql_cluster_7_performance_benchmark
6
Increasing the number of operations in a transaction produces large performance gains, as it reduces the number of times NDB API clients send
transactions to Data Nodes, better utilizing network bandwidth.

Copyright © 2009, Sun Microsystems Page 8

and an update of subscriber data) which is submitted to a data node in the cluster using a ‘nearest data node heuristic’
or round-robin policy7.
In this case, we assume that the transaction is sent to a data node which is not in the Node Group containing a copy of
the subscriber’s tuples. This incurs unnecessary extra inter-Node Group network traffic, as the Transaction Coordinator
(TC) needs to coordinate the 2-Phase Commit Protocol (2PC) for the update operation between the Local Query
Handlers (LQHs) on the Data Nodes for Primary and Secondary Partitions.

Figure 5: Index Scans from MySQL Server have Parallel=0 (i.e., maximum parallelism)

Similarly, in Figure 5, we can see how an index scan that is sent to a MySQL Server causes the scan to be executed on
all of the data nodes in the cluster. The TC sends the index scan to the LQHs of all nodes, which execute the index
scan locally, and then return the results back to the MySQL Server.
However, we can reduce the number of index scans significantly by partitioning the database in such a way that all
relevant tuples belonging to a specific subscriber are located within a single node. The index scan will then only
execute on that data node. An example of this can be found in Figure 6.

7
See NDB-API Documentation: http://dev.mysql.com/doc/ndbapi/en/overview-selecting-tc.html

Copyright © 2009, Sun Microsystems Page 9

 Figure 6: Partitioning the Database for Distribution Awareness
In the figure above, where tables that are partitioned by the same distribution key (here the ‘uid’ column), tuples from
those tables with the same distribution key value are stored on the same Primary Partition.
With this background, we can now discuss how developers can write NDB API applications that are distribution-
aware. Such applications eliminate inter-Node Group network traffic for primary key operations and optimize the
number of index scans started in a cluster. Distribution-aware applications are, however, still partition and access
transparent, i.e., they are still cluster-size independent. Distribution-awareness is achieved by:
o User-level partitioning with the PARTITION BY KEY syntax that allows for the specification of a
distribution key (i.e., a subscriber-ID) for a schema8;
o Controlling the partition where a transaction is started in the cluster by supplying a distribution
key value (i.e., a subscriber-ID) when starting the transaction;
Controlling the level of parallelism for an index scan ensures that the index scan is only started on the data node that
contains the primary copy of the subscriber-specific data9.
An MD5 hash function (in the NDB API and SQL API) uses the distribution key to map tuples in a schema to partitions,
as shown in the figure above. The distribution key maintains partition transparency, as applications do not know on
which partition the tuples are stored. Distribution key values determine on which data node a transaction is started, and
they do not break access transparency, as applications only know that the transaction has started on the partition
containing tuples with the distribution key value.
Similarly, when starting an index scan, if we know that the data for the index scan is on the same data node where the
transaction started, then we can set the level of parallelism to ‘1’, as shown in Figure 7. The NDB API allows
applications to set distribution key values when starting transactions and the level of parallelism for index scans.

8
Partition by key is available in MySQL Cluster CGE
9
The parallel parameter for index scans is ignored and set to maximum if the scan results are sorted.

Copyright © 2009, Sun Microsystems Page 10

 Figure 7: Optimizing Index Scans with NDB API

As illustrated above, when using the NDB API, a distribution key value is set for the Transaction, and an Index Scan’s
level of parallelism is 1. The Index Scan executes on the Primary Partition for the subscriber data.
For existing relational subscriber databases, MySQL Cluster's approach represents a painless transition to a
subscriber-oriented database compared to hierarchical approaches, such as LDAP and DAP for X.500.
MySQL Cluster CGE provides the performance benefits of distribution-aware operations, while still maintaining partition
and access transparency, as well as offering the advantages of the relational database model.
Similar benefits from distribution awareness can be realized when accessing data through the SQL interface where the
MySQL Server can parse the query and internally make the appropriate calls to the NDB API.

5. Creating Tables Partitioned by Subscriber-ID

We can now work through a simple example of a subscriber database with an associated IMS service. First, we define
a simplistic schema for subscriber profiles, partitioned by subscriber-ID (‘uid’ column in the schema definition) as
follows:
CREATE TABLE subscriber_profile (
uid INT NOT NULL,
name VARCHAR(255) NOT NULL,
addr VARCHAR(255) NOT NULL,
PRIMARY KEY(uid)
) ENGINE=NDB PARTITION BY KEY (uid);
PARTITION BY KEY allows the specification of the distribution key for the table as a list of zero or more column
names. Where no column name is specified as the distribution key, the table's primary key is used (as would have
been the case in the above table). If no partition key or primary key is specified for the table, the table is reorganized
using a “hidden” primary key as the table's new partitioning key.
Columns specified as the distribution key do not have to be integer values, since the MD5 hashing function supplied by
MySQL guarantees an integer result regardless of the column data type. The distribution key can also be a composite
key, consisting of more than one column.
Now, we define an IMS service that uses the subscriber database, called Push-to-Talk (PTT). PTT is a “walkie-talkie”-
style service, where users push a button on their mobile device to instantaneously set up a one-way voice-
communication channel to one or more users.

Copyright © 2009, Sun Microsystems Page 11

 CREATE TABLE service_pushtalk (
uid INT NOT NULL,
ip_addr INT NOT NULL,
credit INT NOT NULL,
PRIMARY KEY (uid)
) ENGINE=NDB PARTITION BY KEY (uid);
PTT also maintains a history of calls made by users, defined in the following pushtalk_history schema. Here, the
primary key is a composite of the uid and group_id columns, although the distribution key is defined on the uid
column, i.e., the schema is still partitioned by subscriber-ID.
CREATE TABLE pushtalk_history (
uid INT NOT NULL,
group_id INT NOT NULL,
duration long NOT NULL,
PRIMARY KEY (uid, group_id)
) ENGINE=NDB PARTITION BY KEY (uid);

NDB-API is required to write distribution-aware applications that can start transactions with the primary key or index
scan operations on the node containing the subscriber data. Some sample code is given in Figure 7 above.

6. Improved Scalability with Distribution-Awareness

In this section, we evaluate the performance improvement gained with user-defined partitions, distribution key values,
and optimal parallelism for index scans. In the following figure, we can see how supplying a distribution key value
when starting a transaction (containing subscriber-specific operations), guarantees the transaction will start on the Data
Node containing the subscriber data (probability = 1).

However, when no distribution key value is supplied, the probability that the transaction will start on a Data Node in the
same Node Group as the Primary decreases with the increasing size of the cluster. For a transaction containing
Primary Key operations, in an 8-node cluster, this can lead to a performance drop of roughly 20%. This demonstrates
that, for large cluster sizes, a reasonable performance improvement can be gained by using distribution key values for
transactions containing individual subscriber operations.

Probability of Transaction Starting in Node Group

containing Subscriber Data is '1' for Distribution Key

0.8

0.6
Probability
0.4 No Distribution Key
Distribution Key
0.2

0
2 4 8 16
Number of Data Nodes

Figure 8: For Linear Scalability, Start Transactions with a Distribution Key Value.

Copyright © 2009, Sun Microsystems Page 12

Figure 9 shows the extra overhead in starting a transaction containing an index scan operation on the wrong Data
Node increasing as the size of the cluster increases. This demonstrates that particularly for increasing cluster sizes, a
significant performance improvement can be gained by using distribution key values to start transactions and control
parallelism when performing index scans for subscribers.

Num of Nodes executing an Index Scan remains

constant, using Distribution Key and Parallelism=1
16
14
12
10
No Distribution
Num Scans 8
Key, Parallel=max
6
With Distribution
4 Key, Parallell=1
2
0
2 4 8 16
Number of Data Nodes

Figure 9: For Linear Scalability with Index Scans, use a Distribution Key Value and Parallel=1 to start the
Transaction and Index Scan on the Data Node that contains the Subscriber Data.

7. Conclusion
MySQL Cluster Carrier Grade Edition is a perfect fit for Subscriber Databases due to its high performance, high
availability, and ease of integration with database-independent Subscriber APIs or existing relational or directory-based
subscriber models.
Many of its features are aimed specifically at meeting the requirements for Subscriber Databases deployed with CSPs,
including:
– Distribution-Awareness through the partitioning of tables by subscriber identifiers, and by using those identifiers
when accessing subscriber data to ensure that reads/writes are localized to the data node(s) containing the
subscriber data;
– Standards Based, open source database allows vendors and users of subscriber data management solutions to
easily integrate their applications with MySQL Carrier Grade Edition using their preferred database-independent
Subscriber API, e.g., LDAP, SQL, C++, Java, HTTP, etc;
– LDAP drivers enabling MySQL Cluster CGE to be accessed via the LDAP protocol;
– High Performance with a Shared-Nothing, Distributed Database that provides real-time access to in-memory
subscriber data with just a few milliseconds latency for reads and writes, and can be scaled out by adding
additional resources or by storing data on disk;
– 99.999% Availability achieved by synchronously replicating data across active nodes in the cluster, with recovery
data being asynchronously written to disk;
– Self-Healing of data nodes with sub-second fail-over times, and an optimized node recovery protocol that
automatically re-synchronizes data across re-starting data nodes;
– Geographic-Replication for site-level redundancy;

Copyright © 2009, Sun Microsystems Page 13

– Relational Database technology supports mature tools for analyzing and mining customer data via an SQL
interface;
– Low TCO through the ability to scale on low cost, commodity hardware and open source economics.

When deploying MySQL Cluster Carrier Grade Edition as

a centralized Subscriber Database to handle Subscriber
Profiles and Service-related Data, it is easier and more
efficient to roll out new services, while being sure that the
database system can meet extreme performance and
availability guarantees. Major Telecom Equipment
Manufacturers and CSPs are already realizing the
benefits of building Subscriber Databases using
commodity hardware and open source components.
“Service availability is the number one requirement for our
customers. MySQL Cluster delivers the high availability that enables
us to guarantee continuous services to our subscribers. This has
had an immediate impact in significantly improving customer
satisfaction, and has reduced the cost of operating our network”.
Lars-Ake Norling, CTO (B2), Telenor

8. Additional Resources
Alcatel-Lucent uses MySQL Cluster Carrier Grade Edition to Handle over 60 million Subscribers:
http://www.mysql.com/why-mysql/case-studies/mysql-alcatel-casestudy.php

Open IMS Core Project uses MySQL as HSS:

http://www.mysql.com/why-mysql/case-studies/mysql_cs_IMS_Core.php

BT Plusnet Achieves Continuous Availability of Subscriber AAA Services with MySQL Cluster and FreeRADIUS:
http://www.mysql.com/why-mysql/case-studies/mysql_cs_plusnet.php

MySQL Cluster Architecture and New Features Whitepaper:

http://www.mysql.com/why-mysql/white-papers/mysql_wp_cluster7_architecture.php

MySQL Cluster Evaluation Guide:

http://www.mysql.com/why-mysql/white-papers/mysql_cluster_eval_guide.php

Integrating LDAP with MySQL Cluster:

http://www.mysql.com/why-mysql/white-papers/mysql_wp_openldap-scaling-guide.php

Integrating AAA with MySQL Cluster:

http://www.mysql.com/why-mysql/white-papers/mysql_wp_ha_auth_account.php

MySQL Cluster on the web: www.mysql.com/cluster

Getting Started with MySQL Cluster: http://www.mysql.com/products/database/cluster/get-started.html

Copyright © 2009, Sun Microsystems Page 14

9. Glossary
o 2-Phase Commit (2PC)
o AAA (Authentication, Authorization, Accounting)
o Application Programming Interface (API)
o Average Revenue Per User (ARPU)
o Business Support Systems (BSS)
o Carrier Grade Edition (CGE)
o Communication Service Provider (CSP)
o Customer Relationship Management (CRM)
o Directory Access Protocol (DAP)
o Home Subscriber Server (HSS)
o Home Location Register (HLR)
o IMS Application Servers (AS)
o IP Multimedia System (IMS)
o Java Database Connectivity (JDBC)
o Lightweight Directory Access Protocol (LDAP)
o Local Query Handler (LQH)
o Network Database (NDB)
o Next Generation Network (NGN)
o Operations Support Systems (OSS)
o Open Database Connectivity (ODBC)
o Prepaid Account Manager (PAM)
o Push-to-Talk (PTT)
o Remote Access Dial-In User Service (RADIUS)
o Service Control Point (SCP)
o Session Initiation Protocol (SIP)
o Total Cost of Ownership (TCO)
o Transaction Coordinator (TC)
o Video on Demand (VoD)

Copyright © 2009, Sun Microsystems Inc. MySQL is a registered trademark of Sun Microsystems in the U.S. and in
other countries. Other products mentioned may be trademarks of their companies.

Copyright © 2009, Sun Microsystems Page 15