01 CN66561EN92GLA0 System Overview

7/26/2019 01 CN66561EN92GLA0 System Overview

1/37

System Overview

CN66561EN92GLA0 2014 Nokia Solutions and Networks

1

Contents

1 General Tips for Troubleshooting 3

1.1

Preface 4

1.2 Logical approach 5

1.3 Problem Solving Technique 7

1.4 Data Collection Saving Sequence for Error Report 9

2 Scope 13

2.1 One-NDS Components 14

3 Basic Knowledge 17

3.1 Directory Concept 18

3.2 Interfaces and Protocols 20

3.3 Network Connectivity 31

3.4 Ports 34

3.5 Operating System Users and Rights 37

System Overview


2/37

System Overview

CN66561EN92GLA0

2014 Nokia Solutions and Networks2


3/37

System Overview


3

1 General Tips for Troubleshooting

Fig. 1 General Tips for Troubleshooting


4/37

System Overview

CN66561EN92GLA0


1.1 Preface

Troubleshooting, by its nature, is a tough subject to teach. You start with any of aworld of symptoms and try to work your way back to the cause. We can't cover thewhole gamut of problems you may encounter, but we will certainly do our best toshow how to diagnose the most common of them. And along the way, we hope toteach you troubleshooting techniques that will be valuable in tracking down moreobscure problems that we don't document.

This course covers a selected subset of troubleshooting situations and tools for theOne-NDS 9.0 system. Use of these tools should be at the direction of Nokia Solutionsand Networks Service personnel as some processes may affect the performance ofthe Network Elements under test.

Troubleshooting and collection of Error Symptoms for the One-NDS 8.0 system arecontained in the Customer Documentation. Please refer to it for additionalinformation.

WARNINGInformation is not intended to replace the One-NDS 9.0 Service Manual forMaintenance, Diagnostics and Emergency and does not cover any Operatorspecific tools.


5/37

System Overview


5

1.2 Logical approach

A logical approach is helpful when troubleshooting any problem. Some commonquestions to ask during troubleshooting include the following:

What works?

What does not work?

How are the things that do and do not work related?

Have the things that do not work ever worked?

If so, what has changed since it last worked?

The answers to these questions can indicate where to begin troubleshooting,possibly allowing you to isolate the component, layer, or configuration issue that iscausing the problem.


6/37

System Overview

CN66561EN92GLA0


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 2014 Nokia Solutions and Networks. All rights reserved.

Common questions to ask when troubleshooting

A logical approach is helpful when troubleshooting any problem.

Some common questions to ask during troubleshooting include the

following:

- What works?

- What does not work?

- How are the things that do and do not work related?

- Have the things that do not work ever worked?

- If so, what has changed since it last worked?

The answers to these questions can indicate where to begin

troubleshooting, possibly allowing you to isolate the component, layer,

or configuration issue that is causing the problem.

Fig. 2 Common questions to ask when troubleshooting


7/37

System Overview


7

1.3 Problem Solving Technique

1.3.1 Appreciation

Appreciation is a very simple but powerful technique for extracting the maximumamount of information from a simple fact.

How to Use:

Starting with a fact, ask the question 'So what?' i.e. what are the implications of thatfact? Keep on asking that question until you have drawn all possible inferences.

Example:

Fact: It rained heavily last night.

So What?

The ground will be wet

So What?

It will turn into mud quicklySo What?

If many vehicles pass over the same ground, movement will be progressivelyslower and more difficult as the ground gets muddier and more difficult.

So What?

Where possible, stick to paved roads. Otherwise expect movement to be muchslower than normal.

While it would be possible to reach this conclusion without the use of a formal

technique, Appreciation provides a framework within which you can extractinformation quickly, effectively and reliably.

Key points:

Asking 'so what?' repeatedly helps you to extract all important information implied bya fact.


8/37

System Overview

CN66561EN92GLA0


1.3.2 5 Whys

Quickly Getting to the Root of a Problem:

Why use the tool?

