Embedded   GSM   Avionics   DSP   Consumer   Automation   Unix   DOS\Windows   Networking


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

LSUv3 System Architecture
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.
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.


• Height: 74 cm
• Width: 60 cm
• Depth: 60 cm
• 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.


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.

LSU v3 Software modules overview
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