8610ITE

Nexus Telecom 8610 ITE
Basic Training Document
Content overview

Introduction
General Overview
Hardware components
Software components
8610 ITE Applications

RKU
27.02.2010
X-ITE
Nexus Test case Editor QD-EDIT
Test Data Editor TDE
Universal Protocol Decoder UPD
Common Result Handler CRES
Nexus8610 ITE Presentation for C-DOT
Introduction
Nexus 8610 ITE is an advanced protocol test solution for network
operators and network providers
Enables the simulation and emulation of many telecommunication related
protocols in all existing core-networks, converged as well as traditional
SS7networks
Nexus 8610 ITE
Mobile
Network
RKU
27.02.2010
Fixed
Network
NGN
Network
Introduction
8610 ITE is the key solution for several testing requirements within an expanding
reliable network such as:
Feature test
Load/Stress test
System/Integration test
Regression test
Conformance test
Robustness test
Revenue assurance test
RKU
27.02.2010
General overview Hardware components

Used hardware platforms
SUN Desktop Ultra 25/45
Server SUN Fire V245
Server SUN Fire V445
1 or 2 x High Performance CPU

1 x PCI-X slots for interface cards
3 x PCI-e slot for interface card
2 x 10/100/1000 BaseT Gigabit
Ethernet ports
1 x embedded VGA card
2 x High Performance CPU

2 x PCI-e slots for interface cards
4 x 10/100/1000-Mbps BaseT
Ethernet ports
optional VGA card
rack-mounted
2 or 4 x High Performance CPU

4 x PCI-e slots for interface cards
4 x 10/100/1000-Mbps BaseT
Ethernet ports
optional VGA card
rack-mounted
Functional & Regression

Test
RKU
27.02.2010
Scaleable
High Performance Load

& Stress Test

Interface hardware
Quad port HDC interface card

4 E1/T1 links
PCI card for SS7/Frame Relay
Dual port ATM interface card

2 link ATM PCI
single/multimode fiber
RKU
27.02.2010
Quad port ISDN Basic Access interface card

Eight port ANALOGUE interface card
DSP processor onboard
Single/Quad Ethernet interface card

10/100/1000 Mbit
PCI card for additional ethernet ports
Additional Features
Several machines may be connected to a LAN
Usage of one machine as server possible
Possibility to use several machines and hardware by one user at the same time via same test
configuration.
Possible use of one machine by several testers (Multiuser-TUCH)

RKU
Remark:
Additional machines have to be added to $HOME/.netrc for usage.
27.02.2010
General overview Software components

Test case
Test cases
ITE
protocols
ITE
operating
system
SUN
Solaris
UNIX
RKU
27.02.2010
Customer Specific Protocol Adaption

Common ITE Kernel
Protocol Kernel
Forth Interpreter
Test Unit
Command Handler
(TUCH)
RTP
Interface Command Handler
(ITFCH_RTP)
Interface Command Handler

(ITFCH)
UNIX
Interface Card
(IP)
Interface Cards
(SS7, ATM, ISDN, Analogue)
General overview Software components

Testcases are forth-based, but written in a user-friendly notation.

Testcase compilation generates together with ITE-protocol contents a forthexecutable
Forth interpreter processes (amount depends on user-defined test
configuration)
execute this file towards Test Unit Command Handler (TUCH).
TUCH exists twice per machine:
One is owned by root, another by an user who locked the test machine
It may be restarted using the command /etc/rc2.d/S99tuch start
TUCH communicates either with the hardware directly (UNIX-based Ethernet

interfaces) or with the interface handlers (ITFCH) for non-IP-hardware
Kind and amount of ITFCH are defined in /etc/osite.conf
Exercise: Check for actual processes of tuch and itfch on your machine
RKU
27.02.2010
Nexus 8610 ITE Applications
Test case Editor

QDEDIT
XITE
main window
- navigation
- TC compilation
Universal Protocol
Decoder (UPD)
Terminal Data
Editor (TDE)
Test Execution
(TEA)
- Load Test
- Update Data
- Start-Stop
Global Data
Editor (GDE)
RKU
27.02.2010
Online Statistic
Offline Statistic
CRES
Nexus 8610 ITE Applications XITE