The 5 Whys is a simple problem-solving technique that helps you to get to the root ofthe problem quickly. Made popular in the 1970s by the Toyota Production System,the 5 Whys strategy involves looking at any problem and asking: "Why?" and "Whatcaused this problem?"

Very often, the answer to the first "why" will prompt another "why" and the answer to

the second "why" will prompt another and so on; hence the name the 5 Whys.

It helps to quickly determine the root cause of a problem

It is easy to learn and apply

How to use:

When looking to solve a problem, start at the end result and work backward (towardthe root cause), continually asking: "Why?" This will need to be repeated over andover until the root cause of the problem becomes apparent.

TIPThe 5 Whys technique is a simple technique that can help you quickly get to the rootof a problem. But that is all it is, and the more complex things get, the more likely it isto lead you down a false trail. If it doesn't quickly give you an answer that's obviouslyright, then you may need more sophisticated technique problem solving techniques.


9/37

System Overview


9

1.4 Data Collection Saving Sequence for Error Report

When an error occurs, the basic error symptoms and the error symptoms accordingto the error class should be saved as soon as possible.

The reason for quick action is that data, which is essential for error diagnosis andstored in cyclic error symptom files or in the memory, could be overwritten and lost.


General Troubleshooting Instructions

Collect information

Analyze cause

Implement solution

Test solution

Design solution

Fig. 3 General troubleshooting instructions

The following slide sums up the procedure that needs to be handled in order to reporteffectively an error.


10/37

System Overview

CN66561EN92GLA0


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Basic Error Reporting

Save the basic error symptoms immediately

- List the alarms indicated in the @vantage commander

- Describe the error situation and all system relations, including all (operator)

actions taken before and after the error.

- Save the specific error symptoms which may require the following.

Network Trace

HealthChecks

Subscriber Specific Trace at direction of NSN Service- Determine the Error Priority

- Open Fault report in RESOLVE. Fill out the error report, and attach the error

description as well as the error symptoms!

Fig. 4 Basic Error Reporting

Collecting Symptoms for the One-NDS is realized as a generic shell script availableon all the network elements provided by the installation. The script is installed withthe One-NDS cntdb_common package and stored under:

/opt/c n tdb /b in /co l lec t_s ymptoms.


11/37

System Overview


11

1.4.1 The collect_symptoms utility

This utility stores multiple types of information gathered in 3 different categories:

Global system information

Global One-NDS information

Node specific application information

The global system information are gathered by the subscript supportconf ig. Thisscript is available on all different node types. The supportconf igscript is part ofsupportutils-1.01-xx.x.noarch.rpm package provided from NOVELL (not part ofSLES10 distribution).

For more detailed information please visit:

http://www.novell.com/communities/node/2332

In order to retrieve the global One-NDS information, the conf ig.sh subscript isexecuted. Also, this script is available on all different node types and stores e.g. theinstalled medium information (/opt/cntdb/etc/Media).

Finally, the Node specific application information are retrieved executing application-related own symptom collection script which in turn get executed by the master script

in order to support application specific symptom collection.col lect_symp toms -pwill print the available application script for this specific nodetype (server role).

The slide on the right hand side shows you an example of the running of the script ona BE-DS. The script has to be executed with rootuser.
http://www.novell.com/communities/node/2332http://www.novell.com/communities/node/2332


12/37

System Overview

CN66561EN92GLA0


.

cdb2be2:/ # collect_symptoms

collect_symptoms - version 8.6.3

run script /opt/cntdb/etc/symptoms.d/apertioDS.sh /tmp/cdb2be2_120918_0825/apertioDS.sh ...

DS is running

Writing status message to AQ17Writing measurements message to AQ17

The Attribute (bgReconKeyFieldCnt) was not found

done !

run script /opt/cntdb/etc/symptoms.d/config.sh /tmp/cdb2be2_120918_0825/config.sh ...

done !

run script supportconfig /tmp/cdb2be2_120918_0825/supportconfig ...

