|
LINE SERVER UNIT Version 3
Technical
Description
Hardware Architecture
The Line Server Unit V.3
(LSUV3) is a high performance multiprocessor system based on the Compact
PCI (cPCI) bus and using a pool of single or dual Pentium III cards, E1/T1
PCM Line cards, SCC (Serial Communication Controller) cards and Atm &
Ip Wan cards equipped with the Power Quick II (MPC8260) communication coprocessor.
The system functions are
split among some specialized control units: the MPU (Main Processing Unit)
and a set (1-4) of PPUs (Protocol Processing Unit).
The MPU manages the graphical console, the shared mass storage, the removable
devices and the network interface to the corporate LAN.
The PPUs run the various protocol module that require accurate control of
the processing power and the real time behavior of the processor. For some
applications the Pentium III cooperates also with the communication coprocessors
on the Wan cards.
We typically select the CPU card among the best products available on the
market, conversely all the other cards has been designed specifically by
our hardware development team with this application in mind.
The excellent system performances
are obtained using the last generation of semiconductor components,
and the great reliability and flexibility of QNX 6 (Neutrino) operating system.
Additional commercially available cPCI cards can optionally be added to the
system for special test requirements (i.e. Multiple Ethernet Interfaces).
The LSUV3 distinguishing features are:
- 4 independent cPCI
bus segments of 5 slots each connected to the H.110 bus;
- Huge processing power:
up to 5 Single or Dual Pentium III and 8 MPC8260
- Distributed 4096x4096
switch matrix;
- Up to 128 E1/T1 PCM
interfaces;
- Up to 4096 SCC with
channel rate from 8 to 2048kbit/sec.;
- Up to 16 STM-1 interfaces
(UTP or Optical connection);
- Up to 64 Digital Phone
interfaces;
- Up to 16 Multiprotocol
interfaces (V.28,V.11,V.35,RS-232,RS-449,RS-485,RS-422);
- Up to 16 Internal STM-1
links to distribute the load to the available processors
Figure 3 – LSUV3 System Architecture
The system is totally
scalable in terms of installed PPUs, PCM, SCC, or Wan cards and if necessary
other commercially available cards.
The LSUV3 PCM card provides 16 E1/T1 PCM Interfaces,
an H.110 controller and timeslot switching unit, the clock synchronization
function by means of a digital PLL that references to an internal or external
source.
The LSUV3 SCC card
provides a pool of 1024 serial communication controllers with channel
rate from 8 to 2048 kb/s and an H.110 controller. It supports both HDLC based
protocols (i.e. LAPD, Frame Relay, SS7), and some other ones operating in
transparent mode (e.g. Trau Frames, PCU Frames, V.110 packets).
The ATM 155 PMC card is a mezzanine
card designed to be mounted on a CompactPCI carrier or directly on a CompactPCI
CPU board with PMC connectors, in order to manage a STM-1/OC-3 optical or
electrical interface.
Power requirement
It ranges between 150-350 W (110 or 220 VAC) depending on the selected
hardware configuration.
Mechanical
- • Height: 74 cm
- • Width: 60 cm
- • Depth: 60 cm
Environmental
- • Operating Temperature:
0 to 45 C
- • Non-Condensing Relative
Humidity: less than 95% at 40 C
Software Architecture
The LSUv3 keeps the successful
modular software architecture of its precursors (LSU/LSU+), based on the
client/server model. This concept applies both to its internal and external
interfaces. The LSUv3 basically handles the hardware interfaces and the lower
layer of communication protocols, and it allows other client applications,
optionally running on external hosts, to operate at the upper level through
a set of primitives.
Communication between
LSUv3 and its clients is based on TCP/IP. Each LSUv3 software package that
manages a specific function (e.g. Configuration services, Logging services,
LAPD services, SS7 services, etc.) provides a service access point that corresponds
to a daemon process that is listening to a predefined TCP port number. On
the other hand, LSUv3 internal IPC is based on the high performance message
passing mechanism of QNX, while connection between the client and the router
is based on TCP.
In this way client applications
can run within the LSUv3 environment or on other hosts and use a local or
remote user interface.
At first the client application
connects to the daemon, which in turn spawns a dedicated router that manages
all primitives of the requesting client. Then the router typically activates
the specific protocol modules according to the configuration primitives received
from the client, and it continues to route the primitives between the client
and the addressed software modules.
This architecture supports
concurrent operation of multiple protocol stacks (e.g. LAPD, SS7, Gb …),
and it allows multiple clients to share the system, of course excluding the
layer-1 resources.
A key feature of every LSUv3 protocol implementation is the maximum conformance
to the relevant specifications (ITU, GSM, 3GPP etc.) at upper and lower access
points of the protocol stack. This also means that the primitives exchanged
with the application typically correspond to what is specified in the related
recommendations. Moreover a set of O&M primitives allows the configuration
of the stack and the layer management functions.
The system startup includes
only activation of layer-1 drivers and daemons; all other protocol modules
are activated on demand by the client application.
Client Applications
The interface between
LSUv3 software packages and the external world is fully public. So, on the
client side, we can provide the proper solution or just support the customer
that decides to develop autonomously what is needed, sometimes integrating
an already existing proprietary tool.
In any cases, software
at the client level is supplied with full source code, in order to let users
update or add new features themselves.
The choice of the proper
client application depends on several factors: the test phase it addresses
to, the development environment and the education of the testing team, that
is the tools and/or the languages they are already familiar with.
Entity and white box testing
typically requires to develop a multitude of separate message sequences to
test singularly all the functions of the system. Conversely the Load &
Stress phase need not handle the details of all procedures; it needs a powerful
method to flexibly create scenarios as close as possible to the real environment
to simulate.
The solutions suitable
for White Box and Entity Tests are:
- Custom client application
using an interpreted language that fits both the application and the education
of the testing team (e.g. Visual Basic, TCL/TK, simple ‘C’ test programs).
- Integration with third
party tools, like Telelogic SDT or Telelogic TTCN, by means of a proper ‘Adaptation
layer’ that for example, in case of Telelogic SDT, translates the various
messages into SDL signals. In this way the user can develop the test sequence
using the SDL graphical editor, generate the test application with
the SDL code generator, and execute the test with the SDL simulator.
As far as System Test and
Load & Stress are concerned, these teams need not bother about developing
any test script based on some special proprietary language; we provide a
ready to run, basic object oriented Load & Stress engine that can be
adapted to all interfaces and customised on the basis of the specific test
requirements. The users have only to describe the scenario they want to simulate
by means a configuration file, and to provide the table of mobiles data.
Modularity
The LSUv3 is highly modular
by design, both in hardware and in software, since it was designed for different
working environments (entity test, white box test, black box test, integration
and system test) in several application areas.
The available interface
lines and serial channels can be used profitably in load & stress test
beds, and different teams can share a single LSUv3 among several prototypes.
The hardware configuration
is suited to the customer application in terms of:
- Number of PPUs, from
1 to 4;
- Number of PCM cards, from 1 to 8 (16-128 E1/T1);
- Number of SCC cards, from 1 to 4 (1024-4096 SCC);
- Number of ATM & IP Wan cards,from 1 to 8 (2-16 STM-1);
- Additional commercially
available cards if required.
On the software side, a great
number of software modules are available, as described in the following chapter,
and many other are being developed or planned for release in the near future.

