a

SOLUTION DESCRIPTION

Network Monitoring System

::: Issued Date 18 April 2009

::: Author Walter Buehler / Angel R. Mora

::: Issued by Nexus Telecom, Switzerland

::: Offer Number Z08.A.232 Ed. 13

NexusNETVIEW | Solution Description | V0.1 | 04DEC2008 | © Nexus Telecom Page 2 of 104

Table of Contents

1 Introduction....................................... ............................................................................ 3

2 Overview........................................... ............................................................................. 3

3 Technical requirements............................. ................................................................... 3 3.1 System Requirements............................................................................................ 3

3.1.1 Modular Structure (6.1.1, 6.1.2, 6.1.6) ................................................................................... 3 3.2 System Architecture............................................................................................... 3

3.2.1 Supported Interfaces (6.2.1.3)................................................................................................ 3 3.2.2 TDM & SIGTRAN Links (6.2.1.6) ........................................................................................... 3 3.2.3 Map Information (6.2.1.12)..................................................................................................... 3 3.2.4 Database Access (6.2.1.21)................................................................................................... 3 3.2.5 Backup and Restore (6.2.5) ................................................................................................... 3 3.2.6 Central Server (6.2.7.1).......................................................................................................... 3 3.2.7 System Extensions (6.2.8.4/5) ............................................................................................... 3 3.2.8 Client Workstations (6.2.9.4) .................................................................................................. 3

3.3 System Performance ............................................................................................. 3 3.3.1 "Peak Busy Hour" Handling Capabilities (6.3.1)..................................................................... 3 3.3.2 System Bottlenecks & Limitations (6.3.3/7)........................................................................... 3 3.3.3 Data Granularity (6.3.8).......................................................................................................... 3

3.4 Probe Performance Requirements......................................................................... 3 3.4.1 Throughput Capacity (6.4.14/6.4.17)...................................................................................... 3 3.4.2 Probe Extensions (6.4.16)...................................................................................................... 3

3.5 System Administration ........................................................................................... 3 3.5.1 User Administration (6.5.13)................................................................................................... 3

3.6 Application Requirements ...................................................................................... 3 3.6.1 Reports and KPI (6.6.3.2) ...................................................................................................... 3 3.6.2 Measurements for SS7 and SIGTRAN (6.6.3.3) .................................................................... 3 3.6.3 Report Samples (6.6.3.4) ....................................................................................................... 3 3.6.4 Aggregation Level (6.6.3.4.9) ................................................................................................. 3 3.6.5 Statistical Alarms (6.6.3.4.10) ................................................................................................ 3 3.6.6 Scheduled Reports (6.6.3.4.14) ............................................................................................. 3 3.6.7 Service Related Reports (6.6.3.4.22) ..................................................................................... 3 3.6.8 Call Trace Filters (6.6.5.1.13)................................................................................................. 3 3.6.9 GPRS Reports (6.6.5.4.5/6) ................................................................................................... 3 3.6.10 Service-related Reports (6.6.5.4.6/11) ................................................................................... 3 3.6.11 On-demand Performance Reports (6.6.5.46)......................................................................... 3 3.6.12 International Roaming Monitoring (6.6.5.6) ............................................................................ 3

3.7 Filter Functionality.................................................................................................. 3 3.8 Call Trace Functionality.......................................................................................... 3

3.8.1 Performance of Call Trace (6.8.3) .......................................................................................... 3 3.9 Protocol Analysis ................................................................................................... 3

3.9.1 PAT Performance (6.9.1/2) .................................................................................................... 3 3.10 Supported Protocols and Interfaces ....................................................................... 3

3.10.1 Signaling Protocols (6.10.1/2) ................................................................................................ 3 3.10.2 Gb Deciphering (6.10.7)......................................................................................................... 3

3.11 CDR - TDR Generation (Call Data Records) .......................................................... 3 3.11.1 Data Base (6.11.1.7) .............................................................................................................. 3 3.11.2 Export Interface (6.11.1.8)...................................................................................................... 3 3.11.3 NexusSCENE Reports using CDR (6.11.1.12/13).................................................................. 3

3.12 A and Iu Interface Quality and Performance Monitoring ......................................... 3 3.12.1 A and IuCS Interface Measurements ..................................................................................... 3 3.12.2 IuPS Interface Measurements................................................................................................ 3

3.13 VoIP and SIP Tracing and Related Statistics Analysis ........................................... 3


3.14 Traffic Management ............................................................................................... 3 3.15 Alarm Handling ...................................................................................................... 3

3.15.1 Link-based Alarms (6.15.22) .................................................................................................. 3 3.15.2 Service-related Alarms........................................................................................................... 3 3.15.3 System-internal alarms .......................................................................................................... 3

3.16 Roaming Management System.............................................................................. 3 3.16.1 International Roaming Monitoring (IRM2)............................................................................... 3

3.17 LAN/WAN Requirements ....................................................................................... 3 3.17.1 Bandwidth Demand between Probes and Central Server (6.17.1.1/2)................................... 3 3.17.2 Bandwidth Demand of Client Workstation (6.17.1.3).............................................................. 3

4 Hardware ........................................... ............................................................................ 3 4.1 Power requirements............................................................................................... 3

4.1.1 Power Consumption (7.1.3/5)................................................................................................. 3 4.2 Electrical Safety ..................................................................................................... 3 4.3 Electro-magnetic Compatibility............................................................................... 3 4.4 Mechanical design ................................................................................................. 3

4.4.1 Probe Layouts (7.4.1)............................................................................................................. 3 4.5 Environment Conditions......................................................................................... 3

4.5.1 Environmental Conditions (7.5.1) ........................................................................................... 3 4.6 Hardware Specification .......................................................................................... 3

4.6.1 Hardware Components (7.6.2) ............................................................................................... 3

5 Software........................................... .............................................................................. 3 5.1 Software Standards ............................................................................................... 3 5.2 Basic Software....................................................................................................... 3 5.3 Application Software .............................................................................................. 3

6 Availability and Redundancy ........................ ............................................................... 3 6.1 Availability.............................................................................................................. 3 6.2 Redundancy........................................................................................................... 3 6.3 Geographical & Physical Independency................................................................. 3

6.3.1 Geographical Independencies (9.3.1.2) ................................................................................. 3

7 Technical support and Software Update Services..... ................................................. 3 7.1 Basic requirements ................................................................................................ 3

7.1.1 3rd Party Hardware (10.1.7).................................................................................................... 3 7.1.2 3rd Party Software (10.1.7) ..................................................................................................... 3

7.2 Technical assistance.............................................................................................. 3 7.3 Hardware Support.................................................................................................. 3 7.4 Software support.................................................................................................... 3 7.5 Maintenance Spare Parts....................................................................................... 3 7.6 Long Term System Support ................................................................................... 3

8 Operation and Maintenance & Security............... ........................................................ 3 8.1 O&M Processes (11.1.1)........................................................................................ 3 8.2 Configuration Management (11.2.1)....................................................................... 3 8.3 Performance Management (11.3.1) ....................................................................... 3 8.4 Security (11.4.1/2).................................................................................................. 3

9 Training Program and Requirements .................. ........................................................ 3 9.1 Training requirements ............................................................................................ 3

9.1.1 Training Program (12.1.1) ...................................................................................................... 3 9.2 Training in Oman ................................................................................................... 3

10 Documentation...................................... ........................................................................ 3 10.1.1 Documentation (13.1.2).......................................................................................................... 3



1 Introduction

This paper describes the proposed system to Nawras. Furthermore it provides answers to some of

requirements in the sections 6 to 14 of the RFP.


2 Overview

NexusNETVIEW is the most powerful signaling and data monitoring system on the market. For

example it covers the entire GSM/GPRS network of T-Mobile, Germany. It is very scalable and,

therefore, can monitor a small number of links only and later can be extended to cover additional parts

of the network.

NexusNETVIEW uses a server/client architecture.

Figure 1: System Architecture of NexusNETVIEW

The system consists of:

::: Probes installed at the different sites. These probes collect the raw data and stores it on their own

HDD. It uses servers from SUN and HP.


::: Central server located at one site. It is a SUN server using SUN Solaris. It aggregates the

measurements and the CDR information from the different probes in real-time and stores this

information in a central database.

::: An optional reporting server for the NexusSCENE reporting framework (see chapter 0).

::: Client workstations located at different sites. These are normal Windows XP-based PC.

Figure 2 shows the SW architecture. There is the Base System into which different core modules are

plugged in:

::: Protocol Centric core module does Protocol Analysis and provides the detailed protocols decodes

to the user of the system.

::: User Centric core module, which handle the E2E Full Session Analyzer (FSA)

::: Network centric which provides all the KPI/Measurements

::: Alarm Management module to forward threshold and system alarms to an umbrella system and

visualize them in the dedicated Alarm window

Figure 2: SW Architecture of NexusNETVIEW

The users access the system via a Java-based GUI, by which information from the different core

modules can be retrieved and real-time, on-demand reports can be viewed.


There are different export interfaces available:

::: XML-based CDR and KPI export to for example Fraud detection, Billing verification, Welcome

SMS systems, etc.

::: Alarm interface, based on SNMP traps

::: Configuration Management interface, using XML


3 Technical requirements

3.1 System Requirements

3.1.1 Modular Structure (6.1.1, 6.1.2, 6.1.6)

The proposed NexusNETVIEW system consists of:

::: Distributed probes

::: Central servers, collecting CDR and KPI from the probes for very fast user responses

::: Client workstations

These are described below:

3.1.1.1 Distributed Probes

In general probes of NexusNETVIEW are made up of:

::: Pre-Processing Element (PPE), which consist of the interface modules. It pre-processes the data

streams read from the physical interface, e.g. filter-out (if required) user plane information, and

forwards the information to the DPE. Often these modules are plugged directly into the DPE. Only

in cases where a high number of E1 interfaces have to be monitored a 19" rack is used to hold

these modules. The following type of interfaces are available (list of supported protocols can be

found in chapter 3.10):

− E1/T1 Interfaces, channelized, HSL (High Speed Link) or Frame Relay

− 100/1000 Base-T Interfaces

− 1000 Base-SX Interfaces

− 10 GigE Interfaces (with next release)

− STM-1, ATM

− STM-1, E1 (VC12) channelized or HSL

::: Data Processing Element (DPE): Reads the data from the PPE and processes the raw data

before uploading the information to the central application server. One strength of

NexusNETVIEW is its scalability. In cases the probe has to handle high traffic the process, which

stores the raw data (Writer process) runs on a different server than the processes, which analyze

the raw data (Reader processes). The number of Reader servers depends on the traffic to be

analyzed.


::: Data Storage Element (DSE): Raw data read from the PPE is stored on the DSE. In case of high

traffic or long storage time external HDD storage elements are used, otherwise the internal HDD

of the DPE responsible for reading the data from the PPE is sufficient.

::: These elements are interconnected via TCP/IP links by means of a switch.

Figure 3: General Probe Design

3.1.1.2 Central Server

The central server is composed of different servers having unique functionality:

::: CDR Correlation and KPI Aggregation:

This server is responsible for:

− Correlating leg information from the probes for creating CDR for every session subscribers

establish. These CDR are stored in the central database for fast access by the user of the

monitoring system.

− Collecting and aggregating basic-KPI from the probes. These basic-KPI are stored in the

central database as well.


Data from this server can be accessed via dedicated Java application running on the client

workstation.

::: Service Performance Analyzer:

The Service Performance Analyzer (SPA, is not part of the offer) can be used as a stand-alone

tool, also in conjunction with another monitoring system. It collects information from the dedicated

probe and creates reports as described in chapter 3.6.10.

Report data collected and generated by this server can be accessed via WEB browser.

::: Reporting Framework Server:

The reports are generated by an adjunct process called NexusSCENE, which often runs on a

dedicated server. These reports can be accessed via WEB browser.

3.1.1.3 Client Workstation

Any Windows based PC can be used as client. The minimum client configuration requires:

− Pentium 4 CPU

− 1 GB RAM

− 80GB HDD

− 100BaseT

− CD/DVD Drive

− Windows XP

3.2 System Architecture

As described above NexusNETVIEW consists of distributed probes, client server and client