done !

Creating tarball

--[ DONE ]-------------------------------------------

Log file tar ball: /tmp/cdb2be2_120918_0825.tar.bz2

Log file size: 4.7M

-----------------------------------------------------

cdb2be2:~ #

Fig. 5 Executing the collect_symptoms utility on a BE-DS

Here, we can see that the script is divided into multiple subparts that are executedone after the other, collecting each time a different type of information.

The following picture is the execution of the script on a PGW:

.

cdb2pgw1:~ # collect_symptoms

collect_symptoms - version 8.6.3

run script /opt/cntdb/etc/symptoms.d/pgw.sh /tmp/cdb2pgw1_120918_0850/pgw.sh ...

info: Dumping list of processes and top.

info: Searching for instances.

info: Found 2 instances: instance_li instance1

[]

run script /opt/cntdb/etc/symptoms.d/config.sh /tmp/cdb2pgw1_120918_0850/config.sh ...

done !

run script supportconfig /tmp/cdb2pgw1_120918_0850/supportconfig ...

done !

Creating tarball

--[ DONE ]-------------------------------------------

Log file tar ball: /tmp/cdb2pgw1_120918_0850.tar.bz2Log file size: 23M

-----------------------------------------------------

cdb2pgw1:~ #

Fig. 6 Executing the collect_symptoms utility on a PGW

The main difference here as we can see is the execution of an additional script calledpgw.sh that stores the information related to the Provisioning Gateway functionality.


13/37

System Overview


13

2 Scope

Fig. 7 Scope


14/37

System Overview

CN66561EN92GLA0


2.1 One-NDS Components

The troubleshooting of the One-NDS system must start by identifying its components.In this case, it is better to distinguish them by their function rather than by theirhardware. Indeed, all of them are running on the same HW platform.

The OS running on all is SuSe Linux Enterprise Edition v10.

We can distinguish the following functions:

NDS

The Network Directory Servers (later simply called DS) are the core elements of theOne-NDS, forming together DSAs on which the DBs are stored.

The data base where subscribers at stored consists of routing DSA cluster and theBE-DSA clusters.

The BE-DSA clusters are the part of the directory that does contain the actual datacontent.

The routing DSA stores access keys and references to the database entries(subscriber data)

The PGW-DSA (Config DSA) is used to store the configuration data of the PGW. Theconfiguration data provides information about the typology of the One-NDS Directory:number of DSs of routing DSA and PGW DSA, distribution of these DSAs overgeographical sites, number and IDs of BE DSAs, IP addresses, presence of separateapplication LAN, presence of PGWs, their IP addresses, distribution of PGWgeographical sites, and so on

Provisioning Gateway (PGW)

Transactions from the Customer Care Center (CCC) systems are forwarded to theprovisioning gateway, processed there (selecting the DSA, where the subscriber willbe stored), and then forwarded to the Data Base. The lightweight directory accessprotocol (LDAP) interface is used to transfer these transactions to the database.LDAP is based on the X.500 standard, but unlike X.500, LDAP supports TCP/IPaccess.

Notification Manager (NTF)Either as a standalone or part of the PGW-DSA, the NTF is a central component fordistributing all notifications from One-NDS components to both PGW and applicationservers. The NTF stores the subscription information from different applications in theOne-NDS Directory.

System Monitor (SM2)

The NetAct System Monitor is introduced as an integral part of the One-NDS thatprovides standard interfaces that can be integrated to a third party NetworkManagement System (NMS) for fault and performance management. One-NDS isintegrated to NetAct via the System Monitor. Fault and Performance management

data are collected from One-NDS components by the SM, aggregated and filtered,then reported to NetAct.


15/37

System Overview


15

One-NDS Administrator (ADM)

The One-NDS Administrator (ADM) is an independent management system used forthe administration of One-NDS Directory, PGW configuration, and Notification