Xite
Start:
Xite &
console showing
actions & errors
Test list
.qd-file
Project test list
Test configurations
RKU
27.02.2010
Detailed test list

definition

RKU
XITE gives access to all tools necessary for test creation, test editing, test
execution
and result-evaluation.
A console-window is started simultaneously which displays all actions & errors of
XITE and its
sub-applications
All available test-configurations are displayed in the left window column
Test scenarios used for testing are represented with their whole structure
Main columns of X-ITE display the ITE-directory-structure of:
~/tests - 1st column
~/scenario - 2nd column
3rd- and 4th-column display content of selected directory in 2nd column
Remark: Whether youve opened XITE and nothing appears within the columns,
please check $HOME/Lamadef for correct paths
XITE characteristics may be set in $HOME/.Xiterc
27.02.2010

Testconfiguration
Select a Test Configuration
Select Item
Double Mouse-Click or
press <RETURN> to start
the Test Execution
Application (TEA)
Test Configurations
RKU
27.02.2010

QD-file
Edit a QD-File Testcase
Select Project
Select Area
Select a .qd-file
Press EDIT button
Selected QD-file
RKU
27.02.2010
Nexus 8610 ITE Applications QDEDIT

Testcases are written face-to-face (no separation of sides in different files)
ITE-command set provides all interface-specific messages and information elements
Copy & paste-functionality to copy test cases or to copy ITE commands from edit
assistance
Creation of a new .qd-file via the button New in X-ITE and editing with QDEDIT will fill
the .qd-file with the default .qd-contents.
Any .qd-file starts with a terminal configuration defining the different stack-elements and
the protocols they are using:
Due to the circumstance, that any used interface is handled as separate process during
execution, a steer file has to be generated each time anything was changed in the
terminal-configuration of the .qd-file. This will be done by choosing a .qd-file within Xite
and pressing the 'Gen Main'-button
RKU
27.02.2010

Editor
Editing
shortcuts
Terminal list
Macro List
Testcase List
Testcase commands
RKU
27.02.2010

Example Terminal Configuration
\Terminal Configuration\
\SIP_CLIENT\
Protocol:
SIP/VERSION2
Init:
TL_SIP/SIP_INIT/SIP_constants
Extensions: USE_AUTH
\SIP_SERVER\

Protocol:
SIP/VERSION2
\COMMON\
Extensions: USE_COMPRESS_FORMAT
\End Terminal Configuration\
Start-tag of
configuration table
Terminal name as
used in message flow
Terminal uses
this protocol
Protocol specific
constant file
Protocol specific
extensions
Extensions valid for
all used protocols
End-tag
configuration table
RKU
27.02.2010

Variants
Variants can be used to expand one test case to different versions.
Variants can be used to distinguish between:
I) configurations with different interface sets
II) special parts of a message flow inside a subsection
The usage of variants is optional.
All variants have to be defined in the variant section of the QD file.
Syntax:
\Variant <name>\
Terminals: <term1>, <term2>, etc.
\End Variant\
A variant block starts with \Variant name\ and ends with \End Variant\.
Switching between variants is done via the global data Variant.
When running the test case in Synchro mode, all terminals listed have to
beloaded to the test system, because of initial synchro-initiation betweenall
partners
RKU
27.02.2010
Nexus8610 ITE Applications QDEDIT

Example Variant definition
\Variant SIP_Loop\
Terminals: SIP_CLIENT, SIP_SERVER
\End Variant\
\Variant SIP_Asterisk_test\
Terminals: SIP_CLIENT
\End Variant\
\Variant SIP_ServerX_test\
Terminals: SIP_CLIENT
\End Variant\
Example Variant in message flow

SIP_CLIENT
|
SIP_SERVER
\|\
bob@biloxi.com
Invite
|
SIP_MSG--------------------------------->|
|-------------------->SIP_MSG
|
|
Ringing
|<--------------------SIP_MSG
SIP_MSG<---------------------------------|
C_Ringing
|
|
\Variant SIP_ServerX_test\
|
SIP_MSG<---------------------------------|
C_Ringing
|
\End Variant\
|
RKU
27.02.2010

