01 01 cn65001en80gla0 product overview theory

8/10/2019 01 01 CN65001EN80GLA0 Product Overview Theory

1/15

CN6500EN80GLA00 Company Confidential 1

Product Overview NSN

Company Confidential

1 Nokia Siemens Networks

Product Overview One-NDS Directory


2/15




CN6500EN80GLA00 Product Overview / 22 April 20092 Nokia Siemens Networks

Contents

Functionality

Standards Data access protocols

Directory Server concepts

Architecture

Customer references


3/15


4/15





One-NDS Directory Functionality - Platform

One-NDS Directory Provides the back end data store

One-NDS Directory Provides the platform for the application

(e.g. One-HLR, One-MNP, One-EIR)

As well as being a data store One-NDS Directory is also the platform for hosting applications,

providing functionality (e.g. Logging and alarm reporting)

One-NDS Directory platform is used by other SDM applications

One-HLR Home Location Register

One-MNP Mobile Number Portability

One-EIR Equipment Identity Register


5/15





One-NDS Directory Data Store

DirecTree

The name of the in-memory database

Holds all the information associated with data entries Based on the ISO/IEC & ITU-T X.500 directory specifications

One-NDS Directory includes mechanisms for managing theDirectTree

Access control (data access restrictions and permissions)

Memory management

Backup & restore of data Schema management (data structure & rules)

Alarm management & logging


6/15





X500: A Standards Based Architecture

X.500 is a hierarchical directory structure for organising information

ISO/IEC and ITU defined standards

X500 Directories

Can be geographically dispersed: Providing redundancy over several sites.

Locating data relevant to a geographic area.

Can cater for potentially billions of entries of information

Can be physically distributed: Multiple physical servers & sites

Appears as a single logical directory server

The One-NDS Directory X.500 implementation

Provides scalability, resilience and required performance levels

Is an ideal choice for the telecommunications industry

One-NDS Directory have been developed using the ISO/IEC (International Organisation for

Standardization/International Electro technical Commission) and ITU (International

Telecommunication Union) standards for X.500.

One-NDS Directory has been designed for telecoms applications where typically a database

needs fast access to potentially millions of subscriber entries.


7/15





Data Access Protocols

Lightweight Directory Access Protocol (LDAP)

Simplified string-based version of the X500 protocol DAP

Openly available for users to access the directory

Simple Object Access Protocol (SOAP)

Used to invoke actions in external applications when a particular value orset of values is altered in the database.

One-NDS Directory systems use open standard protocols

Network operators have access to their own data

One-NDS Directory does not use proprietary interfaces

LDAP is not specified in the X.500 standards, but is a version of the DAP (Directory Access

Protocol) which is specified by X.500:

DAP is used internally within One-NDS Directory

LDAP is used by applications as to access One-NDS Directory

LDAP is automatically converted to DAP for use within One-NDS Directory

Methods are used to perform a complex sequence of database operations using one

LDAP request, thus simplifying the user interface (i.e. adding subscribers).

Soap notifications can be triggered enabling external applications to be notified of updates to

specific data stored within One-NDS Directory.

Using open non proprietary access protocols allows customers the ability to enable access to

One-NDS Directory using their own existing applications.


8/15





In Summary

One-NDS Directory is a data store

One-NDS Directory is a platform for applications Based on X500 standards for directory servers

Open access using standard LDAP


9/15





Root DSA

Directory Concepts

Directory Information Base (DIB)

Set of all data stored in One-NDS Directory

Directory Information Tree (DIT)

Structure of the data

Directory System Agent (DSA)

A cluster of nodes containing a subset of the DIB

Together the DSAs implement the overall directory

Subscriber Data DSA 2Subscriber Data DSA 1

ID type

Subscriber 2

Service 1

Entry Entry

Subscriber 1

Service 1 Service 2

EntryEntry Entry

Root

Directory have a hierarchical structure. Data is stored using parent & child relationships i.e.

one entry is the parent for another entry or entries. Whenever a new entry is created it is

necessary to specify which entry should be the parent of that new entry.