Manager (NTF). Over the ADM, authenticated clients and authorized users canperform tasks, for example, in the One-NDS Directory. The tasks include relocatingsubscribers from one BE DSA to another, monitoring subscriber data storage,schema management, checking data consistency and administrating new DSAs.

Here is an illustration of the main functional components of One-NDS that will beseen throughout the course:


NDS = Network Directory Server

PGW = Provisioning Gateway

NTF = Notification Manager

ADM = One-NDS Administrator

INS = Installation Server

SM2 = System Monitor

NDS PGW NTF ADM INS

SLES 11

e.g. Oracle Netra / HP Blade

platform

components SM2

Fig. 8 One-NDS main functional components


16/37

System Overview

CN66561EN92GLA0



17/37

System Overview


17

3 Basic Knowledge

Fig. 9 Basic Knowledge


18/37

System Overview

CN66561EN92GLA0


3.1 Directory Concept

3.1.1 GeneralDirectories provide a versatile way of organizing information and are highlyappropriate for modeling the typical hierarchical relationships between data objects inthe real world.

For One-NDS, a standard X.500 directory has been selected in accordance with theInternational Telecommunication Unions X.500 series of recommendations as thepreferred structure for arranging information within the directory. Storage capacity isvirtually unlimited and directory performance is not affected by increases in datavolume.

In simple terms, a Directory is a database that follows the structure and featuresdefined in the X.500 standards. The data is stored in a directory structure, hence theterm Directory.

Telecoms applications require fast access to potentially millions of subscriber entries.The Directory provides this because of two key features:

Data is held in memory (as opposed to on disk) making access very fast.

The directory structure allows for efficient retrieval of data

3.1.2 Directory model definitions

The following terms which we will use during this course are defined in ITU-T Rec.X.501:

Access control

Alias

Attribute

Attribute type

Attribute value

Directory Information Tree (DIT)

Directory System Agent (DSA)

Directory User Agent (DUA)

Distinguished name (DN)

Entry

Hierarchical group

Object (of interest)

Relative distinguished name (RDN)

Root


19/37

System Overview


19

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

The directory data will then be available for a specific application part to access viaLDAP, as shown on the following figure:


Data Layer

Service Layer

(dataless)

IP network SS7 network

Network Layer

One-NDS

HLR HSS EIR AAA PCS

MSC/VLR SGSN MMSC SMSC

Fig. 10 Elements involved in the access to One-NDS


20/37

System Overview

CN66561EN92GLA0


3.2 Interfaces and Protocols

In this part, we will describe the interfaces of each One-NDS component type and theassociated protocols used in the communication.

3.2.1 R-DSA/BE DSA Interfaces

The main One-NDS Directory (routing/BE DSA) interface between the routing/BEDSAs and application servers is the LDAP interface. It is used for read-only andupdate requests.

3.2.1.1 Interface to NTFThe routing/BE DSAs send trigger notifications to the Notification Manager (NTF).

Protocol: SOAP

3.2.1.2 Interface to ADM

One-NDS Directory management functions can be performed from an ADM client(GUI) over this interface. These functions include the management of the One-NDSDirectory scheme and LDAP users, DSA administration, subscriber relocation, andADM configuration.

Protocol: LDAP

3.2.1.3 Interface to PGW

The PGW server sends all provisioning requests to the routing DSA. The provisioningrequests are handled differently in the PGW server. The corresponding provisioningresults are sent from the routing DSA to the PGW server in the opposite transmissiondirection.

Protocol: LDAP

3.2.1.4 Interface to B&R

In addition to the backup files and logs saved daily on the DS local hard disks, a dailybackup of the same DS backup files and logs is performed at the B&R server.

Protocol: SFTP

3.2.1.5 Interface to INS

The INS is first used to load the DS software and then used to perform softwareupdates.

Protocol: SFTP, BOOTP, TFTP

3.2.1.6 Interface to SM

Network element management (NEM), like fault management, is performed over thisinterface, which connects the DSAs to the @vantage Commander server and clients.

Protocol: SSH and SNMP


21/37

System Overview


21

