EAST Architect Document v1.

EAST Architect Document

Proprietary and Confidential 1

 EAST Architect Document v1.0

EAST Architect Document

Current EAST System

Contents
1. INTRODUCTION.............................................................................................................................................................5
1.1 PURPOSE.....................................................................................................................................................................5
1.2 SCOPE.........................................................................................................................................................................5
1.3 VOCABULARY.............................................................................................................................................................5
1.4 REFERENCES...............................................................................................................................................................7
2. ARCHITECTURE CONSIDERATION..........................................................................................................................8
2.1 ASSUMPTIONS AND DEPENDENCIES............................................................................................................................8
2.2 CONSTRAINTS.............................................................................................................................................................8
2.3 RISKS AND VOLATILE AREAS.....................................................................................................................................9
3. HIGH LEVEL ARCHITECTURAL OVERVIEW........................................................................................................9
3.1 SOFTWARE ARCHITECTURE.......................................................................................................................................10
3.1.1 Description..........................................................................................................................................................10
3.2 HARDWARE ARCHITECTURE.....................................................................................................................................11
3.2.1 Description..........................................................................................................................................................11
3.3 SYSTEM BLOCK DIAGRAMS......................................................................................................................................13
3.3.1 Main EAST Block Diagram................................................................................................................................13
3.3.2 EAST Platform Block Diagram...........................................................................................................................14
3.3.3 EAST Adaption Layer Diagram..........................................................................................................................15
3.3.4 EAST Services Block Diagram............................................................................................................................15
3.3.5 EAST Core Block Diagram.................................................................................................................................17
4. SYSTEM DECOMPOSITION.......................................................................................................................................18
4.1.1 Introduction.........................................................................................................................................................19
4.1.2 EAST Platform Subsystem...................................................................................................................................19
4.1.2.1 Base Hardware sub subsystem..................................................................................................................................19
4.1.2.2 Interface Hardware sub subsystem............................................................................................................................20
4.1.2.3 Operating System sub subsystem..............................................................................................................................21
4.1.2.4 Interface Drivers sub subsystem................................................................................................................................21
4.1.2.5 System Tools sub subsystem.....................................................................................................................................21
4.1.3 EAST Adaption Layer Subsystem........................................................................................................................22
4.1.3.1 OS Adaption Layer ss-system...................................................................................................................................22
4.1.3.2 NH Adaption Layer sub subsystem...........................................................................................................................22
4.1.3.3 NPU Adaption Layer sub subsystem.........................................................................................................................23
4.1.4 EAST Services Subsystem...................................................................................................................................23
4.1.4.1 Protocol Server..........................................................................................................................................................24
4.1.4.2 IPXPress ss-system...................................................................................................................................................34
4.1.4.3 DataGenerator ss-system...........................................................................................................................................36
4.1.4.4 Licensing sub subsystem...........................................................................................................................................36
4.1.4.5 Security:.................................................................................................................................................................... 37
4.1.4.6 CLI............................................................................................................................................................................ 37
4.1.4.7 Event......................................................................................................................................................................... 38
4.1.4.8 Database....................................................................................................................................................................39
4.1.4.9 Process [Service Component]...................................................................................................................................39
4.1.4.10 Command [Service Component]...............................................................................................................................39
4.1.4.11 Resource [Service Component].................................................................................................................................39

Proprietary and Confidential 2

 EAST Architect Document v1.0

4.1.4.12 Logging [Service Component]..................................................................................................................................39

4.1.4.13 Codec [Service Component]:....................................................................................................................................39
4.1.4.14 Compression [Service Component]:..........................................................................................................................39
4.1.5 EAST Core Subsystem.........................................................................................................................................39
4.1.5.1 Desktop ss-system.....................................................................................................................................................39
4.1.5.2 Logic Editors ss-system............................................................................................................................................40
4.1.5.3 Message Editors ss-system........................................................................................................................................40
4.1.5.4 Database Editors ss-system.......................................................................................................................................41
4.1.5.5 Engine ss-system.......................................................................................................................................................41
4.1.5.6 Log Viewer ss-system...............................................................................................................................................43
4.1.5.7 Runners ss-system.....................................................................................................................................................44
4.1.5.8 Reporter ss-system....................................................................................................................................................44
4.1.5.9 Scheduler ss-system..................................................................................................................................................44
4.1.5.10 Admin Utilities sub subsystem..................................................................................................................................44
4.1.5.11 Test Management sub subsystem..............................................................................................................................46
4.1.5.12 Installer/Uninstaller sub subsystem...........................................................................................................................46
4.1.5.13 Configuration sub subsystem....................................................................................................................................47
5. USE CASES......................................................................................................................................................................48
5.1.1 Configuration Management:...............................................................................................................................48
5.1.1.1 Installation of EAST:................................................................................................................................................48
5.1.1.2 Starting of EAST Desktop:........................................................................................................................................50
5.1.1.3 Checking EAST License:..........................................................................................................................................51
5.1.2 Message Creation:..............................................................................................................................................52
5.1.2.1 Create Message Template:.........................................................................................................................................52
5.1.3 Test Case Creation:.............................................................................................................................................53
5.1.3.1 Resource TIO:...........................................................................................................................................................54
5.1.3.2 Create Database:....................................................................................................................................................... 55
5.1.3.3 Create TestCase:........................................................................................................................................................ 56
5.1.4 Test Case Execution:...........................................................................................................................................57
5.1.4.1 Transmit/Receive Message using UDPServer:..........................................................................................................57
5.1.4.2 Transmit/Receive Message using TCPServer:...........................................................................................................59
5.1.4.3 Transmit/Receive Message using UTRANServer:....................................................................................................60
5.1.4.4 Transmit/Receive Message using SigtranServer:.......................................................................................................62
5.1.4.5 Transmit/Receive Message using MTP3Server:........................................................................................................64
5.1.4.6 Transmit/Receive Message using SCTPServer:.........................................................................................................65
5.1.4.7 Transmit/Receive Message using GTPServer:...........................................................................................................67
5.1.4.8 Transmit/Receive Message using LUCPServer:........................................................................................................67
5.1.4.9 Transmit/Receive Message using IPXpress Server:...................................................................................................68
6. PRODUCT STRUCTURE..............................................................................................................................................71
6.1 PRODUCT STRUCTURE..............................................................................................................................................71
6.1.1 “Single User” EAST Configuration....................................................................................................................71
6.1.2 “Multi User” EAST Configuration.....................................................................................................................71
6.1.3 “Multi User Centralized Data” EAST Configuration........................................................................................72
6.1.4 “Centralized Load” EAST Configuration..........................................................................................................73
7. EAST PRODUCT BUILD PROCEDURE:...................................................................................................................75
8. Question/Answer...............................................................................................................................................................77

Proprietary and Confidential 3

 EAST Architect Document v1.0

Table of Figures
Figure 3 - EAST Software Architecture...................................................................................10
Figure 4 - EAST Hardware Architecture..................................................................................11
Figure 5 - Main EAST Block Diagram.....................................................................................13
Figure 6 - EAST Platform Block Diagram................................................................................14
Figure 7 - EAST Adaption Layer Block Diagram.......................................................................15
Figure 8 - EAST Services Block Diagram................................................................................16
Figure 9 - EAST Protocol Layer Block Diagram........................................................................17
Figure 12 - Installing EAST Use Case Diagram........................................................................49

Proprietary and Confidential 4

 EAST Architect Document v1.0

1. Introduction
The EAST is a tool comprises of its set of H/W and S/W to simulate different network
elements to test telecom network entities.

It provides integrated environment for Test Case development, platform to execute Test
Cases and automated environment for testing.

1.1 Purpose
The purpose of this document is to outline the EAST System, sub-system, sub sub-system †,
component and modules.

1.2 Scope
Audiences of the document are architects, designers. This document also helps to add new
component/module to EAST and reuse EAST existing Component/Modules. The document will
provide enough high-level information to allow R&D to create additional high-level documents
specifying EAST sub-systems, sub sub-system†, which will lead to a detailed design of every
Component in EAST.

1.3 Vocabulary
TERM DESCRIPTION
EAST Environment for Automated System Testing
System A group of interacting, interrelated, or interdependent elements forming
a complex whole.
Sub-system A unit that is a part of large system.
Sub sub-system It is unit of large sub-system, too large to be treated as a
component. Now onwards it will be called as “ss-system”.
Component Component is a software package or a module that encapsulates a set of
related functions.
Service Component: If all the modules (Internal modules)
of a component are used in other components, then that will
be termed as Service Component

Internal Component: If some of the modules are used in

that component and also some of the modules of which are
used by other components (Service modules), then that will
be termed as Internal Component.

Module It is smallest independent units which can an executable of shared library.

Service Module: If a module is used in more than one

component, then that will be termed as Service Module.

Internal Module: If a module is used in one component

only, then that will be termed as Internal Module.

Proprietary and Confidential 5

 EAST Architect Document v1.0

TERM DESCRIPTION

BER Basic Encoding Rules. These are used as part of ASN1.

CN Core Network.
Gb In GPRS, the interface between BSS and SGSN. Gb can run over
Frame Relay or IP.
H323 Protocols to transmit video or audio over packet networks.
ICMP Internet Control Message Protocol. Used mainly for error
reporting and diagnostic/routing functions over IP.
IP Internet Protocol.
IPSec Protocols used for securing data over IP. This handles
authentication and encryption of data.
JDK Java Development Kit. Contains a VM as well as a compiler and
other development tools. Currently, EAST uses the 1.4.2 version
supplied by Sun.
JNI Java Native Interface. A feature of Java that allows a method (or
methods) to be declared native. The developer is then
responsible for creating the implementation of that method in
C/C++. This must be done carefully, as the C/C++ code can
corrupt data in the JVM, resulting in a loss of runtime safety, etc.
However, the performance improvement may be worth the risk.
JRE Java Runtime Environment. Contains the virtual machine used to
run Java applications. Currently, EAST uses the 1.4.2 version
supplied by Sun.
LLC Logical Link Control. Handles multiplexing protocols transmitted
over the MAC layer, as well as providing flow control.
Load Testing To test a SUT with large amounts of messages to test
MTP2 Message Transfer Part 2. Corresponds to the OSI Layer 2 for
SS7 (link layer).
MTP3 Message Transfer Part 3. Corresponds to the OSI Layer 3 for
SS7 (network layer).
MUMB Multi-user/Multi-board. Originally, EAST was designed so it could
run on a single board for a single user. As requirements evolved,
it became necessary for a single user to control the actions of
multiple boards at the same time. The MUMB system allows a
user to reserve a set of boards in a chassis, configure them, then
start test cases on them all at once.
PER Packed Encoding Rules. Used as part of ASN1. Allows data to be
encoded in the minimum number of bits. PER may be aligned
(octet-based) or unaligned (data can cross octet boundaries).
PESQ Perceptual Evaluation of Speech Quality. ITU-T recommendation
P.862. Used to determine the quality of speech over a telephone
network.
PSTN Public Switched Telephone Network. Differs from an IP-based
network by relying on circuit-switching as opposed to packet-
switched, networking.
RTP Real-time Transport Protocol. Used to send audio and video over
IP-based networks.
SAP Service Access Point. A network endpoint in the OSI model.
SNAP Subnetwork Access Protocol. Used for multiplexing (using IEEE
802.2 LLC) more protocols than can be used with the 8-bit 802.2

Proprietary and Confidential 6

 EAST Architect Document v1.0

TERM DESCRIPTION
SAP fields.
Streams A SysV feature that allows user-space applications to access
drivers in full-duplex mode.
TALI Tekelec’s Transport Adapter Layer Interface. Used to route SS7
messages over IP connections.
TC Test Case. These are created by the user, and generated to run
in the LoadEngine.
TCP Transmission Control Protocol. A streamed-based layer over IP.
Handles reliability and ordering of data.
TIO Test Independent Object. This is a generic object in EAST that
can be used to build individual state machines that make up the
Test Cases. Since these objects originally did not represent a
specific protocol, network element, or hardware, they were
referred to as Independent.
TLP Test Logic Procedure. When a given sequence of TIOs can be
reused across multiple parts of a TC (or in multiple TCs), it
makes sense to isolate those sequences in a separate TLP to
allow for reuse and easier modification.
TLT Test Logic Thread. Used to create separate threads of execution,
which can be run at the same time. Can be used in TCs, TLPs,
and TSs.
TS Test Suite. A collection of TCs that may contain TLPs and TSs,
which then can be scheduled for execution.
SS7 Signaling System #7. A series of protocols used to setup and
maintain calls over the PSTN system.
SUT System Under Test. The customer’s hardware that needs to be
evaluated and tested by EAST.
UDP User Datagram Protocol. A datagram-based layer over IP. Does
not handle reliability or ordering of data.
UMA Unlicensed Mobile Access. Also known as GAN (Generic Access
Network). Allows roaming and handover between local-area and
wide-area networks.
UMTS Universal Mobile Telecommunications System.
UTRAN UMTS Terrestrial Radio Access Network. Collective term for
NodeBs and RNCs in a UMTS system.
WiMAX Worldwide Interoperability for Microwave Access. Allows wireless
data to be sent over long distances.