workstations.

3.2.1 Supported Interfaces (6.2.1.3)

This chapter generically describes the interfaces that are supported by the NexusNETVIEW system.

The system configuration proposed to NAWRAS is described in the chapter 3.2.2.

There the following types probe configurations (Note: all use the same types of probe server):


3.2.1.1 TDM Interfaces

::: E1/T1 Compact Probe Configuration

This probe configuration (see Figure 4) uses on probe server and can handle up to 4 bi-

directional E1, carrying either:

− SS7, BSSAP, ISDN, etc. in a total of 124 signaling links.

− SS7, BSSAP, ISDN, etc. in HSL links

− Gb in Frame Relay

Figure 4: Example of a E1/T1 Compact Probe for up t o 4 E1 Interfaces

::: E1/T1 Probe Configuration

This probe configuration (see Figure 5) uses one or more probe servers and can handle the same

type of E1/T1 as the Compact Probe Configuration. The interface modules are plugged into one

19" sub-rack. A fully equipped 19" sub-rack can handle up to 256 bi-directional E1/T1 or up to

1984 signaling channels.


Figure 5: Example of a E1/T1 Probe for up to 64 E1 Interfaces

Also there are STM-1 interface modules available, which can extract signaling channels or HSL from

STM-1, in VC12 containers. These interface cards are plugged into the same 19" sub-rack as the

E1/T1 interface modules.

3.2.1.2 ATM-based Interfaces

NexusNETVIEW at the moment supports two types of ATM-based interfaces:

::: E1/T1 – probe configuration see above.

::: STM-1/ATM, optical.

Today1 the STM-1/ATM probe can handle a total traffic of up to 200 Mbps and consists of one or more

probe server and STM-1 interface cards directly plugged into the probe server (see Figure 6). The

interface card is equipped with filters, to, for example, filter-out payload and keeps signaling traffic

only. These probes are mainly used to analyze traffic of IuCS and IuPS.

1 The performance oft he probes is constantly improved.


Figure 6: Example of an STM-1 Probe for 4 STM-1

3.2.1.3 IP-based Interfaces

NexusNETVIEW supports the following different types of IP-based interfaces:

::: 100/1000 Base-T Interfaces

::: 1000 Base-SX Interfaces

::: 10 GigE Interfaces (with next release)

As the STM-1/ATM probe the IP probe can handle a total traffic of up to 200 Mbps and consists of one

or more probe server and interface cards directly plugged into the probe server (see Figure 7)2. The

interface card is equipped with filters, to, for example, filter-out payload and keeps signaling traffic

only. These probes are handling the following type of protocols:

::: Circuit switched protocols:

− SIGTRAN, i.e. MAP, BICC, ISUP, etc.

− SIP

− MEGACO/H.248

− H.323 (with next release)

− Etc.

2 One probe server can carry up to 2 interfaces, each handling up to 2 bi-directional links


::: Packet switched protocols:

− Gn, control (GTP) and user plane

− Gi, control (DNS, RADIUS) and user plane

Figure 7: Gig-Ethernet Probe for 4 100/1000Base-T

3.2.2 TDM & SIGTRAN Links (6.2.1.6)

The proposed system is designed to avoid duplicated collection of messages, mainly to have low

investment cost and at the same time have highest benefit from it.

The monitoring NexusNETVIEW solution proposed to NAWRAS takes advantage on the fact that

most signaling can be capture on the SIGTRAN FE interfaces of the R4 network. This allow the

system to capture and monitor A-interface protocols ( BSSAP) and IuCS protocols ( RANAP), but no

equipment need to be deployed to pat the STM-1 physical interfaces. Further MGW signaling is

available on the MSS interfaces and therefore no probes need to be a deployed on MGW GE

interfaces.

In additional to the SIGTRAN Fe interfaces, the proposed NexusNETVIEW proposal is configured to

monitor TDM SS7 links, that shall be Tapped on E1 lines ( 120 Ohms, on the Huawei DDF).

The proposed system is designed to avoid duplicated collection of messages, mainly to have low

investment cost and at the same time have highest benefit form it.

The following table summarizes the interfaces that are directly tapped :


NETWORK Summary ( update March. 31st. 2009)

Interfaces/Sites Muscat 1 Muscat 2 Nizwa Salalah Sohar

LSL/E1 82//64 138/94 72/68 4/4 60/60 SIGTRAN (FE) 14+14 4+4 14+14 2+2

Gb and IuPS (GE) 8 Gn (GE) 4 GRX/Gp (FE) 2+2

Configuration Details:

1.- MGW signalling is capture at the MSS. Probes on the MGW GE are not needed

2.- BSSAP ( HSL) is capture over SIGTRAN. Probes on the HSL are not needed

3.- RANAP ( IuCS) is capture over SIGTRAN. Probes on the IuCS( STM1) are not needed.

4.- Raw Data Storage on Probes is 15 days

5.- CDR storage on Central server is 30 days @ 70 Millions CDR per day

6.- One additional cabinet for Ethernet TAP

Fast Ethernet lines are active + passive link. Both links are tapped, but traffic is carried only on the

active link and on the passive link only in case of failure if the active one. This fact is taken into

account for the dimensioning of the row data storage on the probes.

The proposed solution consist of monitoring equipment that shall be installed on each of the 5 sites.

All probes shall be connected to the System central server over NAWRAS data network ( WAN). The

System server is suppose to be installed in Muscat 2, but could be installed in any other site too.

The architecture of the Nexus pores allow the storage of the row signalling data directly on the probe

and therefore reduces the bandwidth requirement on the WAN.


3.2.2.1 Equipment Footprint:

The space requirement for the probe as listed below. On each site an additional 19” cabinet is

required to hold the Ethernet TAPS.

Muscat 1: 2x 19” cabinet for the probe and 1x 19” cabinet for Ethernet TAPs

Muscat 2: 1x 19” cabinet for the probe, 1x 19” cabinet for NMC Equipment, and 1x 19” cabinet for

Ethernet TAPs

Nizwa: 1x 19” cabinet for the probe and 1x 19” cabinet for Ethernet TAPs

Sohar: 1x 19” cabinet for the probe and 1x 19” cabinet for Ethernet TAPs

Salalah: 1x 19” cabinet for the probe and 1x 19” cabinet for Ethernet TAPs

NexusNETVIEW Equipment deployment


3.2.2.2 Signaling traffic for System Dimensioning

The propsed solution is dimensioned for to handle the traffic according to the information disclosed by

NAWRAs in several clarification meetings.

For the dimensioning of the central we have estimated 70 millions CDR per day. NexusNETVIEW

generate CDR for each call attempt ( successful and successful ), location update, SMS , and PDP

context ( including MMS).

Nawras has confirmed the following utilization factors for the NMS System Dimensioning

factors for the probes.

a. Utilization is 40% for C7 TDM Links-64 Kbps. .

b. Gb interface at 500kbps per PCU, 13 PCU per SGSN, resulting 6.5Mbps at the GE interface

c. Loadsharing on the Gn, GE interfaces d. IuPS traffic is estimated at 4Mbps e. 15 days for row data storage and 30 days for CR storage. f. Utilization is 30% for SIGTRAN FE Links (100% is 9.7 Mbps).

But Utilization is 50% for MUMSCS1, MUMSCS2& 3G MSCS1 SIGTRAN FE

Links

(100% is 9.7 Mbps).

SIGTRAN Links are working at 1+1 (ACTIVE + STANDBY) Mode at present.

Standby Link doesn't carry any traffic. Please refer statistical data.

SIGTRAN Utilization is given for TX or RX direction only.

Following the advice of i NAWRAs, Nexus Telecom has dimensioned the row data storage

buffer on the probes ( 15 days ) based on the traffic figures given in the annex-5,

“Network statistics”.

3.2.2.3 Equipment Breakdown

The equipment break down for the proposed configuration is as follow:

Equipment/Sites Muscat 1 Muscat 2 / NMC

Nizwa Salalah Sohar

Cabinet 3 3 2 2 2 LAN switch 2 2 1 0 1

LSL Subrack 1 1 1 0 1 D16MI LSL 4 6 5 0 4

2x E1/T1 Module 0 0 0 1 0 32/2 E1 Grromer 1 Patch Panel 4 6 5 1 3 LSA 2/2 32 47 34 2 30


120 Ohm Cable 16 24 17 1 15 DELL 2950 LSL 1 1 1 1 1

SIGTRAN FE Muscat 1 Muscat 2 Nizwa Salalah Sohar

FE 8/4 TAP-AGGREGATOR

0

FE 12/4 TAP-AGGREGATOR

2 1 2

FE 1/1 TAP 4 GiE card 4 1 4 0 2 DELL 2950 2 1 2 0 1 Gb and IuPS( GE) Muscat 1 Muscat 2 Nizwa Salalah Sohar

GE 1/1 TAP 8 GiE card 4 DELL 2950 2

Gn ( GE) Muscat 1 Muscat 2 Nizwa Salalah Sohar

GE 1/1 TAP 4 GiE card 2 DELL 2950 1

GRX/Gp ( FE) Muscat 1 Muscat 2 Nizwa Salalah Sohar

FE 1/1 TAP 4 GiE card 2 DELL 2950 1 NMC SUN M3000 1 SUN ST2510 1 DELL 2950 ( CDR) 1 DELL 2950 (SCENE) 2 DELL 1950 (Client Server)

2

3.2.2.4 Estimated Signaling traffic


Nexus Telecom has made an estimation of the actual signaling traffic on NAWRAS’ network using the

traffic figures given in the Network Statistics Document ( Excel file).

The estimated traffic is lower than the figures given for the system dimensioning. Therefore Nexus can

assure with confidence that the proposed solution will meet NAWRAs’ requirements for data storage

and will be able to handle the actual traffic.

bytes per event Total bytesTotal Call Attempts in A-Interface + Iu-CS 12,988,090 450 5844640500Roaming,HO & CF Cases Over head @ 15% 1948213.5 150 292232025Total Call Attempts Per Day. 14,936,304 6136872525

568 kbps (average)

Total Call Attempts in A-Interface @ BH 1033384 450 465022800Roaming & CF Cases Over head @ 15% 155007.6 150 23251140Total Call Attempts @ BH. 1188392 488273940

1085 kbps (BH)

BH % of Calls per day 7.96%

MUMSS1 (A Interface) bytes per event Total bytesTotal Call Attempts in A-Interface + Iu-CS 4,690,300 450 2110635000Roaming,HO & CF Cases Over head @ 15% 703545 150 105531750Total Call Attempts Per Day. 5,393,845 2216166750

205 kbps (average)391 kbps (peak, calculated)

MUMSS2 (IuCS Interface) bytes per event Total bytesTotal Call Attempts in A-Interface + Iu-CS 1,194,318 500 597159000Roaming,HO & CF Cases Over head @ 15% 179147.7 180 32246586Total Call Attempts Per Day. 1,373,466 629405586


NIMSS1 (A Interface) bytes per event Total bytesTotal Call Attempts in A-Interface + Iu-CS 6,124,376 450 2755969200Roaming,HO & CF Cases Over head @ 15% 918656.4 150 137798460Total Call Attempts Per Day. 7,043,032 2893767660


NIMSS2 (A Interface) bytes per event Total bytesTotal Call Attempts in A-Interface + Iu-CS 979,096 450 440593200Roaming,HO & CF Cases Over head @ 15% 146864.4 150 22029660Total Call Attempts Per Day. 1,125,960 462622860



Total MMS 115099Bytes per MMS: 30000 Estimated avg. ValueTotal bytes per day: 3,452,970,000

320 kbps (average)768 kbps (peak)

Total 14,449,002Bytes per SMS 180Total Bytes per day 2,600,820,360

241 kbps (average)578 kbps (peak)

3G+2G Attempts-GPRSAttach Attempts-GPRSDetach Attempts-ActivationPdpContext Attempts-DeactivationPdpContextTotal 533763 389544 588673 352062

200 100 180 90106,752,600 38,954,400 105,961,140 31,685,580

10 4 10 3 27 kbps (average)24 10 24 7 65 kbps (peak)

Total 2G SGSN Attempts-GPRSAttach Attempts-GPRSDetach Attempts-ActivationPdpContext Attempts-DeactivationPdpContextTotal 436388 337915 496028 281234