3.2.1.7 Interface to APP-FE

Read-only and update requests are received by the routing DSA directly from the

application server (APPL).The routing DSA forwards such requests to specific BEDSAs. In the case of read-only requests, responses containing the requiredinformation are sent by the BE DSAs over the routing DSAs to the relevantapplications. After updates have been successfully performed in the BE DSAs at allsites, corresponding responses are sent over this interface to the applications.

Protocol: LDAP

This information is summed up on the following figure:

2014 Nokia Solutions and Networks. All rights reserved.

R-DSA

BE-DSAs

NTF ADM PGW B&R INS SM2 APPL

SOAP LDAP LDAP LDAPsFTP sFTP RMTP

Fig. 11 Routing/BE DSA Interfaces


22/37

System Overview

CN66561EN92GLA0


3.2.2 PGW DSA Interfaces

The main PGW DSA/Config DSA interfaces are LDAP-based interfaces between the

PGW server and PGW DSA/Config DSA. They are used for storing the PGWconfiguration and act as an intermediary server between the PGW and the One-NDSDirectory (routing DSAs and BE DSAs) Configuration data is received from the PGWserver (or ADM) over these PGW DSA/Config DSA interfaces and then forwarded asconfiguration data information to the routing DSAs.

3.2.2.1 Interface to PGW Server

The PGW stores configuration data on the PGW DSA/Config DSA. The PGWDSA/Config DSA acts as an intermediate server between the PGW and the One-

NDS Directory (routing/BE DSA).Protocol: LDAP


PGW DSA/Config DSA management functions can be performed from an ADM GUIclient over this interface. These functions include managing the PGW applicationadministration, PGW configuration data, and PGW user management.

Protocol: LDIF and SSH


23/37

System Overview


23

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


PGW-DSA

ADM PGW B&R INS SM2

LDAP

LDAP sFTP sFTP RMTPSSH

Fig. 12 PGW DSA interfaces


24/37

System Overview

CN66561EN92GLA0


3.2.3 Notification Manager (NTF) Interfaces

The Notification Manager (NTF) interfaces are SOAP-based interfaces between the

NTF and application servers, Routing/BE DSAs, and PGW. They are used forexample for transferring trigger messages from the subscriber data directories toapplications.

Subscription requests are received from the applications over the NTF interfaces andforwarded as application server subscription information to the Routing DSAs.Furthermore, the NTF can send trigger subscription messages to the RoutingDSA/BE DSAs. In the opposite direction, the NTF receives trigger messages from theRouting DSA/BE DSAs that are sent as notifications to the applications and to thePGW.


NTF management functions can be performed from an ADM client (GUI) over thisinterface. These functions include the configuration management of the NTFconfiguration data and NTF subscription data, as well as fault management,performance management, etc.

The SOAP protocol is used for update of configuration data, the LDAP is used forconfiguration change, and the SSH protocol is used for start/stop/status.

Protocol: SOAP, LDAP, SSH

3.2.3.2 Interface to APPL

The application servers are subscribed with detailed subscription data in the NTFover this interface. The NTF receives triggers from the One-NDS Directory andforwards it to the subscribed applications and to the PGW.

Protocol: SOAP

3.2.3.3 Interface to R-DSA /BE-DSA

As mentioned earlier, the NTF receives the triggers from the primary servers running

on R-DSA and BE-DSAs. Once the Trigger condition is fulfilled and detected on theDS, the trigger is directly sent to the NTF along with the subscription information, sothat the NTF knows how to handle such trigger.

Indeed, the notifications sent from the NTF to the applications depend on the type ofdata modified (Broadcast, Round Robin).

Protocol: SOAP


25/37

System Overview


25

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


NTF

ADM PGW B&R INS SM2

LDAP

sFTP RMTPSSH

R-DSA/BE-DSA

SOAP

PGW-DSA

or

stand-alone

APPL

SOAPsFTPSOAP

Fig. 13 NTF interface


26/37

System Overview