RKU
Message Setup
27.02.2010

Message setup for sending and reception
SIP_MSG->
Send message with

default delay
T303 SIP_MSG<-
Await message with

predefined timeout T303
2000 SIP_MSG->
Parameter setup for sending and reception

bob@biloxi.com
pc33.atlanta.com
SIP_MSG->
T303 SIP_MSG< bob@biloxi.com
RKU
Invite
Via
Send message with

user-set delay of
2000 ms
C_Invite
Sending: 1st setup parameters, then send the message
Reception: 1st await message, then check parameters

Usage of strings: After 1st double-quote a leading space has to be inserted
27.02.2010

Synchronisation of terminals
In test mode manual Synchro and Synchro all terminals are automatically
synchronized at the start and the end of the test case
Sending internal trigger in message flow from one terminal to another
Using TRIGGER_<termname> and RCV_TRIGGER function
To use this function all terminals must be located on the same TEQ and
the extension USE_TC_INIT must be defined
Example
SIP_CLIENT_1
|
|
bob@biloxi.com Invite
|
SIP_MSG----------------------------------------------------->|
|
SIP_MSG<-----------------------------------------------------|
C_Ringing
|
|
TRIGGER_SIP_CLIENT_2
|
RCV_TRIGGER
|
|
bob@biloxi.com Invite |
SIP_MSG------------------>|
|
RKU
27.02.2010
SIP_CLIENT_2

RKU
All useable commands are documented at the Online Documentation:

Web-documentation: Protocols [Protocol name]
Choose within Xite the actual changed .qd-file and press Gen-button (Gen-Main if you
generate for the first time). Red or Green frame around the button indicates the generation
status. In case of errors, they are displayed within the Xite-console.
When pressing the '^Gen' - button, only terminals which contents have been changed and
with the same terminal-prefix are verified.
Remark: Generation does mean only a syntactical check, no semantic one. ITE allows the
user to create non-specified message-flows.
Generation will create several sub-directories named as the .qd-file-directory + terminal
name. These directories contain the executables file which have to be used when loading
the testmachine. Its recommended to create unique names for projects + interface-areas
which easily can be identified by name in case of later usage (e.g. regression-testing)
Exercise: Check the above described directory-structures
27.02.2010

RKU
QD to TEA Mapping
27.02.2010
Nexus 8610 ITE Applications TEA

TEA: Test execution application; opened by double-clicking any test configuration

Emulated Layer(s)
Terminal
status matrix
Simulated Layer(s)
Actual test campaign
counting
Online result
evaluation
Test campaign counting on

hour base
Global
control area
Interactive test control
RKU
27.02.2010
Pre-test campaignsettings

RKU
For each connection link to the test object (e.g. trunk) a stack has to be defined.
The names of the stack-points are only of informative nature. They can be set freely
by the user.
Each stack consists of several terminals, representing the different protocol-layers
& channels. Any terminal is handled as one process during test execution.
Each protocol-layer contains a scenario which enables communication with its
upper and lower layer(s). Lower layer runs in emulation mode which can be
influenced by the simulated layer.
All hardware links have to be represented by this stack, even if they're unused.
Unused links have to be filled with a dummy-scenario.
Several colours represent the status of the test equipment (TEQ):
green
- TEQ is available for all users (locked by nobody)
red
- TEQ is locked by another user in single-user mode
grey
- TEQ is not reachable via Ethernet
Reasons:
I) TEQ was restarted/shut downed recently (<10min)
II) network problem
yellow
- TEQ is locked by user himself = ready for testing
magenta
- TEQ is locked by another user in multi-user mode
27.02.2010