1.4 References
Document Location
Wikipedia http://en.wikipedia.org/wiki/Main_Page.
This is used for some definitions of protocols, etc.

Proprietary and Confidential 7

 EAST Architect Document v1.0

2. Architecture Consideration
When designing for the EAST system, there are several considerations to keep in mind.

 To make EAST Architecture simple, it is divided in to various sub-system, ss-system,

component and modules. This document depicts an overall EAST Architecture, not a
detailed high-level/detailed design of the sub-system, ss-system.
 EAST system is designed considering Red Hat Linux operating system as its base
platform.
 All hardware solutions are off-the-shelf.
 Any external drivers or libraries should have an abstraction layer written for them to
hide the actual implementation of that driver/library. This abstraction layer is
maintained by the owner of the driver’s Component Stream. All other code will use this
abstraction layer, as opposed to the driver/library API provided by the vendor. This
makes it easier to migrate to a different vendor without affecting upper code layers.

2.1 Assumptions and Dependencies

EAST is dependent on various third-party tools, device driver for H/W involved and Linux OS.
Therefore an upgrade to the operating system or build tools are considered, these third-party
packages must be checked and evaluated to make sure that they will continue to operate in
that new configuration.

Below link contain list of all 3rd party S/W as well as H/W list and their licenses.

https://nhdocuments.nethawk.fi/productcreation/linemanagementindia/RD
%20Meetings/Product%20Architecture/EAST_3rd_party_licences.xls

2.2 Constraints
Although EAST supports cross platform compatibility of Win32 and Linux, Test Creation and
Test Execution is done in Linux OS and Win32 is used only for Test Creation. Since the GUI
must run on multiple platforms, the Java platform is used.

Another constraint is the speed of the software, especially in the protocol-based Servers. Most
protocol servers must be able to run against a customer’s SUT, and as a result, must be able
to service requests quickly, and not spend a lot of time processing events.

The third constraint on EAST software is memory. All EAST software and its data must be able
to fit into the memory of a GPU, which is critical since the EAST hardware setup does not allow
for a swap file (due to performance).

Proprietary and Confidential 8

 EAST Architect Document v1.0

2.3 Risks and Volatile Areas

Multiple Cores in New Hardware: The current form of EAST is running on SMP OS where
we are availing limited functionality of multiple cores of the processor. So to use multiple cores
of the future hardware, we need to take advantage of multithreading and kernel based
threading.

The Bearer services can make use of multi core Network processors units for L2 and L3
transport services and various bearer protocols to support more scalable and performance in
bearer services.

64 bit Operating System: Currently EAST uses 32 bit address space programming. But the
new era of H/W and OS is moving towards 64 bit, so EAST system should migrate to 64 bit
processing.

Third-party Tools: There is a risk of using 3rd party tools. These include:
1. Vendor going out of business: Self-explanatory.
2. Vendor discontinuing product: This may or may not affect EAST, depending on our
licensing agreement.
3. Vendor no longer supporting an OS that EAST must support: This can be risky. If
Vendor A drops support for RH9.0, for example, but Vendor B won’t support RHEL4, then
EAST becomes stuck between two opposing requirements.
4. Changes to the interfacing API: If the Vendor changes the API for a new version of the
product, EAST must change its API calls, which takes time.
5. Prohibitive change in licensing agreements: For example, the Vendor may decide to
change future licensing from flat-fee to a per-item royalty, which may make using the
Vendor’s product painful enough to require a change.

In the above cases, EAST can minimize the impact by taking the following steps:
1. Wrap all API calls: By isolating where the API calls are made to the Vendor’s library,
EAST can make it simple to change vendors, or modify the API used.
2. Keep EAST platform requirements up to date: EAST must be able to support the
newer releases of the platform operating system. While we can drop older versions, we
must be able to support the newer versions in a reasonable amount of time.
3. Check alternatives: More than likely, the Vendor in question isn’t the only one with that
particular type of offering. R&D must keep an eye on trends, and make suggestions as to
changing Vendors if appropriate.

3. High Level Architectural Overview

Proprietary and Confidential 9

 EAST Architect Document v1.0

3.1 Software Architecture

Figure 1 - EAST Software Architecture

3.1.1 Description
The above diagram shows high level architectural view of the EAST Systems, mainly aligned
along the application level.

The above diagram shows the following:

1. Desktop: It is a start up application of EAST through which other application can
be launched and used thereafter.
2. License Server: Handles the licensing for the EAST system.
3. Link Status: Shows the status of individual links running in one of the Protocol
Servers. For example MTP3Server(E1/T1 link), UTRANServer(AAL5 link, aal2 link)
etc.
4. EventServer: Handles communication between EAST Processes through tcp/ip
interface.
5. Editors: Main user interface to create TestCases, Protocol Messages(Binary,
ASCII), Database tables etc. TestCase and Protocol Message Editors generate
readable scripts to be used for execution.
6. Runners: Main User interface for test execution. It provides different option like
Log-Level, start/stop execution, Call Profiling etc for Test Execution.
7. Logger/Reporter: This facilitate user to view post execution Logs and Reports.

Proprietary and Confidential 10

 EAST Architect Document v1.0

8. Configuration: Single Framework of GUI which facilitate user to configure

Protocol Server parameters, System parameters etc.
9. Scheduler: Used to schedule tasks.
10.LoadEngine: it is the driving force behind EAST. Basically, it translates test cases
scripts created by the user into a series of instructions, and executes.
11.ProtocolServer: Handles the protocol-based interface to the SUT. The
ProtocolServer is responsible for maintaining a link connection with the SUT, and
for encoding/decoding messages through the protocol stack as configured.

3.2 Hardware Architecture

Figure 2 - EAST Hardware Architecture

3.2.1 Description

The diagram above represents a basic EAST Hardware setup. There are multiple ways to
configure an EAST installation with various hardware configurations based on customer
requirement matching to EAST product portfolio.

The above diagram shows the following:

1. User Network: Represents the User, as well as the interface used to access the
EAST Desktop and associated GUIs.
2. EAST Hardware: It includes H/W platforms used by OS and EAST S/W.
3. Data Server: It is used for NFS, DHCP, bootp, tftp and remote login services for
EAST H/W.

Proprietary and Confidential 11

 EAST Architect Document v1.0

4. Switch Card: Used for communication in-between Data Server and the individual
boards in the Chassis.
5. GPU: General Processing Unit. The basic board with the CPU, memory based on
TCA and AdvancedTCA. The personality of the card is derived from the attached
PMC/AMC respectively.
6. Chassis: It is a rack mount which is used to contain the EAST boards.
7. Interface Cards: These are PMC/AMC H/W mounted in GPU is used for
communication with SUT over OC3/E1/T1/J1 for ATM, E1/T1/FR for SS7, Ethernet
and NPU.
8. SUT: The User’s System Under Test. The Customer hardware that will be tested
by EAST.

There are four main EAST configurations, each with sub-configurations that will need to be
managed:

1. “Single User” System

2. “Multi-User” System
3. “Multi-User with Centralized Data” System
4. “Centralized Load” System

These are discussed (and examples given) in the Appendix (Section 5.1).

Proprietary and Confidential 12

 EAST Architect Document v1.0

3.3 System Block Diagrams

3.3.1 Main EAST Block Diagram

Figure 3 - Main EAST Block Diagram

The EAST System is divided into following Sub-system.

1. Platform: This Sub-system describes H/W and OS images. Also it handles all the 3 rd
party interface hardware like Xalyo PMC/AMC, Adax PMC/AMC, NPU and system tools.

2. Adaption Layer: This Sub-system describes the OS abstraction layer and 3 rd party
S/W wrappers which, hides their implementations from the rest of the EAST layers.

This abstraction makes easier for the EAST system to be ported on different hardware
and operating systems. This includes providing a common interface for IPC, Memory
Management, File Management, 3rd party S/W and other utilities.

3. Services: This Sub-system describes different functionality needed to operate the

EAST system. This includes Protocol Servers, Database, licensing etc.

4. Core: This Sub-system includes Test Creation, Test Execution, Test Management and
Automation.

5. Test Packages: Test Packages are used to simulate protocol specific call flows. These
are Customer deliverables developed using EAST.

Proprietary and Confidential 13

 EAST Architect Document v1.0

3.3.2 EAST Platform Block Diagram

Figure 4 - EAST Platform Block Diagram

The Platform layer consists of the following ss-systems:

1. SUT: The customer’s System under Test.

2. IUT: The interface under test.

3. Base Hardware: The H/W in which OS and EAST application runs.

4. Interface Hardware: The interface cards used by EAST, attached to Base

Hardware to provide necessary physical connectivity with customer’s SUT.

5. Drivers (Interface Card Driver): 3rd party software provided by the

manufacturer of the Interface Card hardware. These drivers run on OS installed in
Base H/W.

6. Operating System: The Operating System used in EAST Base H/W. EAST uses
Red Hat Enterprise Linux as its OS. This version of RHEL may contain a customized
kernel, if needed.

7. System Tools: This provides all the different software which will run in operating
system to provide utility.

Proprietary and Confidential 14

 EAST Architect Document v1.0

3.3.3 EAST Adaption Layer Diagram

Figure 5 - EAST Adaption Layer Block Diagram

The EAST Adaption Layer is built on top of the EAST Platform Layer, and can be broken up into
the following ss-systems:
1. OS Adaption Layer: This ss-system provides a common interface to rest of EAST
applications and hides the OS specifics system calls and utilities.

2. NH Adaption Layer: This ss-system provides a common interface to all EAST

applications for basic programming utilities.

3. NPU Adaption Layer: This ss-system provides a common interface for NPU SDK
and Linux kernel irrespective of its architecture.

3.3.4 EAST Services Block Diagram

Proprietary and Confidential 15

 EAST Architect Document v1.0

Figure 6 - EAST Services Block Diagram

This ss-system lies on top of Adaption Layer providing specific services to upper layer.

The EAST Services layer contains functionality needed by other EAST applications and
Subsystems. These include the following ss-systems:

1. Event: Handles Data communication between all EAST processes using TCP/IP.
This provides a serialization and publisher/subscriber model for communications.

2. Protocol Server: These provide different services depending upon different

Protocol stacks and requirements. Basically Protocol Server emulates Physical Layer
to Transport Layer using respective Physical Layer devices.

3. IPXPress: These provide NPU base service using NPU H/W for faster IP packet
processing and various IP services.

4. Data Generator: These provide data generation services to various Protocol

Servers. These include Sequenced packets, Dummy or Pseudo Noise Data and
various codecs data Generation. These services are basically embedded inside the
protocol services to test various bearer capabilities of the interface.

5. Process: This is a system service to fork and handle any processes from the OS for
EAST. e.g starting or stopping any OS utility application from EAST.

6. Command: This is a system service used to connect, login, command execution in

a remote machine using remote login utility telnet or ssh from EAST.

7. Resources: Handles Resource allocation for multi-users by defining different

Testbeds.

Proprietary and Confidential 16

 EAST Architect Document v1.0

8. Logging: Handles all logging and recording the execution status for post execution
analysis.
9. Licensing: Facilitates Licensing verification for EAST User and application.

10.CLI: Command Line Interface services of EAST. This allows User to operate EAST
and execute EAST applications, locally as well as remotely without any GUI
interaction.

11.Codec: This provides various codec services for Data Generation.

12.Security: This provides authentications and ciphering algorithms for technologies

like IMS, 2G, 3G, LTE etc from EAST.

13.Database: Handles the database connectivity and data management between

EAST applications and various Databases it supports.

14.Compression: This provides data compression for signaling messages for SIP,
SIPT using Deflate algorithm.

3.3.5 EAST Core Block Diagram

Figure 7 - EAST Protocol Layer Block Diagram

Proprietary and Confidential 17

 EAST Architect Document v1.0

The layer handles the core of EAST System which, consists of EAST UI, EAST Engine and Basic
Utilities of EAST System. The Core Layer is used by Test Packages.

This layer is divided into following ss-systems:

1. Desktop: The main User Interface to start any other EAST applications.

2. Logic Editor: This is the integrated development environment to create or edit

Test Cases. It includes TC Editor, TLP Editor, TLT Editor, TS Editor and Reference
Editors.

3. Message Editor: This facilitate user to create protocol messages as per the
specification.

4. Database Editor: This provides to create user defined database tables.

5. Engine: It executes different state machine, send messages to protocol server,

receive and decode message from Protocol server, generate call details report and
support logging for post execution debugging.

6. Runner: This provides environment to execute scripts by invoking Engine and

collect statistics from Engine during run time.