200 100 180 9087,277,600 33,791,500 89,285,040 25,311,060


Total 3G SGSN Attempts-GPRSAttach Attempts-GPRSDetach Attempts-ActivationPdpContext Attempts-DeactivationPdpContextTotal 97375 51629 92645 70828

250 120 210 11024,343,750 6,195,480 19,455,450 7,791,080


3.2.3 Map Information (6.2.1.12)

Measurements can be visualized in geographical maps (see Figure 8). The map is generated during

configuration of the system and can be updated by users, which have the access right to do so.

The user can click on these links and gets its measurements and from there he can drill-down further.

Also in the next release alarms are flagged on the map as well.


Figure 8: Geographical Map for Measurements

3.2.4 Database Access (6.2.1.21)

NexusNETVIEW is designed for highest performance for not loosing any message or call, which is

very essential for a monitoring system. Nexus does not recommend to lett 3rd party tools access the

database directly, because this might impact the performance of the system. Therefore, Nexus

provides an XML export interface by which measurements and CDR can be exported to external tools.

The XML Export Interface provides data via data streams. Each data stream is a TCP/IP connection

between the NexusNETVIEW server and the "Data Consumer". The following data streams are

available:

::: Voice call CDR

::: GPRS session CDR

::: SMS CDR

::: Location Update CDR

::: GPRS Performance data, generated by the application GPE


::: Network performance data, generated by the application NPE

The flow of control for one Data Consumer to connect to the data export interface and commence to

receive data is as follows:

Figure 9: Flow control between data export interfac e and a data consumer

After the Data Consumer has set-up the TCP connection it initiates the data flow by providing

parameters to specify the data that is expected and delivery options such as time intervals. The export

interface then sends Data Records as the Data Consumer has specified.

It is possible to connect different data consumers to the NexusNETVIEW export interface and each

can create its own data stream.

3.2.5 Backup and Restore (6.2.5)

NexusNETVIEW includes basic backup procedures to avoid loss of data if the system breaks.

Database information is backed-up and can be restored if required.

Additional saving/archiving operations can be implemented and should be agreed during contract

negotiation.

3.2.6 Central Server (6.2.7.1)

NexusNETVIEW is designed to gather CDR and KPI in real-time for large networks and very heavy

signaling traffic. To some extend this contradicts with the need of having very flexible reporting,


because the report creation process may not influence the performance of the collection, aggregation

and correlation process of the base system. Therefore, Nexus has designed a reporting tool, called

NexusSCENE, which can correlate the KPI or CDR from NexusNETVIEW to higher level KPI/KQI (see

Figure 10).

Figure 10: Aggregation Process: NexusNETVIEW to Nex usSCENE

All activities in the network, such as Call Attempts, SMS/MMS, Location Updates and GPRS or UMTS

Sessions, are stored as Communication Detail Records (CDR) in the NexusNETVIEW database for a

configurable amount of days. These CDR contain all CLR (Communication Leg Record) information

that contributes to a successful Call or Session in the network. Furthermore, these CDR are enriched

with information collected on all legs along their way from calling party to called party. The

NexusNETVIEW can export these CDR together with the CLR to NexusSCENE for provisioning real

“near-real-time” ad-hoc reporting capability to operators.

The basic KPI, which are created by NexusNETVIEW, can be visualized as so called canned reports

and are available on-demand and in real-time. NexusSCENE, as a very flexible reporting tool,

receives information from NexusNETVIEW and creates customer tailored reports either scheduled or

on-demand.


Figure 11 shows the interworking of NexusNETVIEW and NexusSCENE. NexusSCENE receives the

data via XML based data streams. This data is processed and aggregated into KPI/KQI before being

stored in the database. These KPI/KQI are now available for reports using parameters provided by the

user. These reports can be either scheduled or generated immediately. NexusSCENE reports can be

generated as PDF files or exported as CSV files.

Figure 11: NexusNETVIEW and NexusSCENE Overview

3.2.7 System Extensions (6.2.8.4/5)

Each component can be expanded as follows:

::: Distributed Probes:

− Probes can be extended by additional interface cards.

− Because probes and clients are interconnected to the central server, these can be added ore

removed without interrupting the system.

− HDD are hot-pluggable and, therefore, HDD storage can be extended while the system is

running

− Additional probe servers can be added

::: Central server:


− Can be extended by an external HDD.

− HDD are hot-pluggable and, therefore, HDD storage can be extended while the system is

running

− To extend it further additional CPUs are required, which can be added to the server.

3.2.8 Client Workstations (6.2.9.4)

Any Windows based PC can be used as client. The minimum client configuration requires:

− Pentium 4 CPU

− 1 GB RAM

− 80GB HDD

− 100BaseT

− CD/DVD Drive

− Windows XP, with the next Release also Windows Vista

3.3 System Performance

3.3.1 "Peak Busy Hour" Handling Capabilities (6.3.1 )

In general the probes are designed to handle full link speed, nevertheless not the entire traffic can be

stored and processed. There are the following limitations:

::: Full link speed can be received and HW filters can be activated to, for example, delete user plane

traffic.

::: Probe server for E1/T1 interfaces can handle 1 erlang per signaling links.

::: Probe server for STM-1/ATM can handle 200 Mbps in total as a sum of up and downlink.

::: Probe server for 100/1000 Base-T can handle 200 Mbps in total as a sum of up and downlink.

3.3.2 System Bottlenecks & Limitations (6.3.3/7)

The overall system performance depends on the central server used. There is a linkage between

number of CPU and numbers of CDR it can handle. The proposed system can handle up to 70 Mio

CDR per day.


3.3.3 Data Granularity (6.3.8)

Figure 12 illustrates the different types of user transactions with the NexusNETVIEW system:

::: CDR Data (E2E Full Session Analyzer)

NexusNETVIEW constantly collects and aggregates CDR as the calls, SMS, Location Updates or

UMTS/GPRS Data Sessions happen. Users can set-up any search for CDR and will get response

within a very short time3.

::: KPI Data

KPI are collected in 5 Minutes intervals and uploaded to the central server. When user access

KPI information a query to the KPI database is made. It aggregates information according to the

user's definition, not shorter than 5 Minutes.

::: Raw Data (Protocol Trace Application)

Probes of NexusNETVIEW constantly collect signaling and user plane information, analyses it

and stores the raw data on the hard disk. When users make a drill-down to the protocol data, a

well defined number4 of messages are transmitted to the clients workstation.

These user transactions are fully independent of each other. Multiple users can run the same

applications in parallel.

3 15 Seconds in a database with more than 1.5 Billion of CDR using "Simple Search" 4 Defined by the time window, i.e start of call to end of call.


Figure 12: NexusNETVIEW Architecture

3.4 Probe Performance Requirements

3.4.1 Throughput Capacity (6.4.14/6.4.17)

As listed above (chapter 3.3.1) probes can handle full link speed but not the entire traffic can be stored

and processed. There are the following limitations:

::: Full link speed can be received and HW filters can be activated to, for example, delete user plane

traffic.

::: Probe server for E1/T1 interfaces can handle 1 erlang per signaling links.

::: Probe server for STM-1/ATM can handle 200 Mbps in total as a sum of up and downlink

::: Probe server for 100/1000 Base-T can handle 200 Mbps in total as a sum of up and downlink.


3.4.2 Probe Extensions (6.4.16)

To increase throughput traffic can be splitted and fed to other probe servers.

3.5 System Administration

Every user of NexusNETVIEW has its own user name and password. Access rights are linked to user

groups (see Figure 13) and, therefore, every user has to be member of one user group.

Figure 13: Application Administration

3.5.1 User Administration (6.5.13)

As described above the administrator can generate an unlimited number of users groups. This would

allow to have for every user its own user group. The "User Administration" GUI (see Figure 13) allows

adding or deleting of users and allocating them to user groups.

By default there are at three different permission levels:


::: Administrator Group, whose member can configure the system and give access right to the other

user groups.

::: Configuration Group, which can configure applications.

::: User Group, which can access data on the centrals server's HDD and can drill-down to protocol

level.

3.6 Application Requirements

There are the following applications available on NexusNETVIEW:

::: End-to-End Full Session Trace (FSA)

The End-to-End Full Session Analyzer (FSA) is one of the strongest features of NexusNETVIEW,

because it uses a unique approach. Probes constantly generate so-called CLR (Communication

Leg Records) from the information read on the links. The central server aggregates these CLR to

CDR and stores these in the database.

CDR are stored in the database for at least 30 days. Users, having the proper access rights, can

find any call, which has happened in the network within seconds by a very strong search feature

(see Figure 14). The users can trace calls network-wide and on-line, without knowing where a call

has started.

Figure 14: Call Trace GUI, Search and Result Window

The user can view call details (CLR) either in a tabular form or in the form of a flow chart diagram,

as shown in Figure 15. For drill-down purposes it is possible to view message details in the PAT

application by just one mouse click on the message "arrow" in the message flow chart.


Figure 15: Message Flow Chart

::: Network Performance (NPE)

The NexusNETVIEW Network Performance Management according to ITU Q.752

recommendation is one of the basic applications of the Signaling Surveillance System used for

performance measurements on any SS7 link in the network. It allows total network visibility

through on-line and off-line network performance monitoring for detailed analysis and statistical

evaluation of signaling information.

The NPE application supports a wide range of protocols:

− ISUP

− SCCP

− TC/MAP/INAP

− TUP

− DSS1

In the future SIP, SIP-T and other VoIP protocols will be supported as well.


Figure 16: Network Performance Measurements

::: International Roaming Monitoring (IRM2)

The IRM2 (International Roaming Monitoring 2) application is a new application, which focuses

on GT (Global Titles). The strength of the IRM2 application is to not only collect normal and

complete but also incomplete MAP transactions.


Figure 17: International Roaming Monitor

::: GPRS Performance Management (GPE)

The NexusNETVIEW GPRS Performance Management is one of the basic applications of the

Surveillance System providing KPI for the Gb, Gn, Gp and Gi interfaces in the GPRS network. It

allows total network visibility through on-line and off-line network performance monitoring for

detailed analysis and statistical evaluation of signaling information.


Figure 18: GPRS Performance GUI

::: Service Performance Analyzer (NexusSPA)

Service Performance Analyzer (NexusSPA, is not part of the offer) provides performance

information for different services, i.e. WAP, MMS, HTTP, E-Mail, FTP, etc. Reports can be

scheduled or on-demand reports and can be viewed with a Web browser. This application can be

used as stand-alone as well.


Figure 19: SPA Report – WAP Hits

::: Protocol Analyzer Tracer (PAT)

NexusNETVIEW provides an industry leading protocol analyzer tracer (PAT) application for a

powerful and fast network-wide tracing of any link monitored by the NexusNETVIEW system. PAT

is designed for simultaneous and accurate monitoring of all critical VoIP, UMTS, GPRS, GSM and

SS#7 interfaces. It facilitates fast fault detection and analysis of network performance with real-

time statistics, and call or session trace.


Figure 20: Protocol Trace

The PAT application is the final drill-down step in fault analysis within the NexusNETVIEW

Signaling Surveillance System. It allows precise access to relevant signaling data out of other

surveillance applications of the NexusNETVIEW system within seconds (e.g. E2E Full Session

Analyzer (FSA), see Figure 21).


Figure 21: Drill-down from Call Trace to Protocol A nalysis

::: Event Counter Application (ECA)

The NexusNETVIEW event counter allows counting of certain protocol element on a link-set over

a defined timeframe with user definable intervals. Powerful graphical tools allow visualization of

the events.


Figure 22: Event Counter application

::: Alarms

For every measurement the user can set threshold levels as global values or individual values per

individual measured item, e.g. operator, link, direction, etc.

The alarms are viewed by the Alarm Management window (see Figure 23). It provides an alarm

summary, shows the alarms in a tabular form and details for every alarm. Every alarm has e

detailed description of the event, including date/time and network element or link as well as text

added by the user.


Figure 23: Alarm Monitor

::: Configuration Management

User with the proper access rights can add, modify or delete the configuration of the system. The

configuration follows a hierarchical system:

− Equipment configuration, at the physical level: Configuration of the probe servers and the

interfaces.

− Probe site configuration makes the mapping of the physical interface to the network

description.

− Network configuration is the highest configuration level. In contains the view of the entire

network, i.e. the names of the network elements and the links between. Furthermore it

contains the geographical locations of network elements and the different maps (see Figure

24).


Figure 24: Network Configuration – Map

The configuration information can be exported and imported via an XML-based interface.

3.6.1 Reports and KPI (6.6.3.2)

Reports and KPI are provided by NexusSCENE mainly. As described above NexusSCENE is an

adjunct process to NexusNETVIEW, often running on an independent report server. Figure 25 shows

the interworking of NexusNETVIEW and NexusSCENE. NexusSCENE receives the data via XML

based data streams. This data is processed and aggregated into KPI/KQI before being stored in the

database. These KPI/KQI are now available for reports using parameters provided by the user. These

reports can be either scheduled or generated immediately. NexusSCENE reports can be generated as

PDF files or exported as CSV files.


Figure 25: NexusNETVIEW and NexusSCENE Overview

For NexusSCENE a bundle of reports are available already. These are for example:

::: Circuit Switched Interconnect (CSI) reports:

The statistics reported by the NexusSCENE CSI reports contain all the data required to analyze

service performance of calls passing through a network, hence the level of SLA compliance.

These are the following:

− Number of calls (NC),

− Number of seizures (NS),

− Number of answered seizures (NAS),

− Number of missed calls (NM),

− Answer Seizure Ratio (ASR),

− Network Efficiency Ratio (NER),

− Average Length of Call (ALOC),

− Post Gateway Access Delay (PGAD).

− Number of records with empty A number (CLI)

These measurements are available per


− OPC, (O)NI

− DPC, (D)NI

− Destination or Called customer (B number),

::: Signaling Carrier Accounting (SCA):

The statistics reported by the NexusSCENE Signaling Carrier Accounting Reports contain all the

data required to account for signaling passing through a network, hence the level of SCA

compliance – most prominently: amount of MSUs and their Octets Transmitted and received per

protocol, amount of MTP messages, amount of SCCP, ISUP and other Service Indicator

messages, and a Global Title (GT) distribution of SCCP messages. (Standards Q.752, Tables 6,

15 and 16).

::: Roaming Subscribers Win/Loss Statistics:

These reports provide the following roaming-related statistics:

− Total Roaming Subscribers in the Network

− Roaming Subscribers per Cell

− Highest Roaming Traffic Carrying Cells

− Red Carpet Cells, Cells Hosting most Roaming Subscribers

− Cells Winning Roaming Subscribers

− Cells Loosing Roaming Subscribers

…and many more.

3.6.2 Measurements for SS7 and SIGTRAN (6.6.3.3)

The Network Performance (NPE) Application of NexusNETVIEW provides canned reports or basic

measurements, which don’t use the CDR/TDR/EDR Applications (FSA). These measurements follow

Q.752 and are for example:

::: MTP Measurements:

− MSU_CNT: Number of message signal units, TX/RX implied by OPC/DPC order

− SIF_OCT_CNT: SIF octet count, TX/RX direction implied by the OPC/DPC order

− SIO_OCT_CNT: SIO octet count, TX/RX direction implied by the OPC/DPC order

− SL_FAILURE: SL failure - all reasons

− SL_FAIL_CNT: Number of signal units received in error

− SL_IN_SERVICE: Duration of link in the in-service state


− SL_OUT_OF_SERVICE: Duration of SL unavailability (any reason)

− SL_RESTORATION: SL restoration

::: ISUP Measurements:

− ISUP_MSU_CNT: Total number of ISUP messages transported, TX/RX implied by OPC/DPC

order

− ISUP_ANM_CNT: Total number of ISUP ANM messages transported, TX/RX implied by

OPC/DPC order

− ISUP_CON_CNT: Total number of ISUP CON messages transported, TX/RX implied by

OPC/DPC order

− ISUP_IAM_CNT: Total number of ISUP IAM messages transported, TX/RX implied by

OPC/DPC order

::: BICC Measurements:

− BICC_MSU_CNT: Total number of BICC messages transported, TX/RX implied by OPC/DPC

order

− BICC_ANM_CNT: Total number of BICC ANM messages transported, TX/RX implied by

OPC/DPC order

− BICC_CON_CNT: Total number of BICC CON messages transported, TX/RX implied by

OPC/DPC order

− BICC_IAM_CNT: Total number of BICC IAM messages transported, TX/RX implied by

OPC/DPC order

::: SCCP Measurements:

− SCCP_HOP_CNT_ VIOLATION: Hop Counter Violation

− SCCP_MSU_CNT: Total number of SCCP messages transported, TX/RX implied by

OPC/DPC order

− SCCP_PROV_REL_ CONN: Provider initiated release of a connection

− SCCP_PROV_ RESET_CONN: Provider initiated reset of a connection

− SCCP_REASSM_ ERR_FAIL: Reassembly Error - Reassembly Failed

− SCCP_REASSM_ ERR_NO_SPC: Reassembly Error - No reassembly space

− SCCP_REASSM_ ERR_SEG_OSQ: Reassembly Error - Segment Received out of sequence

− SCCP_REASSM_ ERR_TIM_EXP: Reassembly Error - Timer expiry

− SCCP_ROUT_ FAIL_NET_CONG: Routing Failure - Network congestion

− SCCP_ROUT_ FAIL_NTFAOSN: Routing Failure - No translation for address of such nature

− SCCP_ROUT_ FAIL_NTFTSA: Routing Failure - No translation for this specific address

− SCCP_ROUT_ FAIL_SS_CONG: Routing Failure - Subsystem congestion

− SCCP_ROUT_ FAIL_SS_FAIL: Routing Failure - Subsystem failure


− SCCP_ROUT_ FAIL_UNEQ_USR: Routing Failure - Unequipped user

− SCCP_ROUT_ FAIL_UNQUAL: Routing Failure - Reason unknown

− SCCP_SEG_ERR_ FAIL: Segmentation Error - Segmentation failed

− SCCP_SEG_ERR_ NOT_SUPP: Segmentation Error - Segmenting not supported

− SCCP_UDTS_CNT: Total number of UDTS messages transported, TX/RX implied by

OPC/DPC order

::: TCAP Measurements:

− TC_COMP_ERR_ BADSTR_COMP: Protocol error in component portion - badly structured

component

− TC_COMP_ERR_ MISTYP_COMP: Protocol error in component portion - mistyped

component

− TC_COMP_ERR_ UNREC_COMP: Protocol error in component portion - unrecognized

component

− TC_MSU_CNT: Total number of TC messages transported, TX/RX implied by OPC/DPC

order

− TC_P_ABORT_ BADFOR_TP: Protocol error in transaction portion - badly formatted TP

− TC_P_ABORT_ INCOR_TP: Protocol error in transaction portion - incorrect TP

− TC_P_ABORT_ UNREC_TID: Protocol error in transaction portion - unrecognized TID

− TC_P_ABORT_ UNREC_TYPE: Protocol error in transaction part - unrecognized message

type

3.6.3 Report Samples (6.6.3.4)

As explained above (see chapter 3.6.1) most of the reports are provided by NexusSCENE. There is,

as an example for other types of reports, the Circuit Switched Interconnect (CSI) Reports, which uses

the voice call CDR to generate:

::: Configuration parameters: − Carrier (Destination/Origination)

− Destination (B number)

− Class of service (defined by PC/CIC)

::: Measurements: − Number of calls (NC)

− Number of seizures (NS)

− Number of answered seizures (NAS)

− Number of missed calls (NM)

− Answer Seizure Ratio (ASR)


− Network Efficiency Ratio (NER)

− Average Length of Call (ALOC)

− Post Gateway Access Delay (PGAD)


::: Reports:

− Carrier report: Measurements aggregated and sorted by carrier and by class of

service.

− Destination report: Measurements for selected destination country (or group of

countries) aggregated and sorted by carrier and class of

service.

− I/O report: Measurements for calls from origination to destination (set of)

carriers and for a particular destination country (or group of

countries).

− Detailed report: Measurements per each OPC-DPC pair. The level of

aggregation can be selected.


Figure 26: CSI Report

3.6.4 Aggregation Level (6.6.3.4.9)

NexusNETVIEW present the measurements by using a tree structure (see Figure 27) by which

measurements can be aggregated, i.e. from Cell to PCU to SGSN. Other measurement applications

provide aggregation from link to link set to operator to country.


Figure 27: Tree Structure for UMTS/GPRS Measurement s

3.6.5 Statistical Alarms (6.6.3.4.10)

For every alarm the user5 can set up to 4 severity levels. The alarm documentation will be part of the

"User Manual" which comes with NexusNETVIEW. Figure 28 illustrates how the different threshold

levels are alarmed.

Figure 28: Threshold Levels

5 He/she has to have the access right to do so!


3.6.6 Scheduled Reports (6.6.3.4.14)

Reports normally are scheduled by the users, even it is possible to create reports on-demand. Figure

29 shows the GUI, yb which a user can define and schedule a report.

Figure 29: Report Definition and Scheduling

3.6.7 Service Related Reports (6.6.3.4.22)

Since exported CDR contain also call leg information it is possible to implement reports on

NexusSCENE, which provide service related information as for example:

::: INAP/ISUP for statistics concerning number portability.

::: SIP and MGCP for reports like requested/received resources vs. call duration.


3.6.8 Call Trace Filters (6.6.5.1.13)

There are two type of filters or search criteria for calls, SMS, Location updates or data sessions:

::: Simple search for quick search

::: Advanced search for any logically combined filter criteria of AND and OR.

The following filters can be set:

::: Simple Search for Calls, SMS and Location Updat es:

One of the following, together with time frame and successful/not successful indication:

− Called B Number

− Calling A Number

− Original C Number

− Redirecting D Number

− Duration

− Elapsed

− Hop Counter

− Bearer

− CSC

− NIP

− Forward Call Ind

− Backward Call Ind

− A-IMSI

− A-TMSI

− B-IMSI

− B-TMSI

::: Advanced Search for Calls, SMS and Location Upd ates:

Any combinations of the following:

− Called (B) Number

− Calling (A) Number

− Original (C) Number

− Redirecting (D) Number

− Setup Time

− Last Activity


− Answer Time

− Connect Time

− Disconnect Time

− Clear Time

− Clearing

− Duration

− Elapsed

− Hop Counter

− Bearer

− CSC

− NIP

− Forward Call Ind

− Backward Call Ind

− A-IMSI

− A-TMSI

− B-IMSI

− B-TMSI

− OPC

− DPC

− CIC

− Physical Element

− A Global Title clr

− B Global Title clr

− CLR Causes

− IMSI

− MSISDN

− MSRN

− Service Key

− Calling Party Cat.

− Trans. Medium Requirement

− Session Description

− Type of call legs

::: Simple Search for Data Sessions:

One of the following, together with time frame and successful/not successful indication:

− IMSI


− MSISDN

− User IP Address

− SGSN IP (Control Plane)

− SGSN IP (User Plane)

− GGSN IP (Control Plane)

− GGSN IP (User Plane)

− P-TMSI

::: Advanced Search for Data Sessions:

Any combinations of the following:

− IMSI

− MSISDN

− User IP Address

− SGSN IP (Control Plane)

− SGSN IP (User Plane)

− GGSN IP (Control Plane)

− GGSN IP (User Plane)

− P-TMSI

− Attach Time

− Activation Time

− RAU Time

− Transfer Time

− Deactivation Time

− Detach Time

− First Activity Time

− Last Activity Time

− Radius Server IP

− DHCP Server IP

− IMEI

− APN

− A Global Title glr

− B Global Title glr

− Cause Value

− Type of session leg


3.6.9 GPRS Reports (6.6.5.4.5/6)

The GPRS Performance Management (GPE) application of NexusNETVIEW provides, amongst

others, the following canned reports or basic measurements, which don’t use the CDR/TDR/EDR

Applications (FSA):

::: Measurements on the Gb interfaces:

− Used capacity

− Discarded Frame Relay Frames

− Attach Requests

− Attach attempts

− No of unsuccessful Attach attempts (Histogram)