CN66561EN92GLA0


3.2.4 Provisioning Gateway Interfaces

The main PGW interface is the SPML provisioning interface between the PGW andCRM/CCC, which is used for subscriber data management.

Subscriber data is administered using this SOAP-based SPML provisioning interfaceover HTTP. Bulk files (for example, for SIM card management) or a selected set ofsubscriber data is entered over this interface. For this purpose, this SPMLprovisioning interface is based on sFTP. As an alternative to the provisioning GUIsprovided in the CRM/CCC, an SPML provisioning GUI for administering subscriberdata can also be integrated at screen-level into @Com on customer request(currently available for HLR or HSS applications).

3.2.4.1 Interface to ADMPGW management functions can be performed from an ADM client (GUI) over thisinterface. Regarding the PGW, the only protocol used in that is the SSH protocol forstart/stop/status display.

Protocol: SSH

3.2.4.2 Interface to CCC

The administration of subscriber, authentication and service data is performed overthis SPML interface based on SOAP over HTTP. A provisioning GUI client is also

available for administration.Furthermore, the CRM/CCC (Customer Care center) sends bulk files containing themultiple SPML request over the other SPML interface using secure FTP (sFTP).

Protocol: SPML

3.2.4.3 Interface to NTF

The PGW receives notifications from the NTF.

Protocol: SOAP

3.2.4.4 Interface to R-DSA

The PGW communicates with the R-DSA for transactions and read-only requests.This is basically the continuation of the messages received from the CCC aftertranslation to LDAP protocol by the plug-ins running on the PGW.

Protocol: LDAP


27/37

System Overview


27

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


PGW

ADM NTF B&R INS SM

SOAP sFTP RMTPSSH SPML

CCC

sFTP

PGW-DSA

LDAP

R-DSA

LDAP

Fig. 14 PGW interfaces


28/37

System Overview

CN66561EN92GLA0


3.2.5 One-NDS Administrator (ADM) Interfaces

Administration tasks are performed over the ADM. All functions can be conveniently

carried out over the ADM GUI, which can be launched from the @Com client.Furthermore, data directory management is integrated in the @Com faultmanagement, and secure shell (SSH) access from @Com to the ADM is supported.

3.2.5.1 Interface to NEM

Network element management, such as configuration and fault management, isperformed over this interface, which connects the ADM to the @vantage Commanderserver and clients.

LDIF files can also be received by the ADM from the schema designer over the

@Com and the sFTP interface. The ADM then uses these LDIF files to update theOne-NDS Directory schema on all DSAs within the in-memory LDAP of the One-NDSDirectory.

Protocol: SNMP, sFTP, SSH

3.2.5.2 Interface to R-DSA/BE DSA

One-NDS Directory management functions can be performed from an ADM GUIclient (DB management part) over this interface. These functions include theconfiguration management of the One-NDS Directory schema and LDAP users, DSA

administration, subscriber relocation, and ADM configuration, as well as faultmanagement, performance management, etc.

Protocol: LDAP

3.2.5.3 Interface to PGW-DSA

Over this interface, PGW configuration, secure administration of PGW passwords,and browsing and downloading command logs can be performed using @Com. Forthis purpose, the ADM GUI is integrated at screen-level in the @Com clients.


3.2.5.4 Interface to NTF

NTF management functions can be performed from an ADM client (GUI) over thisinterface. These functions include the configuration management of the NTFconfiguration data and NTF subscription data, as well as fault management,performance management, etc.



29/37

System Overview


29

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


ADM

B&R INS SM2

sFTP RMTP

SSH

sFTP

R-DSA/BE-DSA

LDAP

NTF

SSH

PGW-DSA

LDAP

SSH

PGW

SSH

Fig. 15 ADM interfaces


30/37

System Overview

CN66561EN92GLA0


3.2.6 Interfaces and Protocols wrap-up

Here is a wrap up on all interfaces and protocols used either when accessing or

inside the One-NDS:

R-DSA

BE-DSAs