Each DSA stores a subset of the DIB.

The number of nodes within each DSA will differ dependent on transaction requirements.


10/15




CN6500EN80GLA00 Product Overview / 22 April 200910 N okia Siemens Networks

DSA

DSA Architecture

PrimaryNominated secondary

(Primary standby)

Secondary


A DSA is a cluster of synchronisedphysical nodes/servers

Each node in a cluster holds an identicalcopy of the data contained within the DSA

Any node within the cluster may receiveread and update requests from externaldirectory users

The Primary node ensures all updates areapplied to all nodes to maintain dataconsistency

RedundancyWithin a DSA: loss of a node does not mean loss of service

Redundancy within a DSA, loss of a node does not mean loss of service as all data is

replicated on each node.

Any node within a DSA can respond to a database query or update

To maintain data consistency, updates are always passed to the Primary node within a DSA,

the primary node performs the update and replicates changes to all other nodes,

In a normal functioning DSA:

One node will be designated as the Primary

All other nodes will be designated as Secondary's

One Secondary node will be designated as Primary Standby

The number of nodes within each DSA will differ dependent on transaction requirements.


11/15





Distributed Directory Architecture

RedundancyWithin a DSA: loss of a node does not mean loss of service

Routing DSA

Root DSA

Routing DSA

BE DSA 2BE DSA 1

Application Front Ends (HLR, HSS etc)

Back Ends hold the subscriber data.

Routing DSAs an internal identity routing

function: identifies the subscriber then

passes request to correct Back End where

subscriber data is held.

Front Ends provide the network interfaces

and execute the application logic.

Root DSA provides a single point of

contact for other systems (e.g. provisioning

system) and greatly simplifies the task of

extending the directory.

Different DSAs may have different roles within the system

Routing DSAs, allow for greater distribution of data among multiple BE DSAs

The routing of queries is done using an identity (e.g. subscriber IMSI or MSISDN

The greater the number of entries (e.g. subscribers) the greater the number of identities that

need to be stored therefore the greater the number of BE DSAs required.

Multiple BE DSAs necessitate the requirement for Routing DSAs


12/15





Site Architecture

Site 1 Site 3

Site 2

Front End Nodes

Routing Nodes

Back End Nodes

Root Nodes

RedundancyAcross geographic sites: loss of a site does not mean loss of service

Locating nodes from each DSA on different geographic sites provides system redundancy

should a site be lost.


13/15





Add more Back End DSAs for increased data capacity

Add more Routing DSAs for increased ID capacity

Add more Front End nodes for transaction capacity

Distributed

Architecture

Transparent Scalability

Front End DSA

Routing DSA

Back End DSA

Increased Data

Capacity

Front End DSA

Routing DSA

Back End DSA Back End DSA

Front End DSA

Routing DSA

Back End DSA

Routing DSA

Back End DSA

Increased ID

Capacity

Back End DSA

Increased

Transaction

Capacity

Front End DSA

Routing DSA Routing DSA

Back End DSABack End DSA

Back End DSA

When adding routing DSAs there is also a requirement to migrate data (IMSI & MSISDN

entries) from original routing DSA to the new routing DSA.


14/15





In Summary

Directory Server concepts

Directory Information Base (DIB)

Directory Information Tree (DIT)


Architecture

DSA architecture

Data distribution

Scalability

Redundancy


15/15




A unified subscriber profile repository

Scalability

Real-time performance andcontinuous availability

Flexibility and adaptability

250 million subscribers0.5 TB subscriber data

180,000 tps (20% updates)

1.97 ms average response time

Sun X4100 (AMD Opteron), 32 GB RAMUp to 14 Front-End serversSun X4600 (AMD Opteron), 64 GB RAM

Up to 26 Back-End servers

Up to 10 Identity/root domains

Site 1: domains

and subscriber

data DSAs

Injectors and

routing DSAs

Site 2:

domains and

subscriber

data DSAs

Scalability and performanceNorth American Carrier, Proof of Concept December 2006

Performance achieved Hardware configuration

Requirements

01 01 cn65001en80gla0 product overview theory

Documents