− Attach Duration (Histogram, and values for Min, Max, Average)

− Detach operations

− Routing Area Update attempts

− RAU attempts duration

− Identity Requests

− Authentication and Ciphering Attempts

− Radio Status Messages

− PDP Context Activation Attempts

− PDP Context Deactivation

− Sessions Terminated on Abnormal Conditions

− Session Activation Duration (Histogram, and Min. Max, Average Values)

− Active Sessions

− Number of Bytes

− GMM Packets

− SM Packets

::: Measurements on the IuPS interfaces:

− Attach Requests

− Attach attempts

− Number of unsuccessful Attach attempts

− Authentication and Ciphering attempts


− Identity Request messages


− Attach Duration


− PDP Context Activation attempts

− PDP Context Deactivation attempts

− Number of sessions terminated on abnormal conditions

− Session Activation Duration

::: Measurements on the Gn/Gp interfaces:

− Create PDP Context Attempts

− PDP Context Deactivation

− Active Sessions

− UDP DNS queries

− UDP DNS resolution duration

::: Measurements on the Gi interfaces

− RADIUS Access Operations

− RADIUS Accounting Operation Attempts

− DHCP Lease Operations

− DHCP Release Messages

3.6.10 Service-related Reports (6.6.5.4.6/11)

The Service Performance Analyzer (NexusSPA , is not part of the offer) monitors either the Gn/Gp

interface or the Gi interface. While NexusNETVIEW monitors the tunnel establishment, analyzes the

NexusSPA the user plane only (see Figure 30).

Figure 30: Service Performance Analyzer (SPA)


The following measurements, amongst others, are available:

::: MMS Reports , per network, per direction (MO or MT) and per VIP groups:

− MMS Success Rate

− MMS Delay, Mean

− MMS Delay Distribution

− MMS Upload Throughput Distribution

− MMS Retries

− MMS MMSC Delay Mean

− MMS Notification Success

− MMS Message Size, Mean

− MMS Message Size Distribution

− MMS Attachment Distribution

::: WAP Reports , per network, per direction, per Top-10, per URL and per VIP groups:

− WAP Volume

− WAP Success Rate

− WAP Throughput

− WAP Access Time, Mean

− WAP URL Failures

− WAP RTT, mean

::: HTTP Reports , per network, per direction, per Top-10 and per VIP groups:

− HTTP Volume

− HTTP Success Rate

− HTTP Throughput

− HTTP Access Time, Mean

− HTTP URL Failures

− HTTP RTT, mean

::: FTP Reports , per network, per direction, per Top-10 and per VIP groups:

− FTP Volume

− FTP Throughput

− FTP Error Rate

− FTP File Size, Mean

− FTP File Size Distribution

::: IP and TCP/IP reports , per direction:


− Active IP Sessions

− IP Packets

− IP Packet Rate

− IP Session Duration, Mean

− IP TCP Session Requests

− IP TCP Packet Retransmission

− IP TCP Round Trip Time, Mean

− IP Volume

− IP Throughput

3.6.11 On-demand Performance Reports (6.6.5.46)

The NexusNETVIEW event counter (ECA) allows counting of certain protocol element on a link-set

over a defined timeframe with user definable intervals. Powerful graphical tools allow visualization of

the events.

Figure 31: ECA


This application is an add-on to the PAT and, therefore, supports, the same protocols as described in

chapter 3.10.1. In a very flexible way the user can create on-demand reports counting messages, info

element or any message content.

Example:

::: The user can create counter criteria by defining Counter Name, Protocol Stack and a filter criteria

as for example Message type and/or Info Element.

Figure 32: Counter definition

::: In this example did the user define three counters: CONNECT_ACK, CONNECT, ALERTING. He

can view the result as a summary in a tabular form:

Figure 33: Result in Tabular View

::: …as a pie diagram:


Figure 34: Result as Pie Chart

::: …or he can view it as a timeline diagram

Figure 35: Result as Timeline Diagram

::: These reports can be printed.


3.6.12 International Roaming Monitoring (6.6.5.6)

The International Roaming Monitoring (IRM2) application of NexusNETVIEW provides, amongst

others, the canned reports or basic measurements, which don’t use the CDR/TDR/EDR Applications

(FSA).

The IRM2 application monitors the following MAP transaction scenarios:

::: Update Location (UPL)

::: Cancel Location (CAL)

::: Provide Roaming Number (PRN)

::: Send Parameters (SPA)

::: Send Authentication Info (SAI)

::: Update GPRS Location (UPGL)

::: Send Routing Info for SM (SRIS)

::: SMS Mobile Terminating (MTFS)

::: SMS Mobile Originating (MOFS)

It provides statistics about:

::: Number of complete MAP transactions:

− successful

− not successful, per error code

::: Number of incomplete transactions, i.e.

− TCAP aborts

− Transaction failed on SCCP layer (UDTS ended)

− Update Locations with "Roaming Restrictions" in Insert Subscriber Data

− Incomplete transactions – unanswered requests

− Special scenarios where a procedures is ended with a "normal" message, but subsequently

invalidated by a "bad" message, as for example a UDTS

3.7 Filter Functionality

The filter functionality for FSA is described in detail in chapter 3.6.8. The user can chose between two

type of filters or search criteria for calls, SMS, Location updates or data sessions (see Figure 36):

::: Simple search for quick search

::: Advanced search for any logically combined filter criteria of AND and OR.


Figure 36: Different Types of Filters

3.8 Call Trace Functionality

3.8.1 Performance of Call Trace (6.8.3)

Figure 37 demonstrates how a user traces a call and drills-down to the protocol details:

::: Starte the call trace using the FSA (Full Service Analyzer) application (the top window): The

system searches for all calls, SMS, Location Updates or Data Session matching the criteria given

by the user. I.e in case of "Simple Search6" the user gets all calls within 15 seconds

::: Select one single call (in the top window) and switch to "Physical View", which presents the

message flow (window in the middle). This takes less than one second.

::: Select one arrow and open with right mouse click the protocol analyzer. The PAT application

collects the raw data information from the probes and displays them in the PAT window (the

bottom window). This takes 10 to 30 seconds.

6 "Advanced Search" allows complex searches, which might take more time than "Simple Search"

(see chapter 3.6.8)


Figure 37: Drill-down from Call Trace to Protocol D etails

3.9 Protocol Analysis

3.9.1 PAT Performance (6.9.1/2)

See chapter 3.8.1, which describes the drill-down from the call trace to the protocol details

3.10 Supported Protocols and Interfaces

3.10.1 Signaling Protocols (6.10.1/2)

The PAT application of NexusNETVIEW supports the following protocols (see offer, which protocols

are licensed):


3.10.1.1 PSTN Protocols

::: ISDN/V5 Decodes:

Protocol name Specification

EDSS1 EN 300403-1

ISDN Q.931

ISDN SS Q.733

QSIG – Basic Calls ECMA-143

V5.1 ETS 300 324-1

V5.2 ETS 300 347-1

::: SS#7 Decodes:


INAP Q.1218 (CS1+, CS1, CS2)

TCAP Q.773

SCCP Q.713

ISUP Q.763 & different national variants

MTP Q.703, Q.704 (different editions)

TUP Q.723 & different national variants

3.10.1.2 GSM/UMTS Circuit Switched Protocols

::: A/IuCS Decodes:


SCCP Q.713


MTP-3B Q.2210

BSSAP TS 08.06

BSSMAP TS 08.08

LDAP RFC 1777

DTAP TS 04.08

RANAP TS 25.413

ALCAP Q.2630.1

::: Abis/Iub/Iur Decodes:



NBAP TS 25.433

RNSAP TS 25.423

RRC TS 25.331

LDAP RFC 1777

SCCP Q.713


Abis Alcatel div. proprietary spec.

Abis Ericsson div. proprietary spec.

Abis Nokia div. proprietary spec.

Abis Lucent div. proprietary spec.

Abis Siemens div. proprietary spec.

Abis Nortel div. proprietary spec.

Abis Huawei div. proprietary spec.

Abis Motorola div. proprietary spec.

::: Core Network Decodes:


MAP TS 29.002 (versions 1, 2, 3 & 4)

CAP/CAMEL TS 23.078 (CAP2, CAP3, CAP4)

TCAP Q.773

SCCP Q.713

ISUP Q.763 & different national variants


BICC

3.10.1.3 GPRS/UMTS Packet Switched Protocols

::: Gb Interface Control Plane Decodes:

Protocol name Standard

GMM/SM 3GPP TS 24.008

LLC ETSI TS 101 351

BSSGP ETSI TS 101 343

NS ETSI TS 101 299


Frame Relay --

::: IuPS Interface Control Plane Decodes:


MM/SM TS 124 008; 3GPP TS 24.008

GMM 3GPP TS 24.008

RANAP 3GPP TS 25.413

SCCP ITU-T Q.713

MTP3-B IUT-T Q.2210

SSCF-NNI RFC 3286

SSCOP Q.2110

AAL5 RFC 1483

::: Gn/Gp Interface Control Plane Decodes:


GTP-C TS 29.060

UDP RFC 768

TCP RFC 793

IP V4 RFC 791

IP V6 RFC 2460

::: Gr Interface Decodes SS7 and SIGTRAN:


MAP div.

TCAP div.

SCCP div.

ISUP div.

TUP div.

MTP div.

SCTP RFC 3286, 2960

M2UA RFC 3331

M3UA RFC 4666

M2PA RFC 4165


::: User Plane Decodes for Gi, Gn/Gp, Gb or IuPS:


DNS RFC 1035, RFC 2136

RADIUS RFC 2865...2869

HTTP RFC 2616

FTP RFC 959

SMTP RFC 2821

IMAP RFC 2060

POP RFC 1939

SMPP SMS Forum

RTP RFC 1889

WAP WTP WAP-201-WTP

WAP WSP / MMS Support WAP-203-WSP/WAP-230-WSP

WAP WAE WAP-192-WBXML

WAP WTLS WAP-199-WTLS

UDP RFC 768

TCP RFC 793

IP RFC 791

3.10.1.4 VoIP/NGN Protocols

::: VoIP Interface Decodes:


MEGACO H.248

H.323 H.225 (Call Signaling), H.245 (System Control)

MGCP RFC 3435

SIP RFC 3261

SIP-T RFC 3372

SIP-I Q.1912.5

RTP RFC 1889, 3611

RTCP RFC 1889

SCTP RFC 3286, 2960


SDP RFC 2327

UDP RFC 768

::: SIGTRAN Layer Decode (Mc, Nc, Nb):


BICC Q.1901 (CS1) Q.1902 (CS2)

MAP TS 29.002

CAP/CAMEL TS 23.078 (CAP2, CAP3, CAP4)

TCAP Q.773

SCCP Q.713

ISUP Q.763

MTP3 Q.703

M3UA RFC 4666

M2PA RFC 4165

M2UA RFC 3331

SCTP RFC 3286, 2960

UDP RFC 768

3.10.2 Gb Deciphering (6.10.7)

NexusNETVIEW deciphers Gb interfaces by using keys read from the Gr interface. The keys are

stored centrally and, therefore, data streams can be deciphered even subscribers "move" from one

probe to another one. Performance limitations are given by the traffic, which has to be deciphered.

The traffic defines the number of probe servers.

3.11 CDR - TDR Generation (Call Data Records)

3.11.1 Data Base (6.11.1.7)

Due to very high performance requirements a proprietary database is used for CDR. This allows

highest number of inserts per seconds and in parallel very fast search of CDR by all the concurrent


users7. Performance of this proprietary database is approx. 3 times better than commercially available

database.

For 3rd party tools, which would like to use these CDR, NexusNETVIEW offers an export interface (see

chapter 3.11.2.

3.11.2 Export Interface (6.11.1.8)

The XML Export Interface provides data via data streams as they are generated by the

NexusNETVIEW8. Each data stream is a TCP/IP connection between the NexusNETVIEW server and

the "Data Consumer". The following data streams are available:

::: Voice call CDR

::: GPRS session CDR

::: SMS CDR

::: Location Update CDR

::: GPRS Performance data, generated by the application GPE

::: Network performance data, generated by the application NPE

More details see chapter 3.2.4).