7. Log Viewer: This is user interface for post execution analysis of Engine logs.

8. Reporter: These applications are used to shows/filters test execution

status/history based on execution timestamp, test case names etc.

9. Scheduler: Provides scheduling services for EAST runners.

10.Admin Utility: This provides environment to create user, grant user permissions.

11.Test Management: This provides facility to handle EAST keywords, Batch

Operation and EAST File Management.

12.Install/uninstall: This provides utility to install/uninstall different test packages

and EAST Patches.

13.Configuration: This provides an environment for all EAST configurable.

4. System Decomposition

Proprietary and Confidential 18

 EAST Architect Document v1.0

4.1.1 Introduction

EAST is the System and all applications, libraries, tools, files, etc, are considered part of the
EAST system.

Note: Wherever applicable the languages used to develop components/modules are noted in
each section explained below. If not noted it implies that C++ Language is used.

4.1.2 EAST Platform Subsystem

This subsystem is the lower most layers of EAST systems which includes H/W, OS images, all
the 3rd party interface hardware like Xalyo PMC/AMC, Adax PMC/AMC, NPU and system tools.

This subsystem is divided further in different ss-system and components as follows:

4.1.2.1 Base Hardware sub subsystem

Note: This section describes H/W information and no S/W is applicable.

Proprietary and Confidential 19

 EAST Architect Document v1.0

1) Chassis: The chassis refers to the rigid framework of rack mount into which the GPU
blades, RTMs, switch card, cooling modules, power modules etc are mounted.

2) GPU: General Processing Unit. This consists of mother board, CPUs, memory modules.
The personality of the blade is based on the architecture of PCI Industrial Computer
Manufacturers Group (PICMG). EAST supports cPCI and ATCA form factor.

3) RTM: This is Rear Transition Module mounted in the rear side of the Chassis basically
include the internal HDD for GPU.

4) Switch Card: This is the internal switch attached to the chassis and provides Ethernet
connectivity for all the GUPs and Data Server.

5) Data Server: Used as a boot agent for all the GPUs, host the file system for EAST and
allow users to login to GPU via IP forwarding.

6) TravelHawk : A standalone and portable system for EAST installation and execution.

4.1.2.2 Interface Hardware sub subsystem

EAST supports both AMC and PMC form factor depending up on type of GPU used. PMC
card are used for cPCI form factor and AMC card are used for ATCA form factor.

1) Ethernet Card: This is an additional card which provisions multiple Ethernet port to the
Base H/W. This can be an AMC/PMC/PCI-X form factor. EAST supports these H/Ws from
vendor Kontron and Intel (PCI-X).

2) ATM/CU (OC3/E1/T1/J1) Card: This card provides ATM link over OC3/E1/T1/J1. This
card can have cPCI/AMC/PMC form factor. EAST supports these H/Ws from vendor
Xalyo.

3) SS7 (E1/T1/J1/FR) card: This card provide SS7 functionalities over E1/T1/J1/FR
link. This card can have AMC/PMC form factor. EAST supports these H/Ws from vendor
Adax HDCII and HDC3.

4) DSP (E1/T1): This card provides bearer functionalities over E1/T1. This card can have
cPCI and PCI form factor. EAST supports these H/Ws from vendor NMS (both cPCI/PCI),
FACT (PCI).

5) Analog Card: This card handles the Analog Signal to connect to the PSTN Networks.
This card can have PCI form factor and EAST supports Dialogic analog card for this.

6) PMC2PCI adapter: This card used to convert PMC card into PCI card, so that that will
fit in PCI slot of a system.

7) NPU Card: This is multi core network processor cards in both AMC/PCI-X form factor
used for bearer services. EAST use Radisys(AMC), Kontron(AMC) and Cavium(PCI-X and
PCI-Express) as NPU vendor.

8) External Data Generator: This provide facility to generate application (ftp, http, mms)
Data from external H/W. EAST use Shenick for External Data Generator.

Proprietary and Confidential 20

 EAST Architect Document v1.0

4.1.2.3 Operating System sub subsystem

1) Linux (RedHat): Linux Operating system. EAST uses RHEL4.5 32 bit as Operating
System for its Base H/Ws.

2) Windows (XP SP3, 2000): Microsoft Operating System for EAST Desktop.

3) SimpleEx: Debian3 Linux and this operating system is used in NPU ss-system.

4) VxWorks: This is a real time Operating System. This is used in CU board.

4.1.2.4 Interface Drivers sub subsystem

These are the vendor specific device drivers loaded to the Operating system of Base
H/W.

1) Adax Driver: It provides a framework to interact with Adax card and following
services.
 qcx: Provides an API to send commands to the Adax card.
 LiS: The Linux Streams library. Adax uses this to send messages to their
driver.
 hdc: The driver to support MTP2/HDLC on the Adax card.
 fr driver: The driver to support FR on Adxa card.

These are used for MTP2 based, FR based testing.

2) Xalyo Driver: This provides a framework to interact with Xalyo card.

3) NMS Driver: This driver is used by EAST to interact with NMS DSP card.

4) FACT Driver: This driver is used by EAST to interact with FACT DSP card.

5) Dialogic Driver: This driver is used by EAST to interact with Dialogic Analog card.

6) Cavium Ethernet Driver: This is the ICD driver used in NPU as Ethernet device driver.

7) Cavium BSP: This is Board Software Package which includes uboot loader, Debian 3.1
64 bit Linux Image, Octeon root file system and Octeon tools used in NPU subsystem.

8) Ethernet Driver: This driver is used by EAST to interact with Ethernet Card. i.e. Intel
e1000 driver.

4.1.2.5 System Tools sub subsystem

Proprietary and Confidential 21

 EAST Architect Document v1.0

1) Compilation Tool: Used to compile EAST source code. The Compilation tools are
dependent upon operating System and development language. In Linux EAST uses gcc,
java and cross compiler (Cavium SDK) as compilation tool. In windows EAST uses VC6+
+ and java as compilation tool.

2) Scripting Tool: EAST uses various scripting tools like bash script, TTCN, pearl etc.

3) Utility Tool : These tools are used in EAST for various purposes, such as capturing the
Data flow in Ethernet, ftp services, Ethernet throughput measure etc. All these are 3 rd
party tools.

4.1.3 EAST Adaption Layer Subsystem

4.1.3.1 OS Adaption Layer ss-system

This ss-system provides a common interface to rest of EAST applications and hides the
OS specifics system calls and utilities.

1) IPC Management[Service Module]: This module is used by all EAST application for
Inter process communication related system calls, utilities. On the above OS Adaption
Layer, NH AL and NPU AL resides.

4.1.3.2 NH Adaption Layer sub subsystem

This ss-system provides a common interface to all EAST applications for basic
programming utilities.

1) Memory Management[Service Module]: This module is used by all EAST application

for memory handling using various data structure, containers and stream management
such as buffer, messages queue, bit field, pdu stream etc.

2) Timer Management[Service Module]: This module provides all the timer

management operation like timer starting, timeout handling etc to all EAST applications.

3) Math Operation[Service Module]: This module provides all the mathematical

operation like integer convertor, hex data convertor etc.

4) File Management[Service Module]: This module provides file handling operations like
create file, read/write from file etc.

5) Driver Management[Service Module]: This module provides a common wrapper to

the driver of similar H/W from different vendors.

6) External Software Management[Service Module]: This module provides wrapper to

the external S/Ws used by EAST. It helps integrating external S/W of different versions
without changing the EAST code.

Proprietary and Confidential 22

 EAST Architect Document v1.0

4.1.3.3 NPU Adaption Layer sub subsystem

NPU Adaption Layer is an achieve library with name libnhal.a which is statically liked to the
IPXpress module. Both IPXpress CPLANE and DPLANE of NPU link the library which contains
separate utility source files in c library format besides these utility IPXpress also uses NHAL
as libCommon, libIO, libEvent for other EAST component interoperability.

1. Memory management[Service Component] In these utilities we have wrappers

for allocating, aligning memory in 32bit intel platform and 64bit cavium platform.
Various utilities are malloc, memalign, free, fpa pool, avl tree data structure, hash
generation and look up etc.

2. Network Management[Service Component] These utility Provides the various

interface of the sub components like C-Plane and D-plane as ICD incase of Cavium
and net-link socket incase of Intel and NF_HOOK utility for kernel, UDP Checksum, IP
Checksum. This utility also provides the wrapper facility to convert various host to
network and network to host format in LITTLE_ENDIAN and BIG_ENDIAN format.
The 16 bit UDP heard checksum and 32 bit IP header checksum calculation wrapper
utility is also there.

3. Timer Management[Service Component] This utility provides the wrapper for

Cavium Hardware and Linux kernel timers. The utility provides the timer operations
and timeout handler functionality through call back function registration.

4. Log Management [Service Component] This utility provides the Logging

functionalities for C-plane and D-plane and a framework for the Linux proc file
system.

5. Status Management[Service Component] This utility collects various system

statistics like CPU core status, Ethernet status and the memory usage status for both
Cavium SimpleEx and Linux.

6. Utils[Service Component] Various system utilities like IP addition to system,

route addition to system and address validation etc.

7. Service[Service Component] This is the additional service provided by NPU

hardware which provides DHCP IP address to the External data generator H/W like
Shenick. It also provides the telnet client interface with the Shenick.

4.1.4 EAST Services Subsystem

The EAST Services layer resides on top of the Adaption Layer and some times access
platform layer and provides various services to all EAST applications.

Proprietary and Confidential 23

 EAST Architect Document v1.0

4.1.4.1 Protocol Server

This ss-system is categorized in to various protocol services which provide functionality
one protocol layer or a stack of multiple protocol layers emulating a complete solution based
on a specific technology.

1) MTP3AdaxServer: [Internal Component]

MTP3Server is a simulation tool that simulates the Message Transfer Part 3 in SS7
network. This tool helps in testing of different functionalities in SS7 network. It is used to
simulate Signal Transfer Point (STP) as well as the Service Switching Points (SSP) in SS7
network. MTP3Server is designed to run in LINUX environment only (RedHat Linux 9.0 and
RHEL 4.5). This product supports basic features like the load sharing, maintenance
message handling etc as well as it supports the Network management functions like
change over, change back and management inhibition.

MTP3Server depends upon the following Service modules and Internal modules:

Serviece Modules:
a. Platforms/libNetwork
b. Platforms/libEvent
c. Platforms/libIo
d. Platforms/libCommon
e. Platforms/libProtocol
f. platforms/libSecurity
g. platforms/seqChecker
h. platforms/libXMLParser
i. servers/utran/libUtranCommon
j. servers/utran/common
k. servers/utran/libLoadGen

Internal Modules:
l. servers/utran/libMtp3common
m. servers/utran/libTALI
n. servers/utran/mtp3common
o. servers/utran/mtp3
p. servers/utran/libMTP2Adax

2) SS7 Conformance Server: [Internal Component]

The EAST MTP2 and MTP3 Conformance server is intended to be used to verify
that a SS7 device is compliant with the SS7 MTP2 and MTP3 protocols. Test Cases are
provided for each Test Case defined within the ITU-T Q.781 and ITU-T Q.782 Test
Specifications. It requires a single 4-port SS7 board to verify SS7 low speed (56Kbps or
64Kbps) links and also for High Speed Links (2Mbps) for the MTP2 Tests. Two 4-port
SS7 boards are required for High Speed Links for the MTP3 Configuration B Tests.

The SS7 Conformance Server relies on the following Service and Intarnal Modules:

Proprietary and Confidential 24

 EAST Architect Document v1.0

Service Modules:
a. Platforms/libNetwork
b. Platforms/libEvent
c. Platforms/libProtocol
d. Platforms/libIO
e. Platforms/libCommon
f. Platforms/libIpc
g. Platforms/libTCPConn
h. Platforms/libLiS
i. servers/utranlibTALI_conf
j. Platforms/libSecurity

Internal Modules:
k. libMTP2Adax_conf
l. libSS7Conformance
m. libMTP3Conformance
n. libMTP2Monitor
o. libMTPConformMsg
p. libMTP2Stack
q. libCapture
r. libSS7Filter
s. libSS7Msgs
t. libMTP3_conf
u. libMTP3Common_conf
v. libMTP3_conf
w. libUtranCommon_conf
x. libMTP3Common_conf
y. libATMDriver_conf

3) NMS-ISDN: [Internal Component]

This Component is the interface for communication between EAST and NMS DSP using ISDN
signaling protocol.

This executable dependent upon the following modules:

Service Modules:
a. Platforms/libProtocol
b. Platforms/libEvent
c. Platforms/libIO
d. Platforms/libCommon

Internal Modules:
e. NMS Library

4) NMS-Voice [Internal Component]

This Component is the interface for communication between EAST and NMS DSP which
basically facilitates the Play/Record of Wav file and also DTMF Generation/Detection.

This executable dependent upon the following modules:

Proprietary and Confidential 25

 EAST Architect Document v1.0

Service Modules:

a. Platforms/libVoice
b. Platforms/libEvent
c. Platforms/libIO
d. Platforms/libCommon

Internal Modules:
f. NMS Library

5) Dialogic Voice Server: [Internal Component]

This Component is the interface for communication between EAST and Dialogic Analog
card which basically simulates the Analog phone.

This component dependent upon the following modules:

Service Modules:

a. Platforms/libEvent
b. Platforms/libIO
c. Platforms/libCommon
d. Platforms/protcols

Internal Modules:
e. Platforms/libVoice
f. Dialogic Library

6) ISDN Server: [Internal Component]

This Component is the interface for communication between EAST and Dialogic ISDN
card which basically simulates the ISDN signal.

This executable dependent upon the following modules:

Service Modules:

a. Platforms/libEvent
b. Platforms/libIO
c. Platforms/libCommon
d. Platforms/protcols

Internal Modules:
e. Dialogic Library

7) RTPServer: [Internal Component]

The RTP server integrated with EAST can transmit or receive RTP packets over UDP,
providing support for the transport of real-time data such as audio and video streams. It
creates an RTP session between RTPServer and a network entity that has the capability of
RTP data stream communication. It also monitors voice quality of on going session and
provides statistics related to it. In order to get better performance and to transmit or
receive more number of packets per second, packet generation and reception is supported
in Linux kernel space.

Proprietary and Confidential 26

 EAST Architect Document v1.0

This component is dependent upon following modules:

Service Modules:

a) platforms/libEvent
b) platforms/libIO
c) platforms/libCommon
d) platforms/libProtocol
e) platforms/libNetwork
f) platforms/libVoice
g) platforms/libXMLParser
h) platforms/libLicense

Internal Modules:
i) Telchemy’s VqMon Library
j) VoiceAge Library
k) NMS Library
l) Commetrex’s T.38 Fax Library
m) Servers/rtp/CodecConverter
n) Servers/rtp/log

8) PESQServer: [Internal Component]

PESQ stands for "Perceptual Evaluation of Speech Quality". PESQ are used to analyze
the distortion that has occurred on test voice signals that have been transmitted through a
VoIP network, and to produce an estimated MOS score. The PESQServer can perform the
speech or audio quality measurement for two input files, reference file and degraded file
with PESQServer. PESQ score is the comparison between two files: reference and degraded,
the objective is to test the quality of a codec. It uses OPTICOM PESQ OEM library (supplied
by Opticom). It reads speech data from files (Reference file and degraded file) to data
vectors, calculates the statistics, and provides a result which is the measurement score for
the degraded file.

Service Modules:
a) Platforms/libNetwork
b) Platforms/libEvent
c) Platforms/libIO
d) Platforms/libCommon
e) Platforms/libProtocol
f) Platforms/libLicense
g) Platforms/libXMLParser
h) Servers/rtp/log
i) Servers/rtp/CodecConverter

Internal Modules:

Proprietary and Confidential 27

 EAST Architect Document v1.0

j) Optcom’s PESQ Library

k) VoiceAge Library

9) ATMDriverProgram: [Internal Component]

The ATM Driver is a software program that serves as a high-level API to the ATM board.
This software runs on VxWorks or Linux platform. This program is responsible for
communication between the host (UTRANServer) and the ATM board. The host
communicates to the ATMDriverProgram through TCP/IP. This driver is responsible for
sending and receiving packets on the ATM board. Host can send various commands to the
ATMDriverprogram and different stacks can be created for different PVCs (permanent
virtual circuit).

Also ATMDriverProgram is supported for “Voice verification” with NMS.

Service Modules:

a. platforms/common
b. platforms/common
c. platforms/security
d. platforms/security
e. platforms/io
f. platforms/io
Internal Modules:

g. servers/atmmessage
h. servers/atmmessage
i. servers/utran/common
j. servers/utran/common

For Voice Verification

k. platforms/event
l. platforms/event
m. servers/rtp
n. servers/rtp
o. servers/rtp/nms
p. servers/rtp/nms
q. servers/rtp/log
r. servers/rtp/log
s. servers/voice
t. servers/voice
u. servers/libIPCNDriver
v. servers/libIPCNDriver

10) IPCNDriverProgram: [Internal Component]

Same as ATMDriverProgram.

11) IPCNISDNInterface: [Internal Component]

This Server used to test ISDN bearer traffic. The IPCNISDNInterface uses the
following:

Proprietary and Confidential 28

 EAST Architect Document v1.0

Service Module:
a. libCommon
b. libEvent
c. libIO

12) UTRANServer/SigtranServer: [Internal Component]

The 3G Network is divided broadly into different interfaces such as Iub, Iur, Iu-PS and Iu-
CS. These interfaces are again subdivided into planes such as control plane, transport
control plane and user plane. The control plane uses ATM Adaption Layer 5 whereas the
user plane uses ATM Adaption Layer 2. The only difference being in Iu-PS user plane
which, uses AAL5 layer as the lower layer. UTRANServer supports all the described
interfaces for the majority of the planes in two different loads. One is called AAL5 and
another one AAL2, with AAL5 load handling all the control planes along with the Iu-PS user
plane and AAL2 handling the remainder of the user planes.

Also SIGTRAN Protocols are an integrated part of UTRANServer. SS7 has been the tried
and true signaling mechanism for providing signaling in traditional PSTN networks. But
with voice-over-IP (VoIP) becoming a more important technology for carriers, carriers are
starting to look for more IP friendly signaling schemes to use in their network
architectures. SIGTRAN developed by the Internet Engineering Task Force (IETF), the
Sigtran protocol suite lets operators carry SS7 signaling traffic between a signaling
gateway (SG) and a media gateway controller (MGC) or IP-enabled signaling control point
(IP-SCP), thus allowing carriers to maintain their SS7 signaling schemes while being able
to tap into the IP network for transport. SIGTRAN is a suite of networking protocols
consisting of Stream Control Transport Protocol (SCTP) and a set of user Adaption (UA)
layers (which transform the look and feel of SCTP into the lower layers of SS7).
UTRANServer supports SIGTRAN protocols like SCTP, M3UA, IUA, SUA and M2PA.

Service Modules:

a. platforms/common
b. platforms/event
c. platforms/io
d. platforms/protocol
e. platforms/network
f. platforms/security
g. platforms/libXMLParser
h. platforms/libBERPRBS
i. servers/atmmessage
j. servers/atm/driver
k. servers/atm/pvc
l. servers/utran/common
m. servers/utran/libLoadGen
n. servers/utran/libTALI
o. servers/libPacketGen
p. servers/PacketServer
q. servers/libPacketDevice
r. servers/utran/mtp3common

Proprietary and Confidential 29

 EAST Architect Document v1.0

Internal Modules:

s. servers/utran/libLTEPDCP
t. servers/utran/aal2
u. servers/utran/iuup
v. servers/utran/sigtran/common
w. servers/utran/sigtran/m3ua
x. servers/utran/sigtran/iua
y. servers/utran/sigtran/sua
z. servers/utran/sigtran/sctp
aa. servers/utran/udp
bb. servers/utran/ip
cc. servers/utran/llc
dd. servers/utran/snap
ee. servers/utran/atmarp
ff. servers/utran/icmp
gg. servers/utran/gtp
hh. servers/utran/mtp3
ii. servers/utran/mtp3b
jj. servers/utran/aal5
kk. servers/utran/ethernet
ll. servers/libPacketCodec
mm. servers/utran/sigtran/m2pa
nn. servers/utran/server

13) BMServer: [Service Component]

There are synchronization issues while trying to run load test cases using EAST tool
where we simulate the User Equipment at the call originating end and terminating end
points. In order to overcome these issues, a BearerManager Server (i.e., BMServer) has
been designed. Bearer capabilities of the originating, terminating, OLCM/ Conference end
points are sent to the BMServer. Depending on the bearer capabilities that are received
from the originating and terminating end points, the BMServer decides the media
capabilities of the call.

The BMServer component depending upon following modules:

Service Modules:
a) Platforms/libCommon
b) Platforms/libIO
c) Platforms/libNetwork
d) Platforms/libProtocol
e) Platforms/libEvent
f) libXMLParser
g) libLicense
h) libUtranCommon
i) libTCP

14) GnServer/GTPServer: [Internal Component]

Proprietary and Confidential 30

 EAST Architect Document v1.0

This is used to in between SSGN-GGSN interface and main motto of this component is to
provide all the functionalities of Gn interface. This includes both GTP-C and GTP-U of Gn
interface.
The GnServer component dependents upon following modules:

Service Modules:

a. Platforms/libNetwork
b. Platforms/libEvent
c. libCommon
d. libProtocol
e. libIO
f. libPacketCodec
g. libPacketDevice
h. libPacketGen
i. libUtranCommon
j. libATMMessage

Internal Modules:

k. libETH
l. libGtp

15) PMIPServer: [Internal Component]

The PMIPSever is used for supporting PMIPv6 protocol stack. PMIPServer appends
PMIPv6 header (and IPv6 header if IPv4 connection is used) on PMIPv6 signaling packets
received from test case and sends those packets to PMIPv6 peer. It removes PMIPv6 header
(and IPv6 header if IPv4 connection is used) from the PMIPv6 signaling packets received
from PMIPv6 peer and delivers it to test case. It can generate tunneled data with format Eth
+ IP + GRE + IP + data. Both IPv6 and IPv4 data generation is supported. IPv6 over IPv4
GRE data generation is supported in PMIPv6.

The PMIPServer component dependents upon following modules:

Service Module:
a) libProtocol
b) libUtranCommon
c) libETH
d) libIO
e) libGRE
f) libPacketDevice
g) libPacketGen
h) libPacketCodec
i) libCommon
j) libEvent
k) libNetwork
l) libBERPRBS
m) libpcap
n) libpthread
o) libLicense

Proprietary and Confidential 31

 EAST Architect Document v1.0

p) libXMLParser
q) libsctp

Internal Module:

16) SCTPServer: [Internal Component]

Previously SCTP was designed for SIGTRAN for its transport layer which was a
component of UTRAN/SigtranServer. Later due to usage of SCTP as LTE signaling transport
and high performance requirement a separate Linux kernel based SCTP server was
developed to have SCTP services of Linux. This SCTP Service has external services as well
as integrated with load engine. The external server has Requced Resource functionality for
DIAMTER protocols.

The SCTPServer component dependents upon following modules:

Service Module:
a) libCommon
b) libProtocol
c) libIO
d) libEvent
e) libNetwork
f) libXMLParser
g) libSecurity
h) libLicense
i) libeSCTP

17) LoadGen: [Internal Component]

The LoadGen is a library that allows generating sample Sequence data with a repeating
message to test the capability of a particular stack to achieve higher data rates than they
could with the LoadRunner alone. The current LoadGen feature is supported on the
following protocol stacks:

MTP3/MTP2
M3UA/SCTP/IP
M2PA/SCTP/IP
SUA/SCTP/IP
MTP3b/SSCF-NNI/SSCOP/AAL5/ATM
Service Module
a. source/servers/utran/common
b. source/servers/utran/mtp3
c. source/servers/utran/mtp3common
d. source/servers/utran/sigtran/m3ua
e. source/servers/utran/sigtran/sua
source/servers/utran/sigtran/m2pa
f. source/servers/utran/sigtran/common
g. source/servers/utran/mtp3

Proprietary and Confidential 32

 EAST Architect Document v1.0

h. source/servers/utran/mtp3b
i. source/servers/utran/mtp3common
j. source/servers/utran/aal5
Internal Module:
j) libLoadgen
k) libMtpLoadGen

18) IPSecServer:

It provides a set of cryptographic protocols that provide interoperable, cryptographically-

based security for IPv4 and IPv6. IPSec has two key security protocols:
a) Encapsulating Security Payload (ESP) which provides authentication, data
confidentiality and message integrity.
b) Authentication Header (AH) that provides authentication and message integrity.
IKE (Internet Key Exchange) is the key exchange protocol for both ESP and AH. IPSec
Server is designed to run on top of IKE stack to provide IPSec functionalities.

The IPSecServer component depended upon following modules:

Service Modules:

a) libCommon
b) libEvent
c) libNetwork
d) libIO
e) libSecurity
f) libXMLParser
g) libLicense

Internal Module:
h) XpressVPN library

19) GbServer:

Gb interface is between the BSS and SGSN (as shown below). Signaling and Data
transmission can take place using either Frame Relay or UDP/IP. The common entity within
the GB Interface is the Network Service Virtual Connection Identifier (NSVCID). The
NSVCID can associate with the DLCI (srcDLCI/dstDLCI) for Frame Relay and UDP (srcIP,
dstIP) for IP transmission.