Any terminal contains specific data (e.g. OPC, DPC, numbers ...). The data have to be
set on simulators point of view (e.g. OPC is the OPC of ITE and the DPC of
exchange).
All settings (stack-building, terminal data-set-up) are done with the Terminal Data
Editor (TDE).
Invoke with the double-left mouse button click over the Terminal status matrix.
Tip: Creation of a new test is easily done by copying an existing (maybe similar) test
(via UNIX-cmd 'cp') and editing the differing data.
Global control area for loading
Control-buttons for all terminals ( whole test configuration )
- Load Test : Load all data, Simulation and Emulation - Scenarios from SUN to ITE-TEQ.
- Load Upper Layers : Load all data and Simulation- Scenarios from SUN to ITE-TEQ.
- Update Variables : Load all data from SUN to ITE-TEQ.
Global control area for execution (interactive test control)
After loading, all terminals are running in a so-called IDLE-state, waiting for any action by the
user.
Following actions can be done by using the buttons:
- Start : All terminals will start test case execution of the selected test case(s).
- Stop : All terminals will stop test case execution if the selected test case loop is finished.
- Release : All terminals will immediately stop actual test case execution.
RKU
27.02.2010

Any terminal reflects an independent EMULATION or SIMULATION process (according
theOSI-STACK ) e.g.
Terminal L1 : Emulation for ATM Layer 1
or ISUP Layer 1
Terminal L2 : Emulation for SCCP/TCAP
or ISUP MTP L2+L3
Terminal L3 : Simulation for GMM/SM
or ISUP Whitebook
Colour of terminals reflects the actual status:
Emulation :
grey
- deactivated
aquamarine
- activated
Simulation :
grey
- destination subscriber
aquamarine
- origination subscriber
blue
- seizure
green
- testcase passed
red
- testcase failed
Hints : If terminal gets black after loading the corresponding test process is terminated.
Try whether you can verify the scenario corresponding to the
terminated terminal without any error.
Check the Xite console for the corresponding entry.
RKU
27.02.2010
Nexus 8610 ITE Applications TDE

TDE: Terminal Data Editor

Select executable
test list
Edit terminal
specific data
RKU
27.02.2010
Display a specific variablevalue

for all terminals where its
used
Nexus 8610 ITE Applications TDE

Setting of used executable test list (so-called scenario)

Setting of terminal specific variables like start-time etc.
Setting of protocol specific variables like own IP address, Called Number etc
Possibility to overwrite global variable settings like test case-number etc.
Typical terminal data entry:
DataVar: D_Start
With this variable it is possible to change the delay between pressing the Start button and
begin of test case.
e.g. D_Start = 1000 ( =1000 milliseconds )
DataVar: Start_Nr
Normally set via global data - valid for all terminals.
Sometimes it may be necessary to execute on a special terminal a different test case - this is
specified via Start_Nr.
e.g. Start_Nr = 5
RKU
27.02.2010
Nexus 8610 ITE Applications GDE

GDE: Global Data Editor (Test Control)
Test mode setting
Test case setting
Test case list definition
RKU
27.02.2010
GDE Test Modes (general)

RKU
Remark: Its also possible to set the test mode exclusive for some terminals via the TDE
using the
variable Start_Stop_Mode and the values described below.
27.02.2010
manual Synchro
(Start_Stop_Mode =0)
Synchro
Manual
Loop
Load
Complex
GDE Test Modes (Manual)

Manual mode
FirstTC = LastTC ( LastTC is not necessary)
e.g. FirstTC = 1
CMD:
Start - TC 1 will be executed and stopped
and so on
FirstTC is not equal to LastTC
e.g. FirstTC = 1 LastTC = 3
CMD:
and so on
UpdateVar - Next TC will be TC 1 ( First TC )
RKU
27.02.2010
GDE Test Modes (Loop)

LOOP mode
First TC = Last TC ( LAST TC is not necessary)
e.g. First TC = 1
CMD:
Start - TC 1 will be executed

TC 1 will be executed
and so on
Stop - tescase execution is stopped testcase is finished
Release - testcase execution is immediately stopped
First TC is not equal to Last TC

e.g. First TC = 1 Last TC = 3
CMD:
Hint:
RKU
27.02.2010
Start - TC 1 will be executed