3.11.3 NexusSCENE Reports using CDR (6.11.1.12/13)

CDR-based reports are provided by NexusSCENE. A bundle of reports are available already,

additional can be added easily. For example the following reports exist:

::: Circuit Switched Interconnect (CSI) reports:

The statistics reported by the NexusSCENE CSI reports contain all the data required to analyze

service performance of calls passing through a network, hence the level of SLA compliance.

These are the following:

− Number of calls (NC),

− Number of seizures (NS),

− Number of answered seizures (NAS),

− Number of missed calls (NM),

− Answer Seizure Ratio (ASR), 7 Largest system has more than 120 concurrent users 8 CDR are generated in real time; Measurements are generated in 5 minutes intervals.


− Network Efficiency Ratio (NER),

− Average Length of Call (ALOC),

− Post Gateway Access Delay (PGAD).


These measurements are available per

− OPC, (O)NI

− DPC, (D)NI

− Destination or Called customer (B number),

::: Signaling Carrier Accounting (SCA):

The statistics reported by the NexusSCENE Signaling Carrier Accounting Reports contain all the

data required to account for signaling passing through a network, hence the level of SCA

compliance – most prominently: amount of MSUs and their Octets Transmitted and received per

protocol, amount of MTP messages, amount of SCCP, ISUP and other Service Indicator

messages, and a Global Title (GT) distribution of SCCP messages. (Standards Q.752, Tables 6,

15 and 16).

::: Roaming Subscribers Win/Loss Statistics:

These reports provide the following roaming-related statistics:







::: Traffic Report:

This report delivers load information on interconnects:

− Relative to available bandwidth

− Relative to available bandwidth, but taking the Erlang B table into consideration

::: VIP Reports

These reports provides the following information per IMSI or group of IMSIs:

− Number of incoming/outgoing calls

− Number of incoming/outgoing SMS

− Number of Location Updates

− Number of GPRS attach procedures


− Number of PDP Context activations

− Number of up/downloaded bytes

…and many more.

The user can parameterize the generation of these reports, i.e. define which measurements shall be

part of the report. In one of the next releases of NexusSCENE it is possible to set threshold levels by

which alarms can be generated.

3.12 A and Iu Interface Quality and Performance Mon itoring

NexusNETVIEW is capable to monitor A and Iu interfaces. Besides of using information from these

interfaces to create CDR the system provides also measurements.

3.12.1 A and IuCS Interface Measurements

The following measurements are available now for the A interface and with next release for IuCS at

cell, SAI, BSC, RNC and MSC level:

::: MM-related Data

− CM SERVICE REQUEST:

Number of CM SERVICE REQUEST per Service Type

− CM SERVICE ACCEPT:

Number of CM SERVICE ACCEPT messages

− CM SERVICE REJECT:

Number of CM SERVICE REJECT messages

− CM SERVICE REJECT Ratio :

Ratio of CM SERVICE REJECT

::: Handover/Relocation-related Data

− HANDOVER / RELOCATION REQUIRED :

Number of HANDOVER or RELOCATION REQUIRED messages per Cause Value

− HANDOVER / RELOCATION PREPARATION FAILURE :

Number of HANDOVER or RELOCATION PREPARATION FAILURE messages per Cause

Value

− HANDOVER / RELOCATION COMMAND :

Number of HANDOVER or RELOCATION COMMAND messages

− HANDOVER / RELOCATION COMPLETE :

Number of HANDOVER or RELOCATION COMPLETE messages


− PING_PONG:

Number of calls that leave a cell with an outgoing Handover and come back to the same cell

within user definable time (i.e. 12 seconds) via incoming Handover

− HANDOVER / RELOCATION REQUEST :

Number of HANDOVER or RELOCATION REQUEST messages

− HANDOVER / RELOCATION REQUEST ACK

Number of HANDOVER or RELOCATION REQUEST messages

− HANDOVER / RELOCATION REQUEST ACK Ratio :

Ratio of HANDOVER or RELOCATION REQUEST messages

::: Call-related Measurements A and IuCS

− SETUP:

Number of SETUP messages

− ALERTING :

Number of ALERTING messages

− CONNECT

Number of CONNECT messages

− ANSWER:

Number of ANSWER messages

− CONNECT ACK

Number of CONNECT ACKNOWLEDGE messages

− DISCONNECT CAUSE:

Number of DISCONNECT messages per cause

− RELEASE CAUSE :

Number of RELAESE messages per cause

− CALL CLEARING CAUSE Ratio :

Ratio of RELEASE and DISCONNECT causes

::: Location Update-related Data

− LOC_UP REQUEST:

Number of LOCATION UPDATING REQUEST messages per type

− LOC_UP ACCEPTED :

Number of LOCATION UPDATING ACCEPTED messages

− LOC_UP REJECT, Cause :

Number of LOCATION UPDATING REJECT messages per cause value

− LOC_UP REJECT Ratio :

Number of LOCATION UPDATING REJECT messages per cause value


3.12.2 IuPS Interface Measurements

The following measurements are available now for the IuPS interface at SAI, RNC and MSC level:

− Attach Requests

− Attach attempts

− Number of unsuccessful Attach attempts

− Authentication and Ciphering attempts


− Identity Request messages


− Attach Duration

− PDP Context Activation attempts

− PDP Context Deactivation attempts

− Number of sessions terminated on abnormal condition s

− Session Activation Duration

3.13 VoIP and SIP Tracing and Related Statistics An alysis

As described above NexusNETVIEW supports a large amount of VoIP protocols (see 3.10.1.4). Today

it creates CDR for SIGTRAN call legs and SIP-based calls. With the next release it will support

MEGACO/H.248 call les and following release will support H.323.

Together with H.323 MOS value information will be added to SIP and H.323 CDR.

3.14 Traffic Management

NexusNETVIEW constantly monitors the network by collecting CDR and KPI and creates an alarm,

when one of the monitored parameters violates a threshold. The user can set for any measurement up

to 4 threshold values (see chapter 3.6.5). These are:


::: Critical

::: Major

::: Minor

::: Warning

The alarms can be visualized in the Alarm GUI as shown in Figure 38.

Figure 38: Alarm Notification

The Alarm GUI shows the KPI that has reached a threshold level and the details for an alarm is

presented (see Figure 39).


Figure 39: Alarm Details

3.15 Alarm Handling

Chapter 3.14 describes how alarms can be set and how they can be visualized in the alarm GUI.

Alarms can be automatically forwarded as SNMP Traps to umbrella system.

3.15.1 Link-based Alarms (6.15.22)

NexusNETVIEW provides the following SS7 link-based alarms:

Alarm Name Alarm Type

SL_SERVICE_DUR SS7 Link Performance

SL_OSS_DUR SS7 Link Performance

SL_RESTORE_CNT SS7 Link Performance

SL_FAILURE_CNT SS7 Link Performance



SL_MSU_FAIL_CNT SS7 Link Performance

SL_OOS_RATE SS7 Link Performance

SL_FAILURE_RATE SS7 Link Performance

LINK_ERROR_RATE SS7 Link Performance

LINK_LOAD_CHANGE SS7 Link Performance

MTP_MSU_CNT SS7, MTP Layer Performance

MTP_SIO_CNT SS7, MTP Layer Performance

MTP_SIF_CNT SS7, MTP Layer Performance

MTP_ERLANG SS7, MTP Layer Performance

MTP_TRANS_PROHIB SS7, MTP Layer Performance

MTP_TRANS_RESTR SS7, MTP Layer Performance

MTP_TRANS_ALLOW SS7, MTP Layer Performance

MTP_TRANS_CTRL SS7, MTP Layer Performance

MTP_CHOVER_COO SS7, MTP Layer Performance

MTP_CHOVER_COA SS7, MTP Layer Performance

SCCP_MSU_CNT SS7, SCCP Layer Performance

SCCP_UDT_CNT SS7, SCCP Layer Performance

SCCP_UDTS_CNT SS7, SCCP Layer Performance

SCCP_UDTS_RCAUSE SS7, SCCP Layer Performance

SCCP_RTFAIL_NTFAOSN SS7, SCCP Layer Performance

SCCP_RTFAIL_NTFTSA SS7, SCCP Layer Performance

SCCP_RTFAIL_NET_CONG SS7, SCCP Layer Performance

SCCP_RTFAIL_SS_FAIL SS7, SCCP Layer Performance

SCCP_RTFAIL_SS_CONG SS7, SCCP Layer Performance

SCCP_RTFAIL_UNEQ_USR SS7, SCCP Layer Performance

SCCP_RTFAIL_UNQUAL SS7, SCCP Layer Performance

SCCP_REAERR_TIM_EXP SS7, SCCP Layer Performance

SCCP_REAERR_SEG_OSQ SS7, SCCP Layer Performance

SCCP_REAERR_NO_SPC SS7, SCCP Layer Performance

SCCP_REAERR_FAIL SS7, SCCP Layer Performance

SCCP_HOPCNT_VIOL SS7, SCCP Layer Performance

SCCP_PROV_RESET SS7, SCCP Layer Performance

SCCP_PROV_RELEASE SS7, SCCP Layer Performance

SCCP_SEGERR_NOT_SUPP SS7, SCCP Layer Performance



SCCP_SEGERR_FAIL SS7, SCCP Layer Performance

SCCP_UDTS_RCAUSE_RATE SS7, SCCP Layer Performance

SCCP_RTFAIL_RATE SS7, SCCP Layer Performance

SCCP_REAERR_RATE SS7, SCCP Layer Performance

SCCP_HOP_VIOL_RATE SS7, SCCP Layer Performance

SCCP_PROV_RESET_RATE SS7, SCCP Layer Performance

SCCP_SEGERR_RATE SS7, SCCP Layer Performance

TC_MSU_CNT SS7, TCAP Layer Performance

TC_COMPERR_UNREC SS7, TCAP Layer Performance

TC_COMPERR_MISTYPE SS7, TCAP Layer Performance

TC_COMPERR_BADSTR SS7, TCAP Layer Performance

TC_PABORT_UNREC_TYPE SS7, TCAP Layer Performance

TC_PABORT_INCORRECT SS7, TCAP Layer Performance

TC_PABORT_BADFORMAT SS7, TCAP Layer Performance

TC_PABORT_UNREC_TID SS7, TCAP Layer Performance

TC_COMPERR_RATE SS7, TCAP Layer Performance

TC_PABORT_RATE SS7, TCAP Layer Performance

ISUP_MSU_CNT SS7, ISUP Layer Performance

ISUP_IAM_CNT SS7, ISUP Layer Performance

ISUP_ANM_CNT SS7, ISUP Layer Performance

ISUP_CON_CNT SS7, ISUP Layer Performance

DSS1_MSU_CNT SS7, DSS1 Layer Performance

NexusNETVIEW can report the following GPRS link-based alarms


USED_CAPACITY GPRS Performance, Gb Interface

FRAME_NR GPRS Performance, Gb Interface

NS_USAGE_MESSAGES GPRS Performance, Gb Interface

NS_BLOCK_MESSAGES GPRS Performance, Gb Interface

NS_UNBLOCK_MESSAGES GPRS Performance, Gb Interface

ATTACH_REQUESTS GPRS Performance, Gb Interface


3.15.2 Service-related Alarms


MAP_SMSFORW SS7, SMS Performance

MSC_MOC_OUTAGE SS7, MSC Performance

MSC_MTC_OUTAGE SS7, MSC Performance

MSC_MOC_SER_DEGR SS7, MSC Performance

MSC_MTC_SER_DEGR SS7, MSC Performance

NODE_TRF_BAL SS7, Switch/STP Performance

NODE_MSG_BAL SS7, Switch/STP Performance

NODE_SCCP_RATE SS7, Switch/STP Performance

NODE_LOAD_RX_CHANGE SS7, Switch/STP Performance

NODE_LOAD_TX_CHANGE SS7, Switch/STP Performance

For roaming NexusNETVIEW reports the following alarms:


IRM_GT_ALARM International Roaming Performance

INAP_ERR_RATE International Roaming Performance

INAP_MSG_LOSS International Roaming Performance

SCCP_ERR_RATE International Roaming Performance

SCCP_NON_DELIVERY International Roaming Performance