b. server/GbServer
c. servers/libGbServer
d. servers/libGbStats
e. servers/libGbDebug
f. servers/libGbStatsVisitor
g. platforms/protocol
h. platforms/network
i. platforms/event
j. platforms/io
k. platforms/common
l. platforms/libBERPRBS
m. servers/utran/common

Proprietary and Confidential 33

 EAST Architect Document v1.0

n. servers/utran/ethernet
o. servers/libPacketCodec
p. servers/libPacketDevice
q. servers/libPacketGen
r. servers/PacketServer
s. external/linux/GbStack/libBSSStack
t. external/linux/GbStack/libSGSNStack
u. external/linux/GbStack/libCommon

4.1.4.2 IPXPress ss-system

IPXpress ss-system which is basically designed to provide high scale IP based protocol
transport services. This framework provides higher scale IP based Tunneling and Data
Generation services for EAST bearer testing. The IPXpress framework was initially designed
to use the Octeon based Network Processor MIPS64 H/W and intel32 based kernel solution.

1) IPXpress-Framework: [Service Component]

Currently the H/W component of NPU for OCTEON is of CN38XX model. The key components
are described below.

- IPXpress is a generic framework for data generation and transport should be laid out
and Common Control interface should be provided towards EAST to access to the
different services.
- The Inter-module transmission is only IP based only.
- Octeon multi core architecture is based on MIPS64 which uses Cavium SDK as a cross
compiler for its binaries.
- All the applications functionality is divided into c-plane and d-plane and are executed in
multiple cores of NPU H/W all the time in order to take advantage of multiple cores.
- The NPU H/W has both AMC (from Radisys AMC7211) and PCI-X (Cavium) form factor
cards. The AMC H/W has 12 cores and the PCI contains 16 cores and the number can
vary from model to model. The 1st 2nd cores will be used for control plane and rest of the
cores will be used for data plane.
- The IPXpress sub system has Control plane and data plane. The control plane interacts
with the NPUAL sub system through socket and ICD interface. ICD stands for Inter Core
Communication Driver and it is used to send/receive data to/from data plane. The data
plane interacts with the NPU AL sub system through the socket or POW interface.
- Various IP based protocols simulation can use the IPXpress framework such as IPSec,
GTP, GRE, PRBS, RTP FTP, HTTP etc. The following Application modules are currently
supported in IPXpress.

The Following are the modules of IPXpress Framework.

1. DNI (Direct Network Interface)
2. ICD (Inter core Communication Driver)
3. RE (Routing Engine)
4. PKO (Packet Output)
5. PKI (Packet Input)

The following are the IPXpress applications supported.

a. IPXpress-RTP: [Internal Component]

Proprietary and Confidential 34

 EAST Architect Document v1.0

RTP module is responsible for creating concurrent RTP Sessions and generating RTP
packets based on various codec, It interact with the RTPQA to calculate the MOS
statistics.
b. IPXpress-PRBS: [Internal Component]
PRBS module is used to create PRBS sessions generate a pseudo random bit pattern
which is used to test integrity of any protocol layer basically the radio interface and
come back to itself and then do a comparison to calculate the loss in the radio interface.
Also it will be used to generate continuously to do the synchronization. Various Noise
insertions techniques can be used to verify the layer under test.
c. IPXpress-Shenick: [Internal Component]
Shenick is an external DataGen H/W used to generate a bit patterns based on support
stateful and stateless sessions. It provides the FTP and HTTP application data generation
over GTP used for bearer testing.
d. IPXpress-GTP: [Internal Component]
GTP module is used to create the GTP tunnels, the IP based data bearers used to
provide PDP context and EPS bearer for LTE. The GTP tunnels are used for filtering and
transmitting data based on TFT filters either generated by the internal data gen modules
or external data generator.
e. IPXpress-IPSec: [Internal Component]
IPSec module provides the IP Security and Integrity both in transport and Tunnel mode.
This is used for transmitting Signalling data over secured IP based tunnels. The module
provides both IKE based signaling for creating Security associations and data
transmission.
f. IPXpress-PMIP/GRE: [Internal Component]
PMIP/GRE module is used to create the GRE tunnels, another IP based data bearers used
to EPS bearer in LTE and CDMA. The GRE tunnels are used for transmitting data either
generated by the internal data gen modules or external data generator. The respective
PMIP based Signaling are also handled by this modules

4.1.4.3 DataGenerator ss-system

1) PacketGenerator: [Service Component]

This is used to generate bearer data service. Its main tasks are to calculate the
round-trip delay, data rate, data loss rate, and periodic successes/failures, etc. The
PacketGenerator dependent upon following modules:

Service Modules:

a. Platforms/libNetwork
b. Platforms/libEvent
c. Platforms/libCommon
d. Platforms/libProtocol
e. Platforms/libIO

Internal Modules:
f. libPacketCodec
g. libPacketGen
h. libPacketDevice
i. libUtranCommon

2) PacketServer: [Service Component]

Proprietary and Confidential 35

 EAST Architect Document v1.0

This component is used for data generation services to various Protocol Servers. These
include Sequenced packets, Dummy or Pseudo Noise Data and various codecs data
Generation. These services are basically embedded inside the protocol services to test
various bearer capabilities of the interface.

This component is dependent upon following modules:

Service Modules:

a. Platforms/libNetwork
b. Platforms/libEvent
c. Platforms/libCommon
d. Platforms/libProtocol
e. Platforms/libIO

Internal Modules:

f. libPacketCodec
g. libPacketGen
h. libPacketDevice
i. libUtranCommon

4.1.4.4 Licensing sub subsystem

1) EAST Licensing:
A. libLicense [Service Module]: License interface library to the LicenseServer. The
libLicense subsystem requires the following:
A. libCommon
B. libIO
C. libXMLParser
B. LicenseServer [Service Component]: Handles the licensing for the EAST system.
The LicenseServer requires the following modules:
Service Module:
A. libCommon
B. libEvent
C. libIO
D. libXMLParser

2) EAST License Generator[Internal Component]:

This id used for generating EAST License key depending up on different License type.
This is a web application and used need to Login before accessing this application. EAST
License is generated based on System MAC address.

4.1.4.5 Security:
This sub sub-system supports encryotion and authentication alogorithm.
a. EAP [Service Component]
This Component is handing authentication using EAP.
The EAP is dependent upon following modules:

a. platforms/common/libCommon
b. platforms/security/libSecurity

Proprietary and Confidential 36

 EAST Architect Document v1.0

b. SSL [Service Component]

This Componet is used to send data in encrypted format.
The SSL is dependent upon following modules:

a. platforms/netork/libNetwork

c. Snow3g [Service Component]

This component used to generate Integrity key and ciphered text for LTE.
a. platforms/common/libCommon
b. platforms/security/libSecurity

d. MILENAGE [Service Component]

This component used for Authentication for UMTS.
a. platforms/common/libCommon
b. platforms/security/libSecurity

4.1.4.6 CLI
1. CLIv1 [Internal Component]

This Component is handling CLI in EAST. This is the EASTCLI v1, which supports non-
MUMB mode of script/profile execution in EAST.

The CLI v1 is dependent upon following modules:

Service Modules:
a. libIO
b. libCommon
c. libLogs
d. libEvent
e. libNetwork

2. CLIv2 [Internal Component]

This Component is handling CLI in EAST. This is the EASTCLI v2, which supports both
MUMB and non-MUMB mode of script/profile execution in EAST.

The CLI v2 is dependent upon following modules:

Service Modules:
a. libIO
b. libCommon
c. libLogs
d. libEvent
e. libNetwork
f. libProtocol

4.1.4.7 Event

Proprietary and Confidential 37

 EAST Architect Document v1.0

1) EventServer [Internal Component]: Handles the majority of packet delivery

between EAST processes. The EventServer has a well-known TCP/IP server socket
(configured in desktop.dos) that listens for connection requests. An EAST application
can connect to the EventServer, and subscribe for certain messages (events). When the
EventServer receives a message from another EAST application, all applications
subscribed for that event will receive it. The EventServer relies on the following:
Service Module:
a) libCommon
b) libEvent
c) libIO
d) libProtocol
e) libNetwork

2) libEvent [Service Module]: The Event library used by applications to

publish/subscribe with the EventServer. This provides an interface (Notice object) that
can be populated with user data, serialized, then sent across a TCP/IP connection to the
EventServer, which will then deliver it to the appropriate subscribers. The libEvent
subsystem requires the following:
Service Module:
a) libCommon
b) libIO

4.1.4.8 Database
Used to store EAST specific system data and also EAST user specific data. EAST
supports MySQL, MSAccess and own flatfile databases. EAST uses JDBC-ODBC database
connectivity for database operations. Also used for report generation. (It is a Java
application.)

4.1.4.9 Process [Service Component]

Used to control other processes. Handles launching, stopping, and returning exit status

4.1.4.10 Command [Service Component]

Used to handle some Command TIO requests. For example, telnet requests can be serviced here.

4.1.4.11 Resource [Service Component]

Reads the DynamicsResourceConfig file, and handles requests from clients for resources. It
reads the config file and stores resources in a map. These resources are moved to an available
map as they become available for use. When a client requests that resource, it gets moved to
a used map until freed. The ResourceServer relies on the following:
Service Modules:
a.) Platforms/libCommon
b.) Platforms/libEvent
c.) Platforms/libIO

Proprietary and Confidential 38

 EAST Architect Document v1.0

4.1.4.12 Logging [Service Component]

Used to store the execution log for Protocol servers and Load engine

4.1.4.13 Codec [Service Component]:

This is used to convert Audio codec from one format to another format.

4.1.4.14 Compression [Service Component]:

Used for compression of signaling message i.e. SIP

4.1.5 EAST Core Subsystem

This sub system is the foundation of EAST. All product lines uses this sub-system for GUI based
test case development, generating desired calls, managing protocol server, loggings, licensing
and protocol based message encoding an decoding .

4.1.5.1 Desktop ss-system

1) Server Buttons[Internal Component]: Used to represent the status of a server. The
status can be seen as follows
a. If the server is running then the color will be green.
b. If the server is down then the color will be red.
c. If the server is not started then the color will be yellow.

This is a Java application.

2) License Verification[Service Component]: This module is used to verify EAST

License for different Component and “Users” of EAST.
3) User Management[Internal Component]: Used to manage User/Group concept in
EAST. This is a Java application.
4) Launcher[Internal Component]: This executable used to invoke EAST Desktop. This
is a C++ application.
5) Exception/Error Management[Internal Component]: Used to see an Exception or
any other fatal error in EAST. Uses basic error and out put stream of the EAST
applications. These errors can be seen from EAST desktop as well as from EAST log files.
6) XML Parser[Service Component]: This component is used to parse XML files used in
EAST.

4.1.5.2 Logic Editors ss-system

1) TC Editor[Internal Component]: Used to create and generate graph file and scripts,
describing the execution to be followed by the LoadEngine. This is a single Java
application. This can be used as main script for starting Runner and Load engine.
This is a Java application.

2) TLP Editor[Internal Component]: Used for modular test case design. Once created
can be used by all the editors.

Proprietary and Confidential 39

 EAST Architect Document v1.0

This is a Java application.

3) TLT Editor[Internal Component]: Used for threaded test case design. Once created
can be used by other editors except TLT editor.
This is a Java application.

4) TS Editor[Internal Component]: Used to execute multiple test cases. This can be

used as main script for starting Regression TS Runner and Load engine. Used for batch
mode testing.
This is a Java application.

5) Referance Editor[Internal Component]: Allows a user to create a TIO which can

then be referenced across multiple TCs/TLPs/TLTs. This is a Java application
This is a Java application.

4.1.5.3 Message Editors ss-system

1) Binary Message Editor[Internal Component]: Used to create protocol messages
based on BCD encoding/decoding rules. For example, used to create DIAMETER, IS41,
ISDN, ISUP message etc. This is a Java application

2) ASCII Message Editor[Internal Component]: Used to create protocol messages

based on ASCII encoding rule. For example, used to create an MGCP, SIP, MEGACO,
SIPT, HTML, or XML-based messages. This is a Java application

3) PER Message Editor[Internal Component]: Used to create protocol messages based

on ASN1 PER encoding/decoding rules like S1AP, RANAP etc. This is a Java application.

4) BER Message Editor[Internal Component]: Used to create protocol messages based

on ASN1 BER encoding/decoding rules like CAP, MAP etc. This is a Java application.

4.1.5.4 Database Editors ss-system

This Used to create Database Tables. It connects to configured database create table
and also populate data in the table. It consists of TIOs for defining table name, column
name and type. EAST supports INTEGER, VARCHAR column types. This is a java application.

4.1.5.5 Engine ss-system

1) Script Parser[Internal Component]: Parses the generated script (by TC/TLP/TLT/TS

editors), initialize various objects to be used for script execution.

2) Template Parser[Internal Component]: Parses the generated templates (by ASCII,

Binary, ASN1PER, ASN1BER editors), initialize various message objects used for script
execution.