and so on
Stop - tescase execution is stopped after last testcase of sequence
(i.e. TC 3) is finished
Release - testcase execution is immediately stopped
Press start and immediately stop - TC 1-2-3 will be executed
once.
GDE Test Modes (manual Synchro)

manual Synchro mode
All terminals are running in independent processes.
Using this mode it is possible to synchronise the execution of terminals.
Extension USE_TC_INIT must be defined in the Terminal Configuration.
Testcase execution behaviour is the same as in Manual mode.
At the beginning and at the end of each testcase all terminals will be synchronized. This
synchronization is done via internal ITE mail messages, which can also be sent from one
board to another within the same TEQ.
It is not yet possible to synchronise terminals over different TEQs and so it is only possible to
run in manual Synchro mode, when all terminals defined in the QD
file are running on the same TEQ.
RKU
27.02.2010
GDE Test Modes (Synchro)

Synchro mode
All terminals are running independent processes.
Using this mode it is possible to synchronise terminals, which belong together.
Extension USE_TC_INIT must be defined in the Terminal Configuration.
Testcase execution behaviour is the same as in Loop mode.
At the beginning and at the end of each testcase all terminals will be synchronized. This
synchronization is done via internal ITE mail messages, which can also be sent from one
board to another within the same TEQ.
It is not yet possible to synchronise terminals over different TEQs and so it is only possible to
run in Synchro mode, when all terminals defined in the QD file are running on the same TEQ.
RKU
27.02.2010
GDE Test Modes (Load, Complex)

LOAD mode
Load mode is not for all protocols available
All loaded scenarios execute parallel calls.
Terminating-sides are always prepared to receive an incoming call, even if
the Start button wasn't pressed.
Automatic recognition of busy call attempts, due to scanning of message and parameter
contents.
Only one test case of the test list can be executed per terminal, so only First TC is relevant.
Special Data Variables ( see later e.g. BHCA, Poisson ) for Load Mode available.
COMPLEX mode
Only available for special protocols (e.g. ISUP). Information on request .
RKU
27.02.2010
GDE Test case selection

FirstTC:
selects the first test to be executed after load or update (max.999).

Actual value is reported in UPD
LastTC:
selects the last test case to be executed in the test case sequence (max.999).
Determine last TC from QD:

Automatically scans QD for the last test case and stores it as LastTC.
Variant
select variant for test case execution (see Variant definition)
Use TC List enables the use of a test case list.

(use of test case lists is only possible in Loop or Synchro mode)
Include
all test cases defined in the test case list will be executed.
Exclude
all test cases defined in the test case list will be skipped.
(range of test cases to be executed is given by FirstTC and LastTC)
TC List
comma separated list of single test case numbers or test case ranges to
be used as include or exclude list .
(Example: 3,4,8-12,15)
RKU
27.02.2010
GDE Timers&Numbers
GDE : Global Data Editor (Timers & Numbers)
Timer Settings
Number Settings
RKU
27.02.2010
GDE Timers
Timers: All timers in ITE have to be set in milliseconds. Most used timers are:
D_Snd_Delay:
General delay before any message-send-process.

Default value: 100 ms
D_Next_Call:
This value is used to delay execution of next test case. Only applicable for
A-side terminals and with BHCA is set to 0.
D_Start:
Specifies the delay between the start of the test case (start button is pressed)
and the execution of the first test case. Only applicable for A-side terminals.
Default value: 0 ms
T_Trigger:
Default watchdog timer for trigger reception (RCV_TRIGGER).

D_Speech:
Delay before starting speech path test.

Default value: 2000 ms.
T_Nodef:
a message.
Default watchdog timer, that is used when no specific timeout value is

RKU
27.02.2010
defined for
GDE Common Numbers

Common Numbers
Called
Digits of the called party number for originating calls.

Only applicable for A-side terminals.
Calling
Digits of the calling party number
Expected
Digits of the called party number for terminating calls.

Only applicable for B-side terminals
Called, Calling and Expected numbers may be used for other purpose in some
protocol implementation (e.g. SIP). Check web documentation of protocols for more
details.
User specific Numbers TDx_NR (1<=x<=9)
User specified variables. Value string can be used inside the test case message flow
with the command TDx_NR. Maximal length of characters (digits): 40
RKU
27.02.2010
GDE Various Data