MAP_ERR_RATE International Roaming Performance

MAP_MSG_LOSS International Roaming Performance

For data services NexusNETVIEW reports the following alarms:


SGSN_OUTAGE GPRS Performance, SGSN Balance

CELL_UPDATES_INCOMING_ DURING_REGISTRATION

GPRS Performance, Gb Interface

SHORT_STAY_OCCURRENCES GPRS Performance, Gb Interface

ACTIVE_SUBSCRIBERS GPRS Performance, Gb Interface

ATTACH_ATTEMPTS GPRS Performance, Gb Interface

UNSUCCESSFUL_ATTACH_ATTEMPTS




AUTHENTICATION_AND_CIPHERING_ ATTEMPTS


DETACH_OPERATIONS GPRS Performance, Gb Interface

IDENTITY_REQUESTS GPRS Performance, Gb Interface

ROUTING_AREA_UPDATE_ATTEMPTS


INTER_SGSN_ROUTING_AREA_ UPDATE_ATTEMPTS


RADIO_STATUS_MESSAGES GPRS Performance, Gb Interface

PDP_CONTEXT_ACTIVATION GPRS Performance, Gb Interface

PDP_CONTEXT_DEACTIVATION GPRS Performance, Gb Interface

TERMINATED_SESSIONS GPRS Performance, Gb Interface

ACTIVATED_SESSIONS GPRS Performance, Gb Interface

ATTACH_SUCC_RATE GPRS Performance, Gb Interface

AUTH_CIPH_SUCC_RATE GPRS Performance, Gb Interface

ID_REQ_SUCC_RATE GPRS Performance, Gb Interface

RAU_SUCC_RATE GPRS Performance, Gb Interface

PDP_CONT_ACT_SUCC_RATE GPRS Performance, Gb Interface

PDP_CONT_DEACT_SUCC_RATE GPRS Performance, Gb Interface

PDP_CONTEXT_ACTIVATION_ ATTEMPTS

GPRS Performance, Gn/Gp Interface

ACTIVE_PDP_CONTEXTS GPRS Performance, Gn/Gp Interface

RADIUS_ACCESS_OPERATION_ ATTEMPTS

GPRS Performance, Gi Interface

RADIUS_ACCOUNTING_ OPERATION_ATTEMPTS

GPRS Performance, Gi Interface

DHCP_LEASE_OPERATIONS GPRS Performance, Gi Interface

DHCP_RELEASE_MESSAGES GPRS Performance, Gi Interface

RADIUS_ACCESS_SUCC_RATE GPRS Performance, Gi Interface

RADIUS_ACCOUNT_SUCC_RATE GPRS Performance, Gi Interface

PDP_CONT_ACT_ATT_SUCC_RATE GPRS Performance, Gi Interface

3.15.3 System-internal alarms

NexusNETVIEW is capable to report the following system alarms:



PROBE_SIG_NOTAVAIL System Alarm

PROBE_SIG_CRC System Alarm

PROBE_FRAME_DROP System Alarm

PROBE_WRITE_ERROR System Alarm

NH_AGENT_DELAY System Alarm

CDR_AGENT_DELAY System Alarm

3.16 Roaming Management System

In respect to roaming NexusNETVIEW offers the following applications:

::: International Roaming Monitoring (IRM2)

This application provides statistical information for Inbound and Outbound Roamers in respect to

their interaction with the home network (HPLMN).

::: NexusSCENE, Roaming Reports

These reports provide the following roaming-related statistics (see 3.11.3):







::: NexusSCENE, VIP Reports

These reports provides the following information per IMSI or group of IMSIs (see 3.11.3):

− Number of incoming/outgoing calls

− Number of incoming/outgoing SMS

− Number of Location Updates

− Number of GPRS attach procedures

− Number of PDP Context activations

− Number of up/downloaded bytes

::: GPRS Performance (GPE)


Delivers information about Inbound Roamers in respect to GPRS performance these receive.

Statistics are delivered per MNC/MCC and therefore can be mapped to Inbound Roamers. A list

of measurements is given in chapter 3.6.9.

::: Service Payload Analyzer (NexusSPA) (is not part of the offer)

While GPE delivers information about session set-up and tear-down and the tunnel management,

NexusSPA provides information about how the users are using the tunnel and what type of QoS

they receive. Chapter 3.6.10 provides a list of measurements provided by NexusSPA.

3.16.1 International Roaming Monitoring (IRM2)

The IRM2 (International Roaming Monitoring 2) application is a new application, which focuses on GT

(Global Titles). It provides information to solve the following issues:

::: Severely degradation of SCCP Signaling towards One Tier 1 Network � Affects a major number

of outbound/inbound roamers.

::: Outage of one network element's (e.g. HLR) SCCP Signaling towards outbound switch peer (e.g.

foreign STP) � Major re-routing imminent and customers may be affected imminently.

::: Assessment on how much SCCP traffic, and specifically how many SMS in/outbound are

received/sent per network or country.

::: Assessment of Voice Activity of Outbound Roamers:

− How many calls do they receive?

− Can they receive calls?

::: Assessment of Tier 1 Roaming Countries:

− How many Inbound/Outbound Roamers?

− How many calls do they receive?

− Can they receive calls?

::: Recognize Present and Clear Signaling Issues to Foreign Networks.

The measurements provided by IRM2 application is described in chapter 3.6.12. It is designed to

support the following workflow (see Figure 40):

1. Select a Network Element or an Operator

2. Adjust Filter Settings

3. Check the Results and make a Selection for deeper analysis

4. Check Detailed Results


5. Check Error Information (make a selection on Detailed Results)

Figure 40: IRM2 Work Flow

3.17 LAN/WAN Requirements

The architecture of the proposed system is the following:

::: Distributed probes

::: Central server

::: Client workstations


3.17.1 Bandwidth Demand between Probes and Central Server (6.17.1.1/2)

The LAN/WAN bandwidth between probes and central server is rather small, because only condensed

information is transmitted. The total bandwidth demand, consumed by call trace and performance

measurement applications, is 12.2 Mbps required at the central server.

3.17.2 Bandwidth Demand of Client Workstation (6.17 .1.3)

Whenever a user makes a drill-down to protocol details, automatically a connection to the relevant

probes is setup and raw data is transmitted from the probe to the client's workstation. The data portion

is rather limited, because only raw data within a certain time frame is transmitted. For this "best effort

services" is used.


4 Hardware

4.1 Power requirements

4.1.1 Power Consumption (7.1.3/5)

Normally the probes of NexusNETVIEW use 110 to 230 V AC power. It is also possible to equip the

probe servers with -48V DC power supplies, which makes the overall solution approx. 30% more

expensive than using the standard powers supplies.

All the quoted equipment require 110 -230 VAC power . The power consumption per device is given in

the following table:

DELL PE 2950 110 -230 VAC 750 W

DELL PE 1950 110 -230 VAC 670 W

FE TAP 110 -230 VAC 15W

SUN M3000 110 -230 VAC 470 W

SUN ST 2510 110 -230 VAC 515 W

GE TAP 110 -230 VAC 20W

SWITCH CISCO 2960-24 110 -230 VAC 30W

NEXUS 19” SUBRACK 110 -230 VAC 600 W

AGGREGATOR FE TAP 110 -230 VAC 45 W


The power consumption is given per site and cabinet. The heat dissipation ( in watts) per cabinet is

equal to the consumed power.

Site Max. Power / Heat

Muscat 1 CABINET1

2,880 W

Muscat 1 CABINET2

3,030 W

Muscat1

Ethernet TAP Cabinet

450 W

Muscat 2

CABINET 1

2,130 W

Muscat2


120 W

Muscat2

NMC Cabinet

4,605 W

Nizwa

CABINET 1

2,880 W

Nizwa


150 W

Salalah

CABINET1

750 W

Sohar

CABINET1

2,130 W

Sohar

Ethernet TAP

cabinet

60 W

4.2 Electrical Safety

NexusNETVIEW follows international standards in respect to electrical safety. Nexus has carefully

selected products for access tapping (Protected Monitoring Points for E1 and T1 lines, Test Access

Points for electrical Ethernet links, Optical Splitters for STM-1 and optical Ethernet links), which

guarantees a propers separation of the probes from the operator's network.


4.3 Electro-magnetic Compatibility

NexusNETVIEW follows international standards in respect to electro-magnetic compatibility. probes

use standard servers from DEL and SUN.

4.4 Mechanical design

4.4.1 Probe Layouts (7.4.1)

The following cabinet layout show equipment of the porbes on each site. The NMC equipment is

assumed to be deployed in Muscat-2, but could be deployed in other location too. In addition to the

porbe cabinets, shown in this layout, an additional cabinet per site is offered, and shall be used to

hold to the FE TAPs.


Cabinet layout for the Probe in Muscat 1


Cabinet Layout for the Probe in Muscat 2


Cabinet Layout for the Probe in Nizwa


Cabinet Layout for the probe in Sohar


Cabinet Layout for the Probe in Salalah


Cabinet Layout for the NMC Equipment

4.5 Environment Conditions

4.5.1 Environmental Conditions (7.5.1)

The following environmental conditions have to be provided:

Parameter Central Server Probe

Operating Temperature 5° … 35° C 10° …35° C

Relative Humidity 20% to 80% 20% to 80%

Altitude up to 3000 m up to 3000 m


4.6 Hardware Specification

4.6.1 Hardware Components (7.6.2)

NexusNETVIEW Probes consists of the following components (see Figure 3 and chapter 3.2.1):

::: Pre-Processing Element (PPE):

These are the interface cards plugged directly into the PCI slots of the probe servers or into a

dedicated 19" sub-rack

− 1 Gigabit interface cards, which handles 2 (bi-directional) 100/1000BaseT (electrical) links,

are plugged into the probe server

− 1 Gigabit interface cards, which handles 2 (bi-directional) 1000BaseSX (optical) links, are

plugged into the probe server

− 1 STM-1 interface cards, which handles 2 (bi-directional) STM-1 (optical) links, are plugged

into the probe server

− 1 E1 interface module, which can handle 2 bi-directional E1 and 62 Signaling links of

64 kbps, are plugged into probe server

− 1 E1 interface module, which can handle 4 bi-directional E1 and up to 124 signaling links of

64 kbps, are plugged into a 19" sub-rack

− 1 E1 interface module, which can handle 16 bi-directional E1 and up to 64 signaling links of

64 kbps, are plugged into a 19" sub-rack

− 1 STM-1 interface module, which can handle 1 bi-directional STM-1 and up to 64 signaling

links of 64 kbps, are plugged into a 19" sub-rack

These interface cards are purchased from specialized interface card vendors.

::: Data Processing Element (DPE):

These are the probe servers and consists of DELL Power Edge Server 2950:

− 2 CPU, 3.00GHz,

− 8GB FB 533MHz (4x1GB dual rank DIMMs),

− 2x73GB SAS (10,000rpm) 3.5 inch Hard Drive,

− 2 hot pluggable power supply,

− RedHat Linux;

::: Data Storage Element (DSE):


The DSE store raw data for the required number of days. Normally these are HDD, which are

mounted internally of the probe servers. In cases the number of required HDD is higher than the

probe server can hold an external storage device is used. It is a DEL Power Vault MD1000.

::: Line Tapping Devices:

The are different tapping devices available:

− Protected Monitoring Points for E1 and T1 lines

− Test Access Points for electrical Ethernet links

− Optical Splitters for STM-1 and optical Ethernet links

::: 48 Port Switch:

For interconnecting the probe servers within the probe rack a switch is used, normally 48 ports,

from Cisco.

::: 19" Rack:

19" Cabinet for PPE, DPE and DSE (1000 x 800 x 2000 mm)


5 Software

5.1 Software Standards

NexusNETVIEW follows latest standards of 3GPP, ITU-T, ETSI, IETF and TM Forum.

5.2 Basic Software

Basic SW of NexusNETVIEW runs on

::: Read Hat Linux for the probe servers and NexusSCNE

::: SUN Solaris for the NexusNETVIEW central server

::: Windows XP or Windows Vista for the client workstation

5.3 Application Software

Application SW is programmed in C or Java. The following applications are available:

::: Subscriber Centric Application:

The main application that provides subscriber focus is the End-to-End Full Session Application