Proprietary and Confidential 40

 EAST Architect Document v1.0

3) Engine Framework[Internal Component]: Main frame work to manage/execute

commands, state-machines, contexts and different state of execution.
The LoadEngine is the driving force behind EAST, and the basis of the EAST system.
Basically, it translates test cases created by the user into a series of instructions, and
sends messages for transmission to the customer SUT (via the appropriate
ProtocolServer). It also handles decision-making for incoming messages from the SUT
as to future actions. The LoadEngine handle statistics and peg counts, as well as logging
to describe the current action. The LoadEngine itself is made up of several modules.

The LoadEngine is dependent upon following modules:

Service Modules:
a. Platforms/libIO
b. Platforms/libCommon
c. Platforms/libEvent
d. Platforms/libNetwork
e. Platforms/libProtocol
f. Platforms/libsecurity
g. Platforms/libdynamicsigcomp
h. Platforms/libXMLParser
i. Platforms/libLicense
j. Platforms/libSigComp
k. Platforms/libLogs
l. Platforms/libThreads
m. Servers/libTCP
n. Servers/libeSCTP

Internal Modules:
o. libAdmin
p. libDatasource
q. libDb
r. libDLLIinterface
s. libServerClients
t. libber
u. libascii
v. libasn
w. libload
x. libEap
y. libbinary
z. Osal/libosal.lib

4) Binary Encode/Decode[Internal Component]: Part of the LoadEngine. Handles

encoding and decoding Binary-based messages like BCD, ASN1PER, ASN1BER.
Service Modules:
a. platforms/common/libCommon
b. applications/load/db/libDb
c. applications/load/DLLiInterafce/libDLLInterface
d. platforms/io/libIO
e. applications/load/common/libLoad
f. platforms/logs/libLogs
g. platforms/protocol/libProtocol

Proprietary and Confidential 41

 EAST Architect Document v1.0

Internal Modules:
h. applications/load/asn/libAsn
i. applications/load/ber/libBer
j. applications/load/binary/libBinary

5) ASCII Encode/Decode[Internal Component]: Part of the LoadEngine. Handles

encoding and decoding ASCII-based messages.
Service Modules:
a. applications/load/asn/libAsn
b. applications/load/binary/libBinary
c. platforms/common/libCommon
d. applications/load/db/libDb
e. applications/load/DLLiInterface/libDLLInterface
f. platforms/io/libIO
g. applications/load/common/libLoad
h. platforms/logs/libLogs
i. platform/protocol/libProtocol
Internal Modules:
j. applications/load/ascii/libAscii
k.

6) Event Handling[Internal Component]: Part of load engine, used for message

handing from Network Ports, Eventserver (from protocol server, utility servers)
Service Modules:
a. applications/load/asn/libAsn
b. applications/load/binary/libBinary
c. platforms/common/libCommon
d. applications/load/db/libDb
e. platforms/io/libIO
f. platforms/logs/libLogs
g. platform/protocol/libProtocol
h. servers/tcp/libTCP
i. platforms/network/libNetwork
j. osal/libosal

Internal Modules:

k. applications/load/common/libLoad
l. applications/load/serverclients/libServerclient
m. platforms/sigcomp/libsigcomp
n. platforms/dynamicsigcomp/libsigcportlayer
o. platforms/dynamicsigcomp/libdynamicsigcomp
p. applications/load/DLLInterface/libDLLInterface

7) Variable Management[Internal Component]: Manages local, global, context and

argument variables.

8) TS/TLP/TLT Execution[Internal Component]: If the user decides that a particular

sequence of logic can be reused in multiple Test Cases, they have the option of using
the TLP Editor to create a Test Logic Procedure. This is similar to writing a method or
procedure in a programming language, as opposed to replicating the same code in every
place that it’s needed. This makes the Test Case easier to maintain and modify, since
updating a single TLP will affect all areas that the TLP is called. Much like the TC Editor,

Proprietary and Confidential 42

 EAST Architect Document v1.0

the TLP Editor saves the TLP itself in the tlp/graphs directory with the “.tlp” extension,
and generates a “.script” file in the tlp/scripts directory. The LoadEngine can then read
the script file and process it as needed.

9) Execution Status[Internal Component]: Logs, Statistics, event view, graph view,

TIO view, CDR.
a. libLoad
b. libLogs
c. libAdmin
d. libIO
e. libCommon

4.1.5.6 Log Viewer ss-system

1) Server Log Viewer: Used to view logs of protocol servers.

2) Regression Log Viewer: View the offline logs of Test Cases, Test Suites, and the
Regressions Load Runner log. This is a Java application.

3) Load Log Viewer: View the offline logs generated in LoadTC Runner and Traffic Runner.
This is a Java application

4.1.5.7 Runners ss-system

1) TC Runner[Internal Component]: Test Case Runner. Used to execute a Test Case.

This is a Java application.
2) TS Runner[Internal Component]: Test Suite Runner. Used to execute Test Suites.
This is a Java application.
3) Regression Load Runner:
4) Load TC Runner[Internal Component]: Load Test Case Runner. Used to execute a
load test This is a Java application.
5) Admin Tunner: [Internal Component]
Allows the user to run the Test Case on multiple boards from a single location. This
is useful for MUMB configurations where the user may want to drive a test across multiple
boards in a chassis. Note that some functionality here (board reservation, etc) has
migrated to the Board Administration application. This is a Java application.
Server Modules:
a. platforms/libCommon
b. platforms/libLogs
c. platforms/libIO
d. platforms/libNetwork
e. platforms/libProtocol

Internal Modules:
f. libLogger
g. libEvent
h. libNetwork
i. libLoad
j. libDLLInterface

Proprietary and Confidential 43

 EAST Architect Document v1.0

4.1.5.8 Reporter ss-system

1. Test Reporter: Handles reporting detailed information of executed Test Cases
and Test Suites. Keeps track of the TCs run, time of execution, whether the test was
completed, etc. This is a Java application

2. Run Reporter: Displays the Event Trace information in HTML format and offline
logs. This is a Java application

4.1.5.9 Scheduler ss-system

Used to schedule tasks, such as TS execution, etc. This is a Java application.

4.1.5.10 Admin Utilities sub subsystem

1. File Clean Up: Used to cleanup swap and log files. This is a Java application.

2. IP Address Generator: Used to create a number of Virtual IP addresses for the

system. This is a Java application.

3. File Backup: Used to take backups for Test Program (TC/TLP/TLT/TS/

Reference/Database), Log, Configuration, ASCII Library, binary Library or
Templates files. This is a Java application.

4. Update License Key: Used to update license key from EAST Desktop. This is a
Java application.

5. Package History: Used to displays all the packages installed in NetHawk EAST
through library installation. The packages build date and version information is
also displayed. This is a Java application.

6. Install
Library: Used to install the package libraries. This is a Java application.

Add-Ins: Used to install add-in applications apart from NetHawk proprietary

package libraries. Currently, TTCN-3 application is available as Add-Ins which
is one of the world’s leading testing application. This is a Java application.

Patch: Used to install the patch. This is a Java application.

7. Uninstall
Library: Used to uninstall the ASCII/Binary libraries. This is a Java
application.
Add-Ins: Used to uninstall add-in applications, which are installed through
EAST. This is a Java application.

8. CodecConverter: Used for PESQ when comparing quality parameters of source

and converted media files. This is a Java application.

9. Decoder: Used to analyze the dump data of all Binary and ASCII protocols
supported in NetHawk EAST. This also helps one to view the dump details for the
message and elements. This is a Java application.

Proprietary and Confidential 44

 EAST Architect Document v1.0

10. Script Import Export: Used for import/export the graphs, their generated files
and dependents. This is a Java application.

11. Script Difference: Used to check the difference between two graphs from one
version to another version. This is a Java application.

12. Multiple Database Configurations: Used to configure multiple databases for

EAST. This is a Java application.

13. DebugUtility: Helps in logging in and browsing remote Linux machine while
working in Windows. Many a times we come across several problems in Linux,
ATM and ISDN boards. In such situations, it is not enough to know just the status
of the servers running on the board and the status of the board itself, but we
need a mean to debug what’s going wrong on the boards, by executing some
commands on the board. Debug Utility functionality helps in providing interactive
session with the board. This utility establishes a session with the board, accepts
commands from users, and executes them on the board, displays the results at
the local utilities display panel. This is a Java application.

14. iPro: Used to capture network data for network analysis. This is a Java
application.

15. Patch History: Used to display the list of installed patch in EAST. This is a Java
application.

4.1.5.11 Test Management sub subsystem

1) Keyword Editor: Allow to add, delete and update the keywords used in EAST
environment. The keywords provide a suitable way of grouping Test Suites in different
Category: Choices and to explore the test suites more efficiently. Keyword is defined as
combination of Categories and Choices. Keyword management makes it easy to search
for a test program. This is a Java application.

2) Batch Builder: Using this feature many files can be grouped into a batch and user can
generate the scripts. This process consumes much less time compared to performing the
operation individually for each file. This is a Java application.

3) File Management: Allows managing files in File System & Database as well as provides
the facility to view the properties of a particular file. This is a Java application.

4.1.5.12 Installer/Uninstaller sub subsystem

1) Installer/uninstaller:

Proprietary and Confidential 45

 EAST Architect Document v1.0

EAST Software comes with an EastSetup.zip for Linux OS and an EastSetup.exe for
Windows OS.

User can install/uninstall EAST software in Windows and Linux OS mentioned below

In Windows OS
Installation: By double clicking on EastSetup.exe
Un-Installation: By selecting Uninstall option of Installed EAST software from
Program Menu.

In Linux OS
Installation: By executing setup.sh script after unzipped EastSetup.zip into a
specified location.
Un-Installation: By executing unistall.sh from installed EAST software.

This is a Java application.

2) Upgrade Installation: The upgrade installation, will attempt to establish a smooth

transition for the existing customer test cases, libraries, etc to function with the new
code base. For this Upgrade Installation option needs to be select during Installation.

This is a Java application.

3) Patch Upgrade: Used to install the patch. This is a Java application.

4.1.5.13 Configuration sub subsystem

This is used to configure the various ProtocolServers which test a SUT. Since the
ProtocolServers create links with the SUT, these links must be configured properly to
ensure that the link remains active and stable throughout the test. This application
allows the user to configure various parameters based on the protocol tested and the
type of link needed.

This is a Java application.

Proprietary and Confidential 46

 EAST Architect Document v1.0

5. Use Cases
A use case diagram in the Unified Modeling Language (UML) is a type of behavioral diagram
defined by and created from a Use-case analysis. Its purpose is to present a graphical
overview of the functionality provided by EAST system in terms of different Sub-systems,
their goals (represented asuse cases), and any dependencies between those use cases.

The main purpose of a use case diagram is to show what system functions are performed for
which Sub-systems/sub Sub-systems.

5.1.1 Configuration Management:

5.1.1.1 Installation of EAST:

Proprietary and Confidential 47

 EAST Architect Document v1.0

Figure 8 - Installing EAST Use Case Diagram

In the above Use Case, the EAST User will start the EAST Installation Wizard.

i) The Wizard will first display a Welcome screen, describing what the EAST installation will
do. When the EAST User clicks on the Next button, the Wizard prompts the EAST User
as to what kind of installation this will be (New/Upgrade).

ii) The Wizard will then display the Licensing Agreement between Nethawk Corporation and
the EAST User. If the EAST User does not accept this license, the Installation will exit.

iii) The Wizard then prompts the EAST User for their name and company information.

iv) The Wizard then prompts the EAST User for the IP Address and Network Interface for
the installation. This is needed for several configuration files and licensing information.

v) The Wizard then asks the EAST User for the desired location of the installation, and
calculates how much disk space will be needed, and how much there is at that location.

vi) The Wizard prompts the EAST User as to where any current environment files for EAST
are located.

vii) Next, the Wizard asks the EAST User if any existing libraries are already installed on this
machine. If so, the EAST User may point the Installation at those files.

Proprietary and Confidential 48

 EAST Architect Document v1.0

viii) The Wizard then asks if the EAST User wants the EAST Installation to create a
Program Folder for EAST.

ix) Next, the Wizard prompts the EAST User as to whether this installation will use flat files
or MySQL for a database. If MySQL is chosen, the EAST User is prompted for
configuration information.

x) The EAST User is then asked for a valid JRE for EAST to use. The EAST User will then
need to select a path to the appropriate JRE.

xi) The Wizard will then display a summary of the EAST User’s choices that were made so
far. The EAST User can then back up and change configuration information, cancel out,
or continue with the installation.

xii) The Wizard then has the appropriate EAST files installed in the selected locations, and
updates the configuration files as needed.

xiii) Finally, the Wizard displays a message stating that the installation has completed,
and gives the EAST User the opportunity to read this EAST version’s Readme file. At this
point, the installation exits.

5.1.1.2 Starting of EAST Desktop:

Proprietary and Confidential 49

 EAST Architect Document v1.0

i) To start EAST Desktop,EAST user will launch the start.sh script or execute Process,
usually found in the installation area, or in that particular user’s directory (depending on
type of Installation).

ii) The start.sh script will then setup some environment variables, and then launch the
EAST Desktop.

iii) The EAST Desktop will check if the EAST User is licensed to use the Desktop. If so, the
Desktop continues to run.

iv) Next, the EAST Desktop will launch any other servers needed (including the EventServer
and any other Protocol Servers, etc).

5.1.1.3 Checking EAST License:

Proprietary and Confidential 50

 EAST Architect Document v1.0

i) The EAST Java and C++ applications both will access EAST licenses. The EAST Java
Application will use the libJNILicense JNI library to interface with the C++-based
libLicense Subsystem, which is directly accessed by the EAST C++ Application.

ii) In both cases, the libLicense Subsystem will use the LicenseServer to determine if the
license is valid, and return the results to the appropriate caller.

5.1.2 Message Creation:

5.1.2.1 Create Message Template:

Proprietary and Confidential 51

 EAST Architect Document v1.0

i) The EAST User starts the Message Editor (Binary, ASN1 PER, ASN1 BER). The Message
Editor loads the messages and their related elements from the graphs/messages and
graphs/elements directories.

ii) Once the messages are modified, the Message Editor resaves them in the above
directories and files.

iii) Before the messages can be used in a script, the messages must be generated. Once
this is done, the messages are converted from their binary versions to ASCII versions
stored in the templates/messages and templates/elements directories. These then can
be accessed and loaded as part of a script.

5.1.3 Test Case Creation:

Proprietary and Confidential 52

 EAST Architect Document v1.0

5.1.3.1 Resource TIO:

1. The User first starts the Test Case Editor, and creates a Test Case. Then they add a
Resource TIO, and add in the target resources along with the local resource name.

2. This information is then generated into a script, and fed into the LoadEngine, which
parses it and configures its internal data accordingly.

3. When the Protocol Server starts up, it creates its Protocol Layers according to the
supplied Protocol Server configuration file. Once all of the layers are created, the
Protocol Server will register the individual Protocol Layer resource names with the
EventServer.

4. When the LoadEngine runs into a Transmit TIO (ASCII or Binary), it will use the
resource name as part of the message to send to the EventServer. The EventServer
receives the message, and determines who is subscribed for this particular resource.
The EventServer then sends the message to the Protocol Server.

5. The Protocol Server receives the message, checks what resource it belongs to, and
forwards the message to that Adaption Layer. At that point, the Protocol Layer
processes the message.

6. Note that the EventServer step is bypassed if the LoadEngine and Protocol Server are
connected directly, as opposed to going through the EventServer itself (P2P).

Proprietary and Confidential 53

 EAST Architect Document v1.0

5.1.3.2 Create Database:

1. When the EAST User needs to update or create a database, they start the Database
Editor.

2. The Database Editor works similar to the Message Editor and the Test Case Editor, in
that it works primarily with binary-based files until the user needs to generate
something usable by the LoadEngine, at which it produces ASCII data.

3. The Database Editor will read the binary graphs/db file to get the table data itself, while
the schema information and help text comes from the schemas/schema and
schemas/hlp2 directories. The user can then modify and edit these files.

4. When the database is complete, the user can generate the ASCII-based db and
signature files, which contain the table data and the schema information respectively.

Proprietary and Confidential 54

 EAST Architect Document v1.0

5.1.3.3 Create TestCase:

1. When the EAST User wants to create a test case, they first start the EAST Desktop.

2. From the EAST Desktop, the EAST User launches the Logic Editor. This starts in the TC
flavor, but can be changed during execution to handle TLPs, TLTs, or TSs.

3. Using the Logic Editor, the user will add TIOs for their desired test logic. If the user has
defined a TLP (or wishes to), they will add or edit that TLP.

4. If the user uses the Receive or Transmit TIOs, the editors read the graphs/messages and
graphs/elements files to construct that message internally.

5. If the user wants to add in a database, the editors read the graphs/db and schemas/schema
files.

6. Once the EAST User has created the desired test case, it is then saved into a graph file.

7. Finally, the EAST User selects the Generate functionality to convert the graph file into a
script file, which then can be read by the LoadEngine itself.

Proprietary and Confidential 55

 EAST Architect Document v1.0

5.1.4 Test Case Execution:

5.1.4.1 Transmit/Receive Message using UDPServer:

A. With External UDPServer:

i. The LoadEngine allows the EAST User to design a test case that transmits and
receives messages with the customer’s SUT.

ii. In this case, we examine how the LoadEngine and UDPServer work together
to send data using the UDP protocol stack to the customer’s SUT.

iii. In this case, we assume that the LoadEngine and UDP Server are
communicating via EventServer. When the LoadEngine needs to transmit a
message (via the ASCII Send TIO), the message is passed to the libEvent
module, which then passes it to the libIO module for serialization and
transmission over TCP/IP to EventServer.

iv. On receiving message, EventServer find appropriate EventConsumer and

deliver received message via libIO.

Proprietary and Confidential 56

 EAST Architect Document v1.0

v. The libIO/libEvent module on the UDPServer gets the message, un-serializes,

and passes it to the UDP Server. The UDPServer check appropriate resource
and delivered message to libNetwork.

vi. libNetwork module then transmit message to libIO. Then libIO delived
message to Customer SUT.

vii. To receive a message, the process is reversed, with the UDPServer receiving
the message on the UDP Protocol tack, passing it to the EventServer, which
then forwards it to the Load Engine.

B. With internal UDPServer in LE:

a. In this case, we assume that the LoadEngine uses inbuild UDP Server for transmit
messages over UDP Protocol stack. When the LoadEngine needs to transmit a
message (via the ASCII Send TIO), the message is passed to the libNetwork module
based on configured resource, which then passes it to the libIO module for
serialization and transmission over TCP/IP to Customer SUT.

b. To receive a message, the process is reversed.

5.1.4.2 Transmit/Receive Message using TCPServer:

Proprietary and Confidential 57

 EAST Architect Document v1.0

A. With External TCP Server:

i. In this case, we assume that the LoadEngine and TCP Server are
communicating via EventServer. When the LoadEngine needs to transmit a
message (via the Binary Send TIO), the message is passed to the libEvent
module, which then passes it to the libIO module for serialization and
transmission over TCP/IP to EventServer.

ii. On receiving message, EventServer find appropriate EventConsumer and

deliver received message via libIO.

iii. The libIO/libEvent module on the TCPServer gets the message, unserializes,
and passes it to the TCPServer. The TCPServer check appropriate resource
and delivered message to libTCP for encode header. After endocing header,
libTCP delived message to libNetowrk.

iv. libNetwork module then transmit message to libIO. Then libIO delived
message to Customer SUT.

v. To receive a message, the process is reversed, with the TCPServer receiving

the message on the TCP Protocol tack, passing it to the EventServer, which
then forwards it to the Load Engine.

B. With Internal TCPServer in LE:

Proprietary and Confidential 58

 EAST Architect Document v1.0

a. In this case, we assume that the LoadEngine uses inbuilt TCP Server for
transmit messages over TCP Protocol stack. When the LoadEngine needs to
transmit a message (via the Binary Send TIO), the message is passed to the
libTCP for encoding appropriate header. Then transmit message to libNetwork
module based on configured resource, which then passes it to the libIO
module for serialization and transmission over TCP/IP to Customer SUT.

5.1.4.3 Transmit/Receive Message using UTRANServer:

Proprietary and Confidential 59

 EAST Architect Document v1.0

Proprietary and Confidential 60

 EAST Architect Document v1.0

i. In this case, we examine how the LoadEngine and UTRANServer work

together to send data using the Iub protocol stack to the customer’s SUT.

ii. When the LoadEngine needs to transmit a message (via the Binary
Transmit TIO), the message is passed to the libEvent subsystem, which
then passes it to the libIO Subsystem for serialization and transmission
over TCP/IP.

iii. In this case, we assume that the LoadEngine and Protocol Server are
using P2P communications. In older releases, the LoadEngine and
UTRANServer would communicate via the EventServer, which added an
additional step for each message transmitted and received. Now, the
LoadEngine has the option to communicate directly to the UTRANServer.
This functionality is hidden in the libEvent Subsystem.

iv. The libIO Subsystem on the UTRANServer gets the message, unserializes,
and passes it to the UTRANServer itself. The UTRANServer sees this is a
message to transmit, and passes it to the libAal2 Subsystem for
encoding.

v. Note that this could easily have been the libAal5 Subsystem, or any other
protocol stack supported in the UTRANServer over ATM. For the purposes
of this example, we use the libAal2 for the Iub protocol stack.

vi. Once the message has been encoded with the RLC/MAC/FP layers, the
message is passed to the libPVC Subsystem, then to the
libDriverInterface Subsystem. The libDriverInterface is responsible for
adding ATM headers that the ATMDriver will expect for each message, as
well as buffering the messages under load so that fewer large
transmissions to the ATMDriver is done, as opposed to many smaller
transmissions.

vii. Once this is done, the libDriverInterface sends the message across the
TCP/IP interface to the ATMDriver itself.

viii. The ATMDriver then receives the messages, pulls out the header
information, then sends it to the Xalyo API code, which in turn sends the
message out the ATM link to the customer SUT.

ix. To receive a message, the process is reversed, with the Xalyo Hardware
receiving the message on the ATM links, passing it to the Xalyo software,
which then forwards it to the ATMDriver Subsystem itself, etc.

5.1.4.4 Transmit/Receive Message using SigtranServer:

Proprietary and Confidential 61

 EAST Architect Document v1.0

i. The LoadEngine allows the EAST User to design a test case that transmits
and receives messages with the customer’s SUT (by way of the
SigtranServer).

ii. In this case, we examine how the LoadEngine and SigtranServer work
together to send data using the M3UA/SCTP/IP protocol stack to the
customer’s SUT.

iii. When the LoadEngine needs to transmit a message (via the Binary
Transmit TIO), the message is passed to the libEvent subsystem, which
then passes it to the libIO Subsystem for serialization and transmission
over TCP/IP.

iv. In this case, we assume that the LoadEngine and SigtranServer are using
P2P communications, as mentioned above.

v. The libIO Subsystem on the SigtranServer gets the message,

unserializes, and passes it to the SigtranServer itself. The SigtranServer
sees this is a message to transmit, and passes it to the libM3UA
Subsystem for encoding (or the libSUA or libM2PA or…).

vi. The libM3UA Subsystem works with the libSigtran Subsystem to encode
messages according to the Sigtran standard. Once this has been
completed, the libM3UA sends the message to the libSctp Subsystem.

Proprietary and Confidential 62

 EAST Architect Document v1.0

vii. The libSctp Subsystem works either by emulating the actual SCTP
protocol layer, or by serving as an interface to the sctp.ko Linux kernel
module. This Use Case assumes the latter, although the only real
difference would be the elimination of the sctp.ko module and direct
access to the Linux kernel.

viii. Finally, the sctp.ko kernel module forwards the message to the Linux
kernel, which then sends the message to the customer’s SUT via IP.

ix. To receive a message, the process is reversed.

5.1.4.5 Transmit/Receive Message using MTP3Server:

i. When the LoadEngine needs to send a binary message to the MTP3Server

running over SS7 links, it goes through the following process.

ii. First, the LoadEngine passes the message to be sent to the libEvent
Subsystem, which then passes the message to libIO for serialization and
transmission to the MTP3Server.

Proprietary and Confidential 63

 EAST Architect Document v1.0

iii. The libIO Subsystem on the MTP3Server gets the message, unserializes,
and passes it to the MTP3Server itself. The MTP3Server sees this is a
message to transmit, and passes it to the libMTP3 Subsystem for
encoding.

iv. The libMTP3 Subsystem works with the libMTP3Common Subsystem to

properly encode the message. Once this is done, it forwards the
message to the libMTP2Adax Subsystem.

v. The libMTP2Adax Subsystem serves as an interface with the Adax HDC

API, as well as providing a way to organize the SS7 links and responding
to alarms from the Adax driver. When the libMTP2Adax Subsystem gets
the message, it sends it to the appropriate Adax HDC API interface.

vi. The Adax HDC driver then encodes the MTP2 protocol layer on the
message, and sends it from the specified SS7 link to the customer’s SUT.

vii. To receive a message, the process is reversed.

5.1.4.6 Transmit/Receive Message using SCTPServer:

A. With External SCTP Server:

i. In this case, we assume that the LoadEngine and SCTP Server are commincating
via EventServer. When the LoadEngine needs to transmit a message (via the
Binary Send TIO), the message is passed to the libEvent module, which then
passes it to the libIO module for serialization and transmission over TCP/IP to
EventServer.

Proprietary and Confidential 64

 EAST Architect Document v1.0