Figure 8 – LSUv3 Software packages overview
In addition Prisma Engineering
software team is available to develop custom modules in order to satisfy
specific customer needs.
Basic Software
Each LSUv3 hardware configuration
is supplied with the Basic Software, and, if required, Optional features
can be added.
The Basic Software Package
contains the following components:
- System software POSIX
compliant (QNX 6 OS(*)) for MPU, PPUs and Wan Cards;
- TCP/IP client and server
facilities (QNX 6 TCP/IP(*));
- Graphical console environment
(QNX 6 Photon(*)).
- Layer 1 multi-protocol
PPU & Wan Card drivers — It is the lower level software managing hardware
resources. It includes the driver running on every PPU and the driver running
on the Wan Card. These processes are activated at system initialisation time.
They basically support configuration and layer-1 protocol services (e.g.
HDLC, AALx, Transparent).
- Configuration server
— It supports the following functions
|
- PCM, STM-1 lines:
parameters configuration and state monitor;
- Synchronisation configuration and monitor;
- Serial channels: rate definition, mapping, current usage monitor;
- Digital-phone: configuration of gain and filters;
- Switch matrix: channel connections, timeslots content trapping;
- ATM physical layer: IMA and UNI configuration and connection, monitor;
- ATM circuit management: channel definition and routing, monitor;
- Configuration Scenario Global Save/Restore;
- Report activity about the various operating servers.
The software structure follows the client/server model used for all
protocol and utility servers. |
- The Web based Configurator
— It can be activated either on the local browser or remotely. Multiple instances
can work concurrently to monitor the system operation from different point
of view (i.e. PCM line alignment state, trapped timeslot content, ATM physical
state …).
- The configuration scripting
facility — It is an alternative way to perform the same operation as above
but by means of a scripting facility. All functions of the Configurator correspond
to special statements that can be specified in a script file. The syntax
supplies with some additional keywords in order to introduce pauses or loops
as is typically required in a test automation environment. The source code
is included to allow easy integration with other systems.
- Logging server — It
distributes the logging events that are collected and classified by the layer-1
drivers to its clients. A client can log concurrently multiple ports with
different protocols; multiple clients can log the same port. The system supports
monitoring the message flow between two real network elements (serial channels
in read only mode), or the message exchange between an LSUv3 simulation package
and an external equipment. The logging server dispatches messages in binary
format, which shall be decoded by the client application.
The LSUv3 comes with the
source code of a portable client application with plain text decoding of
the most used standard protocols. The application can be customised to add
decoding of proprietary protocols (i.e. Abis Operation and Maintenance).
This application can be used on the local console, through a telnet session,
or recompiled in order to be executed on a remote host (Solaris, Linux, SCO,
Windows, VMS, etc.).
In the following pages
you can find the list of the available software
modules ans some examples of common applications.
Info: lsu@prisma-eng.it
|