application FEs

CRM

HLR HSS AAALDAP

PGW-DSA

incl. NTF

PGW

ADMLDAP

SPML

SOAPLDAP

Trigger

SOAP

Notify

SOAP

Notify

SOAP

ssh

LDAP

Fig. 16 Interfaces and Protocols wrap-up


31/37

System Overview


31

3.3 Network Connectivity

In order to separate the traffic taking place between specific elements inside the One-NDS and for security reasons, multiple networks are used. According to the type ofcommunication taking place, we also need two types of communication infrastructure:

Local-site Network

Inter-site Network

3.3.1 Local-site network

This network is implemented as an IP local area network (LAN).

The local site network interconnects servers located at the same physical locations.Typically, the LAN is deployed as a switched Ethernet network.

The LAN provides full path redundancy, that is, at least two independent paths mustbe available between any two servers that have direct connections. This includescabling as well as switches used in the network.

The local-site network is used for the following purposes:

3.3.1.1 OAM LAN and B&R LAN

The OAM network carries the remote management traffic used to perform the variousmanagement tasks for:

Alarm forwarding

Availability management.

Remote management.

Software update management.

Backup and restore.

Administration.

3.3.1.2 Application LAN

The application network carries the client-side traffic to the One-NDS entities:

Basically all LDAP requests issued from clients to the routing DSA.

SPML requests submitted to the provisioning gateway.


32/37

System Overview

CN66561EN92GLA0


3.3.1.3 Data Base LAN

The Database network carries out the requests between the Routing-DSA and the

BE-DSAs. The connections between all database servers shall be gigabit Ethernetfor performance reasons. The latency of the network impacts directly the responsetimes of the database for update requests (since the data on the BE-DS of a tripletare always kept in synch.).

3.3.1.4 HLR/AuC LAN

A good example of a strictly local-site network is the HSM LANs (HLR/AuC LAN),implemented on dedicated hardware. The HSM LANs will only connect HLR-FEs andHSM modules; the LANs will not be visible from any other part of the network.Therefore, this LAN will not be discussed during the course.

3.3.2 Inter-site network

This network is implemented as an IP wide area network (WAN).

The inter-site network connects the different sites with each other for One-NDSDirectory inter-site traffic. This is deployed as a wide area network (WAN) becausethe sites are typically deployed approximately one hundred kilometers apart from oneanother. A dedicated network between the sites is highly recommended for exclusiveuse by One-NDS and application servers.

The inter-site network is used for the following purposes:

3.3.2.1 OAM LAN and B&R WAN

The OAM WAN is used by the One-NDS Directory for inter-DS re-synchronizationafter routing/BE DSA server failure (makes copy of backup and log files).

3.3.2.2 Application WAN

The application WAN can be used in various cases:

To allow an application server to access the One-NDS Directory if an applicationserver is not deployed locally.

To access the PGW from customer care and operations systems.

To access to a remote One-NDS Directory site if a local one is unavailable.

3.3.2.3 Data Base WAN

The Database WAN is used in case of One-NDS Directory updates synchronizationfor servers belonging to the same Routing/BE DSA and also to read traffic if a localrouting/BE DSA fails.


33/37

System Overview


33

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

These different networks and the elements using them are summed up in thefollowing figure:

BE-DSA

IS B&R ADM

HLR HSS AAAR-DSA PGW PGW-DSA

CRM

OAM

B&R

APP

DSA

One-NDS components non One-NDS components

SM

Fig. 17 Summary of Network Connectivity inside One-NDS


34/37

System Overview

CN66561EN92GLA0


3.4 Ports

For each type of communication towards or inside the One-NDS, we distinguish,along with the protocols used, specific ports.

The list is long, but here are the most important ones to remember, again, classifiedby functional components.

Protocol Ports Purpose

LPDAP 16601 Low priority DAP; Currently not used by NSN

DSA_INTER 16602 Inter-DSA communications; for example, search /update chaining