GDE: Global Data Editor (Various data)

Other Global Data Viewer
Display Settings
Loadrate Settings
Additional settings
RKU
27.02.2010
GDE UPD display

Display
Display controls the resolution level of the decoding of sent and received messages.
Special ITE information ( like test case_id .. ) is always displayed.
Note: the exact effect on the decoding is protocol dependent
RKU
None:
Only the Message will be displayed.
UPD:
Displaying of decoded high layer message

Parameter contents are displayed close to specification (see chart UPD)
Hex:
Message name and parameter contents of the message will be

displayed in hexadecimal notation.
Para:
Message name, parameter name and parameter contents will be

displayed in hexadecimal notation.
UPD all:
For INAP/MAP. Decodes SCCP & TCAP/INAP. Message name and

parameter names and parameter contents in words.
UPD low:
For INAP/MAP. Decodes SCCP & TCAP/INAP. Message names and

parameter names and parameter contents in hexadecimal notation.
27.02.2010
GDE Load Test

Special Data for Load mode
BHCA = 0 - 10000 ( Busy Hour Call Attempts)
- If BHCA = 0, the variable D_Next_Call is valid.
- If BHCA is not 0, D_Next_Call is disabled.
With this variable it is possible change the calls per hour per terminal.
Example:
30 ISUP-Channels are used, BHCA=100 3000 Calls/per hour will be executed on the ISUP link.
The calls/hour will be reached independent of the scenario length, but only if the call is short
enough to reach the requested BHCA rate ( e.g. if the call needs 1 min., it is impossible to reach
100 BHCA )
Example:
|-------- 1.Call+Delay -------|-------- 2.Call+Delay --------|
|---- call ----|
|-call -|
|--D_Next_Call--|
|--D_Next_Call----------|
RKU
27.02.2010
GDE Load Test, Various