(FSA). Probes constantly generate so-called CLR (Communication Leg Records) from the

information read on the links. The central server aggregates these CLR to CDR and stores these

in the database.

Figure 41: CDR Generation from CDR


Since this mechanism runs in real-time, the database is always up-to-date.

::: Network Centric Applications:

NexusNETVIEW collects link-based measurements and stores these in the database of the

central server. These can be visualized by the real-time application GUI or exported to a 3rd-party

tools or NexusSCENE for creating complex KPI or dedicated reports. These applications are:

− Network Performance (NPE) application:

NPE provides basic-KPI, which follow the Q.752 standard for SS7 QoS reporting.

− GPRS Performance (GPE) application:

GPE provides basic-KPI for UMTS or GPRS data session.

− International Roaming Monitoring (IRM2) application

IRM2 collects statistics of MAP transactions.

::: Service Centric Application:

The NexusSPA (Service Payload Analyzer) provides statistics about usage of the different

services with a data session. Chapter 3.6.10 gives further details about the statistics. NexusSPA

is not part of the offer.

::: Protocol Centric Applications:

There are two applications, which complements each other as the final drill-down step:

− Protocol Analyzer Tracer (PAT):

PAT provides message decodes down to bit level.

− Event Counter Application (ECA):

ECA is an on-demand measurement application using raw data from the probes. It suites

very well for debugging purposes.

::: Reporting Frame Work NexusSCENE:

Detailed description can be found in chapter 3.2.6 and 3.6.1. NexusSCENE is a very flexible

reporting tool, which creates on-demand or scheduled reports using information from

NexusNETVIEW.


6 Availability and Redundancy

6.1 Availability

The availability of the different probes are as follows:

Site MTBF Availability 9

Muscat 1 2.08E+03 99.81%

Muscat 2 8.06E+03 99.95%

Nizwa 6.3.3E+03 99.94%

Salalah 1.33E+04 99.97%

Sohar 8.31E+03 99.95%

Central Server10 7.56E+03 99.95%

6.2 Redundancy

System can be implemented as fully redundant system as follows:

::: Probes, incl. probe servers

::: Central server

::: Clients – duplication is not required

6.3 Geographical & Physical Independency

6.3.1 Geographical Independencies (9.3.1.2)

NexusNETVIEW uses distributed probes, which can be placed at different locations. It would be

possible to duplicate these probes and have them at either end of the links. Furthermore it is possible

to have duplicated central servers, which could be placed at different locations as well. These central

servers would run in active/standby mode.

9 Assuming spare parts on site 10 NexusNETVIEW and NexusSCENE


7 Technical support and Software Update Services

7.1 Basic requirements

7.1.1 3rd Party Hardware (10.1.7)

As explained above there are three main 3rd party Hardware vendors NexusNETVIEW uses:

::: Sun Microsystems: The following components are purchased from Sun:

− Entry or mid-range SPARC server is used as central server for NexusNETVIEW.

− Workgroup disks StorageTek for HDD extension of the central server

::: DELL delivering the following components:

− PowerEdge rack servers as probe servers and central server of NexusSCENE.

− Probes servers might be extended by PowerVault Direct Attached Storage

::: Cisco for switches used within the probes

These 3rd party components are clearly specified and can be purchased by Nawras directly. In general

support for these components will be delivered by the vendors directly and, therefore, Nawras should

set-up support agreements with these vendors directly.

Other Hardware or Software components, even they are from 3rd party vendors, are maintained by

Nexus and therefore are covered by the SLA with Nexus.

7.1.2 3rd Party Software (10.1.7)

There are software components coming from 3rd parties. These components are fully bundled with

NexusNETVIEW software and therefore fall under the SLA with Nexus.

7.2 Technical assistance

The service delivered as technical assistance is specified in the SLA, which will be negotiated later.

The following options are available:

::: Telephone Support


::: E-mail (via Internet)

::: File Transfer (FTP)

::: Remote Login secure VPN (on demand / on request)

::: On-site support

Further details can be found in the SLA proposal.

7.3 Hardware Support

The Hardware support is specified in the SLA, as well.

7.4 Software support

The Hardware support is specified in the SLA, as well.

7.5 Maintenance Spare Parts

See offer.

7.6 Long Term System Support

Nexus is committed to further enhance the monitoring system NexusNETVIEW. Approximately twice

a year one new release is issued which consists of enhancements of existing functionalities, but also

new functions and features. The evolution of the system follows the following strategy:

::: Capture Enhancements

− Seamlessly spanning all network technologies.

− Probes and processing units process all of today’s network technologies

::: Communication Trace

− Fixed / Mobile Convergence and Next Generations Network bring more complex session

flows. The unique value proposition of the NexusNETVIEW is to correlate these transactions

automatically into CDRs


− CDR can be searched very fast and efficiently.

::: Performance Measurements and KPI

− Open Interfaces according to TMF (JMS, XML)

− Real-Time Events (Data Flavor 1)

− Real-Time Subscriber E2E Transactional Data (Data Flavor 2)

::: Alarm Management


8 Operation and Maintenance & Security

8.1 O&M Processes (11.1.1)

The O&M process is part of the SLA and documented in Quality Assurance process descriptions.

These can be delivered to Nawras when requested.

8.2 Configuration Management (11.2.1)

NexusNETVIEW is designed in such a way that most of the parameters are configurable. There are

different levels:

::: User can set individual GUI parameters in the window itself.

::: Administrator can set some system-wide parameters via dedicated GUIs

::: Dedicated and well documented configuration files.

8.3 Performance Management (11.3.1)

The performance of the system is continuously controlled and in case it falls below a certain threshold

value, which can be set by the administrator, an alarm is generated. The following parameters are

monitored:

::: Frames are dropped in the process chain of the probe.

::: Write errors on HDD.

::: Processing delay of the measurement agent. This is an indication for performance issues in the

KPI-generation chain.

::: Processing delay for the CDR agent. This is an indication for overload in the CDR-generation

chain.

8.4 Security (11.4.1/2)

SLA defines the updating of the system and the remote login for maintenance and support reasons.

NexusNETVIEW uses SSH for remote login.


9 Training Program and Requirements

9.1 Training requirements

9.1.1 Training Program (12.1.1)

The NexusNETVIEW training courses consist of different modules. They are designed for the basic

system user up to a system administrator. The participants will be empowered to efficiently use or

administer the NexusNETVIEW system and applications. The courses cover theoretical aspects and

mainly practical exercises.

Therefore every participant at a NexusNETVIEW training course uses the different applications from

an individual client workstation.

Handout notes are provided for each training course.

9.1.1.1 Training Facilities

The training course is held by a NexusNETVIEW expert at customer premises with a dedicated client

PC for every participant. The number of participants should be limited to six persons. The maximum

number of participants shall not exceed ten and at least one client PC per two persons is mandatory.

Furthermore a video projector is needed to present training slides and demonstrate the use of different

applications. Video projector and client workstations are required throughout all training sessions.

Training language and the documentation provided will be in English.

9.1.1.2 System Operating Training

The NexusNETVIEW System Operating Training course provides the students with the necessary

knowledge and skills to efficiently use the NexusNETVIEW base applications Network Performance,

Alarm Monitor, Call Trace and Protocol Analyzer / Event Counter. It consists of the following modules

::: Day 1

− Module 1 System Architecture

− Module 2 Network Performance

− Module 3 Alarming


::: Day 2

− Module 5 Call Trace

::: Day 3

− Module 6 Protocol Analyzer / Event Counter

Note: Depending on the environment the order of the training modules might be changed.

::: Topics ::: Module 1: System Architecture

The participant gets to know the different system components and

their function. He understands the concepts of data acquisition and

storage. Furthermore the user gets an introduction to the

NexusNETVIEW GUI and an overview about the base applications.

::: Module 2: Network Performance

The participant configures and uses the Network Performance

application to obtain the needed results and statistics. He understands

the network structure and how it is represented in NexusNETVIEW. He

understands and uses filter concepts and exports data according to his

needs.

::: Module 3: Alarming

The user understands the threshold alarming concept implemented in

NexusNETVIEW. He uses the Alarm Monitor and knows how to

identify signaling links or network elements causing trouble.

::: Module 5: Call Trace

The user understands the basic CDR correlation concepts / call

scenarios and uses simple and advanced search functions of the CDR

Trace application.

::: Module 6: Protocol Analyzer / Event Counter

The user operates the protocol analyzer on single and multiple link

sets. He uses simple and complex filter functions to locate the desired

signaling messages. For efficient drill down and trouble shooting the

combination of CDR call trace and protocol analysis is applied.

The user operates the Event Counter application in addition to the

protocol analyzer and generates reports down to nearly every protocol

info elements.


::: Prerequisites All participants should have the following skills:

::: Experience with graphical user interfaces / Windows techniques

::: Familiar with OSS environment

In addition for Help Desk users:

::: Trouble-shooting procedures

::: Basic knowledge of the network configuration

::: Basic knowledge of signaling protocols

Expert OMC / NMC users:

::: In depth telecom protocol knowledge for signaling trouble shooting and

call failure analysis

::: Network operation / management

::: Task-oriented, business process driven use cases

The maximum number of participants shall not exceed 10 persons. We

recommend limiting the number of participants to 6 persons per session.

9.1.1.3 Application Administration Training

This training course is intended for a smaller number of power users. The participants get a deeper

understanding of the NexusNETVIEW system in terms of configuration and they are able to provide

first level support on an application level. They learn to implement or change the existing network

configuration. The application administration training comprises the following 1 day module "System

and User Configuration":

::: Topics The user is able to modify and expand the current system configuration.

Alternatively he can implement a new configuration from scratch. The user

is familiar with

::: Network regions, sub regions, signaling points, link sets

::: Buildings, probes, cards, interfaces, channels

::: Graphical and tabular view

::: Starting and stopping of individual probes

::: Config Tool

::: Disaster recovery procedures

::: Prerequisites The participants should previously attend the NexusNETVIEW System

Operating training. The System Administration Training might be suitable


as well for power users of NexusNETVIEW applications.

The number of participants is limited to four to six persons with at least one

client PC per two persons.

9.1.1.4 System Administration Training

The system administrator has a deeper understanding of the NexusNETVIEW system components.

He configures user access rights and permissions for the different applications. The system

administrator has a basic understanding of the vital system processes and knows the relevant trouble

shooting procedures on UNIX / Sybase level. This is a 1 day training module.

::: Topics The user is familiar with

::: User administration / access rights

::: Sybase setup

::: Express backup; backup / restore

::: Vital NETVIEW system processes

::: System health checks

::: Trouble shooting

::: Log files

::: Prerequisites It is recommended, that the participants should previously attend the

NexusNETVIEW System Operating training.

Designated system administrators should have the following skills:

::: UNIX system administration know-how, preferably on Sun Solaris

::: Database know-how (preferably Sybase)

::: Familiar with backup / restore concepts

9.1.1.5 Protocol / Technology Training (optional)

The participants will learn the structure of Next Generation Networks, the function of the network

elements, principal network procedures as well as the physical interfaces.

9.2 Training in Oman

Training will be held in Oman.


10 Documentation

10.1.1 Documentation (13.1.2)

The documentation coming with the quoted solution consists of:

::: User Manual

::: Administration- and Maintenance Manual

::: Acceptance Test Plan

::: Site Configuration Description

::: Training Material for every participants of a training course

These documents are written in English and are available as electronic copies on a CD/DVD.

Notice

Every effort was made to ensure that the information in this document was accurate at the time of

printing. However, information is subject to change without notice, and Nexus Telecom reserves the

right to provide an addendum to this document with information not available at the time that this

document was created.

Copyright

Copyright 2008 Nexus Telecom. All rights reserved. No part of this document may be reproduced or

transmitted electronically or otherwise without written permission of the publisher.

Trademarks

Nexus Telecom and its logo are trademarks of Nexus Telecom AG. All other trademarks and

registered trademarks are the property of their respective owners.

Revision History

Version Date Author

0.1 04DEC2008 Walter Buehler

Date post:	31-Oct-2014
Category:	Documents
Upload:	amir-h-choomboolou
View:	71 times
Download:	0 times

a

Documents