SCF_PROV 16603 Provisioning; a form of DAP with bespoke TCP/IPwrappers

SDF_STATUS 16606 Bespoke protocol for enquiring the status of a DSserver

nms_alarm 16608 Bespoke protocol for DS alarm events

nms_stats 16609 Bespoke protocol for triggering statistics file (af03)rotation

SDF_INTER 16610 Inter-DS replication

LDAP 16611 LDAP service interfaceMODE_LDAP 16612 Mode sensitive LDAP - responds only on Primary or

Secondary Synchronized servers

DS_RECON 16613 Inter DS Reconciliation monitoring

DS_NONDIR 16614 Non-Directory Data. In particular, used in theprocessing of Variant Objects

LDR_CLIENT 16616 Inter DSA router client port

DS_NDDR 16617 Local nddr connections

DS_ALIAS 16618 Alias verification utility port

DS_SNMP 16650 DS SNMP Port

SOAPC 16700 DS SOAP Client port

SYCOLINK 16701 Sync Controller port


35/37

System Overview


35

Protocol Ports Purpose

SOAP 10081-10090

SOAP port for trigger reception

ICMP Internet Control Message Protocol

SSH 22 Secure shell service for remote maintenance

SSH 22 Used for software update mechanism via installation-server

SFTP 22 Secure FTP service for bulk data transfer

TFTP 69 Used for first installation of the network element

RPC 111 RPC bind for NFS

NFS 2049 For transfer of software from the installation server

NTP 123 NTP client to keep the system time synchronizedamong the servers

SNMP 161 SNMP service to receive management requests

SNMP 162 SNMP service to receive management traps

SNMP 43821 Simple Network Management Protocol

SOAP / SPML 8081-8090

SOAP embedded SPML service

HTTPS 443 Web GUI, SOAP over HTTPS



Proprietary 55504 Used for first installation

Proprietary 55555 Control port for software upgrade

Proprietary 7937-9936

Communication for backup & restore (NEBR)

Proprietary 10001-

30000

Communication for backup & restore (NEBR)


36/37

System Overview

CN66561EN92GLA0


These different protocols and the elements using them to communicate are summedup in the following figure:


R-DSA

BE-DSA

application FEs

CRM

HLR HSS AAA

PGW-DS

incl. NTF

PGW

ADM SSH

LDAP

INS BOOTP

TFTP

B&R SSH

SFTP

SOAP

10180-

10181

NTF

LDAP

16612

SOAP

30300

LDAP

16612

LDAP

16611

HTTPS

30600

SPML-SOAP-HTTP

8081-8090

SPML-file/SFTP

SOAP

10180-

10181

DAP, DOP, DSPNetworks

APP

OAM

DB/DSA

Fig. 18 Summary of Protocols used by One-NDS

F


37/37

System Overview

3.5 Operating System Users and Rights

Multiple users are accessing the One-NDS for different purposes. We have indeedLDAP users, connecting from LDAP clients, SPML/SOAP users, related to theprovisioning phase between the CRM and the PGW, HLR/HSS WebGui users for thecustomers who use them and so on.

However, when it comes to management and troubleshooting of the system, what isimportant to know is which tasks can be performed by which OS user.

Therefore, here is a listing of those users associated to the server they are used on:

NE Type User Group Runtime Login Remote Usage

DS root root Yes Yes No System admin

sdfrun sdf Yes Yes Yes DB Admin

cntdb users No Yes Yes Non Admin

oamsys users Yes Yes Yes @Com Admin

NTF root root Yes Yes No System admin

sdfrun sdf Yes Yes Yes DB Admin



notifs notifs Yes Yes Yes NTF Admin

PGW root root Yes Yes No System admin

provgw provgw Yes Yes Yes PGW Admin

provgw No Yes Yes Bulk DataInterface



ADM root root Yes Yes No System admin

dbmrun users Yes No No ADM Admin



01 CN66561EN92GLA0 System Overview

Documents

Transcript of 01 CN66561EN92GLA0 System Overview