BHCA_Factor = 0 - 10000
enables the user to vary the BHCA-values of all terminals involved in the same test on a
per-thousand-base (BHCA=BHCA*BHCA_Factor/1000).
Poisson ( random distribution )
Activation of random call distribution, the setup BHCA rate will still received.
Additional Settings
Hold_On_Fault: Stop further test case execution after any fault until pressing
RELEASE.
Succ_Flt:
Set amount of successive faults which can occur until the test
stops.
Rep_Nr:
n-times).
TC repeats n-times if n>0, in case of n>0 TC repeats till it passes (max.
Other Variables
Terminal variables which will be used in all terminals.
RKU
27.02.2010
GDE Advanced Options

RKU
GDE: Global Data Editor (Advanced Options)
27.02.2010
GDE Advanced Options

Advanced Options
Bch_Disable: Disable B-channel (no tone-recognition)
Break_Off: Interrupt test case-flow at <BREAK> command until Update Variables button is
pressed. This command is useful for feature test, e.g. to check any flags in exchange.
MaxResultFiles: Number of allocated result files, which are cyclically overwritten.
MaxResultFiles = 0 : one result file with unlimited size is allocated.
1 <= MaxResultFiles <= 8 : MaxResultFiles + 1 result files with 100 MB are allocated
RKU
27.02.2010
GDE Online Help

For every entry is a short help description available when moving the mouse cursor
over the corresponding field and pressing the right mouse button.
RKU
27.02.2010
Nexus 8610 ITE Applications UPD

Decoding example for byte oriented protocol
Octet numbering
Binary decoding of
any octet as
specified
Textual description
of
decoded bit-part
Hexadecimal or
additional
textual description
of
decoded bit-part
RKU
27.02.2010

Decoding example ASCII oriented protocol

Decoding level: UPD
RKU
27.02.2010
Decoding level: Hex

Tool to inspect the message flow on a specific terminal.
Start UPD with right mouse button click on any terminal.
Received messages are decoded in different resolutions.
Max. 6 UPDs can be opened per test session.
Output function
Output On/Off : Toggle tracing and output of actual message flow.
Save Logfile : Save actual logged message flow to file
Terminal control
Start/Stop/Release/Kill/Scenario can be done here to steer only this special
terminal. All other terminals are not impacted.
Resolution
Minimum: Messages & parameters are displayed, parameter contents in HEX.
Medium : None-ASN1 parameters are displayed detailed,
ASN1-parameters are in medium resolution.
Maximum : Also ASN1-parameter are displayed in maximum resolution.
Hint: After test equipment-restart, any still open UPD has to be reconnected (CTRL+R)
RKU
27.02.2010
Nexus 8610 ITE Applications CRES

CRES: Common Result Handler
Counters
Textual Fault
Description
RKU
27.02.2010
Nexus 8610 ITE Applications CRES
Tool to inspect the results of any test run.

Displays all used counters as summary and per terminal.
Displays fault description of each occurred fault.
Contains several filters, so huge data fields can be reduced easily.
Allows to export results in ASCII / Interface to other tools e.g. Excel.
Exercise: Analyse a pre-recorded result file to investigate Counters, Fault-Text,...

RKU
27.02.2010
Thank you !
www.alcatel-lucent.com
RKU
27.02.2010
Further Information
Please visit our website: www.nexustelecom.com
For further questions, please contact:

Ralf Khl
mailto ralf.kuehl@nexustelecom.com
phone: +41 78 750 6856
Helpline
RKU
27.02.2010
mailto 8610@nexustelecom.com
phone: +41 76 355 6767

8610ITE

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

8610ITE

Hochgeladen von

Copyright:

Verfügbare Formate

Nexus Telecom 8610 ITE

Basic Training Document

8610 ITE Applications

Nexus8610 ITE Presentation for C-DOT

Nexus 8610 ITE

Nexus8610 ITE Presentation for C-DOT

Nexus8610 ITE Presentation for C-DOT

General overview Hardware components

Used hardware platforms

SUN Desktop Ultra 25/45

Server SUN Fire V245

Server SUN Fire V445

1 or 2 x High Performance CPU

2 x High Performance CPU

2 or 4 x High Performance CPU

Functional & Regression

Nexus8610 ITE Presentation for C-DOT

High Performance Load

General overview Hardware components

Quad port HDC interface card

Dual port ATM interface card

Nexus8610 ITE Presentation for C-DOT

Quad port ISDN Basic Access interface card

Single/Quad Ethernet interface card

General overview Hardware components

Nexus8610 ITE Presentation for C-DOT

General overview Software components

Customer Specific Protocol Adaption

Interface Command Handler

Nexus8610 ITE Presentation for C-DOT

General overview Software components

Testcases are forth-based, but written in a user-friendly notation.

TUCH communicates either with the hardware directly (UNIX-based Ethernet

Nexus8610 ITE Presentation for C-DOT

Nexus 8610 ITE Applications

Test case Editor

Nexus8610 ITE Presentation for C-DOT

Nexus 8610 ITE Applications XITE

Nexus8610 ITE Presentation for C-DOT

Detailed test list

Nexus 8610 ITE Applications XITE

Nexus8610 ITE Presentation for C-DOT

Nexus 8610 ITE Applications XITE

Nexus8610 ITE Presentation for C-DOT

Nexus 8610 ITE Applications XITE

Nexus8610 ITE Presentation for C-DOT

Nexus 8610 ITE Applications QDEDIT

Nexus8610 ITE Presentation for C-DOT

Nexus 8610 ITE Applications QDEDIT

Nexus8610 ITE Presentation for C-DOT

Nexus 8610 ITE Applications QDEDIT

Nexus8610 ITE Presentation for C-DOT

Nexus 8610 ITE Applications QDEDIT

Nexus8610 ITE Presentation for C-DOT

Nexus8610 ITE Applications QDEDIT

Example Variant in message flow

Nexus8610 ITE Presentation for C-DOT

Nexus 8610 ITE Applications QDEDIT

Nexus8610 ITE Presentation for C-DOT

Nexus 8610 ITE Applications QDEDIT

Send message with

Await message with

Parameter setup for sending and reception

Send message with