ii. On receiving messae, EventServer find appropriate EventConsumer and deliver

received message via libIO.

iii. The libIO/libEvent module on the SCTPServer gets the message, unserializes, and
passes it to the SCTPServer. The SCTPServer check appropriate resource and
delivered message to libeSCTP module for encode header. After endocing header,
libeSCTP delived message to lksctp module.

iv. lksctp module then transmit message to Linux SCTP Kernel. Then Linux Kernel
delived message to Customer SUT.

v. To receive a message, the process is reversed.

B. With Internal SCTP in LE:

a. In this case, we assume that the LoadEngine uses inbuild SCTP module for
transmit messages over SCTP Protocl stack. When the LoadEngine needs to
transmit a message (via the Binary Send TIO), the message is passed to the
libSCTP for encoding appropriate header. Then transmit message to lksctp
module, which then passes it to the Linux Kernel SCTP module and
transmission over SCTP/IP to Cusomter SUT.

Proprietary and Confidential 65

 EAST Architect Document v1.0

5.1.4.7 Transmit/Receive Message using GTPServer:

a. In this case, we assume that the LoadEngine and GTP Server are commincating via
EventServer. When the LoadEngine needs to transmit a message (via the Binary
Send TIO), the message is passed to the libEvent module, which then passes it to
the libIO module for serialization and transmission over TCP/IP to EventServer.

b. On receiving messae, EventServer find appropriate EventConsumer and deliver

received message via libIO.

c. The libIO/libEvent module on the GTPServer gets the message, unserializes, and
passes it to the GTPServer. The GTPServer check appropriate resource and delivered
message to libIO module after encoding GTP header. Then libIO is trasmiting
message to Customer SUT over TCP/IP.

d. To receive a message, the process is reversed.

5.1.4.8 Transmit/Receive Message using LUCPServer:

Proprietary and Confidential 66

 EAST Architect Document v1.0

a. In this case, we assume that the LoadEngine and LUCP Server are commincating via
EventServer. When the LoadEngine needs to transmit a message (via the
ASCII/Binary Send TIO), the message is passed to the libEvent module, which then
passes it to the libIO module for serialization and transmission over TCP/IP to
EventServer.

b. On receiving messae, EventServer find appropriate EventConsumer and deliver

received message via libIO.

c. The libIO/libEvent module on the LUCPServer gets the message, unserializes, and
passes it to the LUCPServer. The LUCPServer check appropriate resource and
delivered message to libIO module after encoding necesary header. Then libIO is
trasmiting message to External TM500 nox over TCP/IP. And further message is
forwarded to SUT.

d. To receive a message, the process is reversed.

5.1.4.9 Transmit/Receive Message using IPXpress Server:

A. During Signaling

Proprietary and Confidential 67

 EAST Architect Document v1.0

B. During Bearer

Proprietary and Confidential 68

 EAST Architect Document v1.0

Proprietary and Confidential 69

 EAST Architect Document v1.0

6. Product Structure

6.1 Product Structure

The following section describes the four major deployment configurations for EAST hardware
and the locations of the software packages.
Please see Section 5.2 for a comprehensive list of the three configuration types.

6.1.1 “Single User” EAST Configuration

This section describes the EAST Installation on standalone configured hardware (i.e.) Super
Micro or Travel Hawk or GPU with RTM or Customer Laptop/Desktop with EAST licensing for
maximum 1 Load Or 1 Regression (with/without automation) or 1 Test Case Creation. This
document depicts Hardware configuration for standalone with EAST License.

Standalone hardware means EAST Machines which have their own hard disk (HDD) and OS
kernel running from local disk. In this class EAST offers following H/W’s with Single user EAST
installation which may have Regression (with/without Automation) or Load or Test Creation or
combination of one or more.

 Super Micro

 Travel Hawk

 GPU with RTM

 Customer Laptop/Desktop (Not provided by NetHawk, sold only for Test Creation)

For detail information refer to below document:

https://nhdocuments.nethawk.fi/productcreation/simulators/EAST/Logistics
%20Documents/Deliverables/1.EAST%20Licensing%20Vs%20Hardware
%20Configuration/Single%20User%20EAST%20Configuration%20on%20Standalone
%20hardware.doc

6.1.2 “Multi User” EAST Configuration

This section describes the Multi User EAST Installation on standalone configured hardware
(i.e.) Super Micro or Travel Hawk or GPU with RTM with EAST licensing for multi user concept.
Maximum User limit is 4 Regression (with/without automation) or 4 Test Case Creation (5 Test
Creation valid for Super Micro and Travel Hawk) or combination of Regression, Load and Test

Proprietary and Confidential 70

 EAST Architect Document v1.0

Creation like 1 Load + 3 Regression (with/without automation) etc. This document represents
Hardware configuration for standalone with EAST License for multi user configuration

Standalone hardware means EAST Machines which have their own hard disk (HDD) and OS
kernel running from local disk. In this class EAST offers following H/W’s with Multi EAST user
installation which may have Regression (with/without Automation) or Load or Test Creation or
combination of one or more.

 Super Micro

This H/W can have 5 Test creations or 4 Regression (with/without

Automation) or 1 Load License or Combination of one or more. Total number
of License should not exceed 5 no’s.

 Travel Hawk

This H/W can have 4 Test creations or 4 Regression (with/without

Automation) or 1 Load License or Combination of one or more. Total number
of License should not exceed 4 no’s.

 GPU with RTM

This H/W can have 4 Test creations or 4 Regression (with/without

Automation) or 1 Load License or Combination of one or more. Total number
of License should not exceed 4 no’s.

For detail information refer to below document:

https://nhdocuments.nethawk.fi/productcreation/simulators/EAST/Logistics
%20Documents/Deliverables/1.EAST%20Licensing%20Vs%20Hardware
%20Configuration/Multi%20User%20EAST%20Configuration%20on%20Standalone
%20Hardware.doc

6.1.3 “Multi User Centralized Data” EAST Configuration

This section describes the Multi User Centralized Data EAST Installation on Super Micro
installed with GPU (with RTM/without RTM) with EAST licensing for multi user concept.
Maximum User limit is 4 Regression (with/without automation) or 4 Test Case Creation or
combination of Regression, Load and Test Creation like 1 Load + 3 Regression (with/without
automation) per EAST Hardware.

Proprietary and Confidential 71

 EAST Architect Document v1.0

EAST Admin should be created per H/W entity to invoke Individual EAST Event and License
servers and required EAST protocol Servers. This implies that all the users acting as EAST
Admin should have separate EAST Config files

Multi User Centralized Data implies user can have multiple points to generate EAST test
traffic against the system under test using multiple EAST hardware’s and data should be saved
at one place, in this class EAST offers following Hardware’s.

1. Super Micro:
No EAST license is applicable in this H/W as it just acts as a Data Server.

2. GPU with RTM

This H/W can have 4 Test creations or 4 Regression (with/without Automation) or 1
Load License or Combination of one or more. Total number of License should not
exceed 4 no’s.

3. GPU without RTM

This H/W can have 4 Test creations or 4 Regression (with/without Automation) or 1
Load License or Combination of one or more. Total number of License should not
exceed 4 no’s.

For detail information refer to below document:

https://nhdocuments.nethawk.fi/productcreation/simulators/EAST/Logistics
%20Documents/Deliverables/1.EAST%20Licensing%20Vs%20Hardware
%20Configuration/Multi%20User%20Centralized%20Data.doc

6.1.4 “Centralized Load” EAST Configuration

Centralized Load implies user can have one single point of control to generate load against the
system under test using multiple EAST hardware’s, in this class EAST offers following
Hardware’s.

4. Super Micro:
No EAST license is applicable in this H/W as it just acts as a Data Server.

5. GPU with RTM

This hardware can have one Load Server license.

6. GPU without RTM

This hardware can have one Load Server license

For detail information refer to below document:

Proprietary and Confidential 72

 EAST Architect Document v1.0

https://nhdocuments.nethawk.fi/productcreation/simulators/EAST/Logistics
%20Documents/Deliverables/1.EAST%20Licensing%20Vs%20Hardware
%20Configuration/EAST%20Configuration%20with%20Centralized%20Load.doc

Proprietary and Confidential 73

 EAST Architect Document v1.0

7. EAST Product Build Procedure:

This section updates about EAST Build procedure for different OS platform.

Before starting the Build Procedure the following are all assumed to be true if you wish to be
able to complete a build successfully using the build scripts.

A. One Server must have configured with Windows XP.

B. One Server must have configured with Linux 9.0 2.4.20-31.9smp.
C. One Server must have configured with Linux RHEL4U5 2.6.9-55.ELsmp.

Also folliwng tools required to Build EAST.

Tools on windows:
a. T2.2x86 Tornado2.2 for vxworks .st file build
b. MicroSoft visual c++ 98 (VC98 and common)
c. TortoiseSVN
d. SmartSVN
e. Subversion
f. Xmanager 2.0
g. Cygwin (no subversion)
Tools on RH9.0:
a. T2.2x86 Tornado2.2 for vxworks .st (reference for windows for failover)
b. timesys for (ATM binary build only)
c. GCC
i. compat-gcc-c++-7.3-2.96.118
ii. libgcc-3.2.2-5
iii. compat-gcc-7.3-2.96.118
iv. gcc-g77-3.2.2-5
v. gcc-java-3.2.2-5
vi. gcc-gnat-3.2.2-5
vii. gcc-3.2.2-5
viii. gcc-c++-3.2.2-5
d. Subversion
ix. subversion-1.4.2-1
x. subversion-perl-1.4.2-1
xi. subversion-python-1.4.2-1
xii. subversion-tools-1.4.2-1
e. /local/tools
xiii. apache-ant-1.6.5
xiv. j2sdk
xv. javalib
xvi. opt
xvii. ibm
xviii. jakarta-tomcat-4.1.31
xix. javas
 1.1.7
 1.3
 j2sdk1.4.2_03

Proprietary and Confidential 74

 EAST Architect Document v1.0

 jdk117_v1a
 jdk1.3.1_04
 commapi
 java_help
 jdk1.2
 JMF-2.1.1e
 1.1.7.orginal
 j2sdk1.4.2
 jdk1.3
 swing-1.1.1fcs
xx. j2ee
xxi. jakarta-tomcat-5.5.9
xxii. JMF2.1.1

Tools on RHEL4.5:
a. GCC
i. compat-gcc-32-3.2.3-47.3
ii. gcc-g77-3.4.6-8
iii. gcc-c++-3.4.6-8
iv. gcc-3.4.6-8
v. compat-gcc-32-c++-3.2.3-47.3
vi. libgcc-3.4.6-8
vii. gcc-java-3.4.6-8
viii. compat-libgcc-296-2.96-132.7.2
b. Subversion
i. mod_dav_svn-1.4.3-1
ii. subversion-tools-1.4.3-1
iii. subversion-1.4.3-1
iv. subversion-perl-1.4.3-1
c. CN38XX NPU SDK for AMC and PCI [mips64-octeon (SDK 1.5.0)]
i. CN3XXX-SDK-1.5.0_p1-195
ii. CN3XXX-PCI-NIC-0.9.4-42
iii. CN3XXX-IP-1.3.3-49
iv. CN3XXX-COMPONENTS-COMMON-1.3.3-30
v. CN3XXX-PCI-BASE-0.9.4-42
vi. CN3XXX-TCP-1.3.3-49
vii. CN3XXX-PCI-CNTQ-0.9.4-42
viii. CN3XXX-LINUX-1.5.0_p1-195
d. /local/tools
i. Ibm
ii. JMF2.1.1
iii. j2ee
iv. javalib
v. javas
i. commapi
ii. j2sdk1.4.2_07
iii. java_help
iv. jdk1.6.0_17

Note: Server should have EAST Third Party Software installed with the latest version.
 NMS
a. Version 8.1

Proprietary and Confidential 75

 EAST Architect Document v1.0

 ADAX
a. Version 1.1 delta 1.20 (qcx)
b. Version 1.1 delta 1.54 (hdc)
c. Version LiS-2.18.4 (LiS)
d. Version 3.0 delta 1.62 (fr)

East Core windows + RHL9 Build:

This procedure will output EastSetup.zip, EastSetup.exe and build logs into a specified
directory on the Windows/Linux build server. All logs can be found in the build directory on
the Windows build server and the Linux logs can also be found in the build directory on the
Linux 9.0 build server.

East Core RHEL4.5 Build:

This procedure will output EastSetup.zip and build logs into a specified directory on the Linux
RHEL4U5 build server. All logs can be found in the build directory on the RHEL4U5 build
server.

For detail Build Procedure please go through below link:

https://nhdocuments.nethawk.fi/productcreation/linemanagementindia/RD
%20Meetings/Product%20Architecture/EAST_Product_Build_Procedure_UserGuid.doc

8. Question/Answer

Proprietary and Confidential 76