All contents of this document are furnished for informational use only and are subject to change without notice and do not represent a commitment on the part
of Dialogic Corporation or its subsidiaries ("Dialogic"). Reasonable effort is made to ensure the accuracy of the information contained in the document.
However, Dialogic does not warrant the accuracy of this information and cannot accept responsibility for errors, inaccuracies or omissions that may be
contained in this document.
INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH DIALOGIC® PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED,
BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED
IN A SIGNED AGREEMENT BETWEEN YOU AND DIALOGIC, DIALOGIC ASSUMES NO LIABILITY WHATSOEVER, AND DIALOGIC
DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF DIALOGIC PRODUCTS INCLUDING LIABILITY
OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY
INTELLECTUAL PROPERTY RIGHT OF A THIRD PARTY.
Dialogic products are not intended for use in medical, life saving, life sustaining, critical control or safety systems, or in nuclear facility applications.
Due to differing national regulations and approval requirements, certain Dialogic products may be suitable for use only in specific countries, and thus may not
function properly in other countries. You are responsible for ensuring that your use of such products occurs only in the countries where such use is suitable.
For information on specific products, contact Dialogic Corporation at the address indicated below or on the web at www.dialogic.com.
It is possible that the use or implementation of any one of the concepts, applications, or ideas described in this document, in marketing collateral produced by
or on web pages maintained by Dialogic may infringe one or more patents or other intellectual property rights owned by third parties. Dialogic does not
provide any intellectual property licenses with the sale of Dialogic products other than a license to use such product in accordance with intellectual property
owned or validly licensed by Dialogic and no such licenses are provided except pursuant to a signed agreement with Dialogic. More detailed information
about such intellectual property is available from Dialogic's legal department at 9800 Cavendish Blvd., 5th Floor, Montreal, Quebec, Canada H4M 2V9.
Dialogic encourages all users of its products to procure all necessary intellectual property licenses required to implement any concepts or applications and
does not condone or encourage any intellectual property infringement and disclaims any responsibility related thereto. These intellectual property licenses
may differ from country to country and it is the responsibility of those who develop the concepts or applications to be aware of and comply with different
national license requirements.
Any use case(s) shown and/or described herein represent one or more examples of the various ways, scenarios or environments in which Dialogic® products
can be used. Such use case(s) are non-limiting and do not represent recommendations of Dialogic as to whether or how to use Dialogic products.
Dialogic, Dialogic Pro, Brooktrout, Diva, Cantata, SnowShore, Eicon, Eicon Networks, NMS Communications, NMS (stylized), Eiconcard, SIPcontrol, Diva
ISDN, TruFax, Exnet, EXS, SwitchKit, N20, Making Innovation Thrive, Connecting to Growth, Video is the New Voice, Fusion, Visio
NaturalAccess, NaturalCallControl, NaturalConference, NaturalFax and Shiva, among others as well as related logos, are either registered trademarks or
trademarks of Dialogic Corporation or its subsidiaries. Dialogic's trademarks may be used publicly only with permission from Dialogic. Such permission may
only be granted by Dialogic's legal department at 9800 Cavendish Blvd., 5th Floor, Montreal, Quebec, Canada H4M 2V9. Any authorized use of Dialogic's
trademarks will be subject to full respect of the trademark guidelines published by Dialogic from time to time and any use of Dialogic's trademarks requires
proper acknowledgement.
The names of actual companies and products mentioned herein are the trademarks of their respective owners.
This document discusses one or more open source products, systems and/or releases. Dialogic is not responsible for your decision to use open source in
connection with Dialogic products (including without limitation those referred to herein), nor is Dialogic responsible for any present or future effects such
usage might have, including without limitation effects on your products, your business, or your intellectual property rights.
July 200905-2640-0033Description of thermal sensor operation added.
May 200905-2640-0022
April 200905-2640-0011Supports the first production release.
Note: The current issue of this guide can be found at:
http://www.dialogic.com/support/helpweb/signaling
Support for introduction of ATM termination mode and
timestamping.
6
®
Dialogic
DSI SS7MD Programmer’s Manual Issue 3
Chapter 1: Introduction
Dialogic® DSI SS7MD Network Interface Boards are specialized T1/E1/J1 SS7 signaling boards suitable for
use in PCI Express form factor systems. The boards use the common Dialogic® DSI software API to the
application that enables applications to be easily ported.
The boards provide a hardware platform to enable running Dialogic
of Signaling System Number 7 signaling nodes. In addition, theDSI SS7MD Boards can be used to build high
performance monitoring applications. The boards can be used under the Linux and Solaris operating
systems.
This manual is the Programmer’s Manual for the Dialogic
is targeted for system developers who are integrating the boards and who have chosen to develop
applications that use the underlying DSI Protocol Stack. The manual includes information on:
®
DSI SS7MD range of network interface boards. It
®
DSI Protocol Stacks for the realization
• software installation
• system configuration
• protocol configuration
• operation of the boards and the SS7 software stack
The manual should be used in conjunction with the appropriate Installation Guide and Regulatory Notice for
the board. These and other supporting documentation, including the Programmer’s Manuals for the individual
protocol modules, are listed in Section 1.1, Related Information.
Note: Users of the Dialogic
Network Interface Boards should refer to separate documentation that covers those boards.
DSI SS7MDL4 PCI Express form factor product line includes the following:
• DSI SS7MDL440Q
A low profile PCI Express form factor with 4T1/E1/J1 ports, supporting up to 124 SS7 links, up to 4 SS7
HSL links, up to 128 Q.SAAL links, or 4 ATM cell streams.
Note: When used in this document, the generic term “DSI SS7MD” is meant to cover both the ”DSI
SS7MDL4” and “DSI SS7MDL440Q” models of the DSI SS7MD Network Interface Boards.
The DSI SS7MDL4 board is a x1 lane electrical, x4 lane physical, low profile PCI Express form factor, which
can be installed in x4, x8, or x16 lane slots. The board is supplied with two End Brackets suitable for low
profile and full height installation. Features of the DSI SS7MDL4 board are described in the following topics:
Factor
• Capacity
• Host Interface
• Physical Interfaces
• Protocol Resource Support
• Visual Indicators
• Power Requirements
• Environmental Specification
• Safety, EMC and Telecommunications Specifications
• Reliability
2.2.1Capacity
The capacity of the DSI SS7MDL4 board is described as follows:
• Digital interfaces
— Four T1/E1 or J1 (software selectable)
— High impedance software selectable
• SS7 links
Terminate or monitor up to
Table 1. SS7 Link Termination or Monitoring Capacity of the Dialogic® DSI SS7MDL4 Network
Interface Board
Link typeMax. number of links per board
Q.703 LSL (64kbit/s)124
Q.703 LSL (56kbit/s)123
Q.703 LSL (48kbit/s)123
Q.703 Annex A HSL Framed4
Q.2140/Q.2110 Q.SAAL links
(terminated)
AAL5 (including Q.SAAL) links
(monitored)
ATM cell streams4
Note: In order to monitor both directions of a signaling link, the user must separately connect each
direction of the signaling link to the receive connection of two different LIUs on the DSI SS7MDL4
board.
• Dialogic
MTP2 on board; other
2.2.2Host Interface
The DSI SS7MDL4 board has a x1 electrical, x4 physical PCI Express connector. It can be installed in x4, x8,
or x16 PCI Express slots.
®
DSI Protocol Stacks
protocols are host-based
128
128
Note: The DSI SS7MDL4 board is a high performance densely packed low profile PCIe board supporting
high message rates. In achieving this performance, the board may dissipate up to 17W and this
must be taken into consideration when selecting both the host chassis and the PCI Express slot in
11
2 Specification
which to install the board. Refer to Section 2.2.7, “Airflow Requirements” on page 13 for more
information.
2.2.3Physical Interfaces
The DSI SS7MDL4 board supports the following physical interfaces:
• Four T1/E1/J1/J1 digital trunk interfaces. See Section 2.2.3.1 below for more detail.
2.2.3.1T1/E1/J1 Digital Trunk Interface Properties
The properties of the T1/E1/J1 digital trunk interfaces are described as follows:
• Standard
— Four interfaces each are software configurable as either T1, E1, or J1
— High impedance software selectable
• Pulse mask
— T1: ANSI T1.403
— E1: ITU-T G.703
— J1: TTC JT-G.703
• Data rate
— T1: 1544 kbits/s ± 50 ppm
— E1: 2048 kbits/s ± 50 ppm
— J1: 1544 kbits/s ± 50 ppm
• Frame format
— T1: F4, D3/D4, ESF, and F72/SLC96
— E1: E1 and E1-CRC4
— J1: J1 frame format
• Line codes
— T1: B8ZS and AMI
— E1: HDB3 and AMI
— J1: B8ZS and AMI
• Connector type
— RJ-48C
2.2.4Protocol Resource Support
When used in a signaling node, the DSI SS7MDL4 board supports the Message Transfer Part (MTP) running
on the board and optionally other protocols including MTP3, ISUP, TUP, SCCP, TCAP, MAP, INAP and IS41
running on the host. The protocols are enabled by software licenses. SeeSection 2.3, “Software Licenses” on
page 15.
The DSI SS7MDL4 board supports passive monitoring of HDLC format data links including, for example, SS7,
LAPB, LAPD, ISDN, and DPNSS. In this mode, the received messages are directly reported to the application.
For more information on link monitoring, see Section 4.6, “Monitoring” on page 34.
It is possible to use monitor and receive-transmit protocol operations concurrently on the same signaling
board.
12
®
Dialogic
DSI SS7MD Programmer’s Manual Issue 3
2.2.5Visual Indicators
The DSI SS7MDL4 board includes the following visual indicators:
• T1/E1/J1 dual-color Green/Red status LEDs:
— Green indicates a valid link
— Red indicates a line alarm
Note: Only the LEDs 0, 1, 2, and 3 are active (LEDs 4, 5, 6, and 7 are reserved for future use).
2.2.6Power Requirements
Power requirements are described as follows:
• +12 VDC power
1.1 A typical, 1.4 A max.
• Power dissipation
17 W max.
2.2.7Airflow Requirements
The board should be installed in host computers providing an airflow of at least 300 linear feet per minute
(LFM), 1.5 m/s. This airflow should be evenly distributed across the board. See Appendix B, “Thermal
guidelines for selecting suitable servers for use with a Dialogic® DSI SS7MDL4 Network Interface Board”.
2.2.8Environmental Specification
Environmental specification is described as follows:
• Operating temperature range
+0°C to +55°C
• Storage temperature range
-20°C to +70°C
• Humidity
5% to 95% non-condensing
• Altitude
0 to 15,000 ft
• Vibration
0.1 g, 5 to 100 Hz
• Shock
Packaged equipment drop test 29.5 in (750 mm)
13
2 Specification
2.2.9Safety, EMC and Telecommunications Specifications
Safety, EMC and telecommunications specification information is provided by the following:
• Dialogic
Supplied with each product and provides a full list of the specifications to which DSI SS7MDL4 board
conforms.
The DSI SS7MDL4 codefile supports different MTP2 link densities on the board. These are enabled using a
Host Software License that is to be ordered at the same time as the hardware. The Host Software License
licenses a specific number of link resources on the host that may be shared between boards in the same
chassis.
For details on how to activate the host license please refer to Dialogic® DSI Protocol Stacks - Host Licensing User Guide U32SSS at http://www.dialogic.com/support/helpweb/signaling.
A combination of link types (provided they are supported by the board’s run mode) may be configured by the
host (on any board) provided the required link resources are available. A configured link’s resources are
freed when either the link is unconfigured or the board on which the link is currently active is reset.
The following table shows the available licenses:
Software LicenseCodeLink Resources
SW LICENSE, 16 LSLSS7SBMDM1616
SW LICENSE, 32 LSL or 1 MTP or ATM HSLSS7SBMDM3232
SW LICENSE, 64 LSL, 2 MTP or ATM HSLSS7SBMDM6464
SW LICENSE, 128 LSL, 4 MTP or ATM HSLSS7SBMDM128128
SW LICENSE, 256 LSL, 8 MTP or ATM HSL SS7SBMDM256256
The number of link resources required for each link type is shown below:
Link TypeResources Required
LSL (64Kb / 56Kb / 48Kb)1
Monitored LSL0.5
HSL (2Mb / 1.5Mb)32
Monitored HSL16
ATM (2Mb / 1.5Mb)32
Monitored ATM16
Note: IMA bundles are licensed based on the number of ATM cell streams they contain.
2.3.1Run Modes
The run mode of a board determines the combination of protocols (LSL/HSL/ATM/IMA) available to the host.
ValueRun ModeProtocols Selected to Run on the Board
34LSLMTP2 Low Speed Links
35HSLMTP2 High Speed Links
36ATMATM links
37IMAInverse Multiplexed ATM links
15
2 Specification
The following combinations of link types are available to the user:
Run ModeLSL LinksHSL LinksATM LinksIMA Links
LSLYYY
HSLYYY
ATMYYY
IMAYY
Note: When using multiple link types on the same board, the run mode indicates to the board the
predominant link type.
Note: To change the run mode of a board, the board must be reset.
16
®
Dialogic
DSI SS7MD Programmer’s Manual Issue 3
Chapter 3: Installation
This chapter contains the following topics:
• Software Packages
• Software Installation for Linux
• Software Installation for Solaris (SPARC)
17
3 Installation
3.1Software Packages
This manual describes the installation and use of the following software:
• Development Package
• User Part Development Package
• Binary for Dialogic
3.1.1Development Package
Different variants of the Development Package are available for the supported operating systems. Each
Development Package contains:
®
DSI SS7MD Network Interface Boards
• a device driver
• library functions and header files for use by an application
• a number of executables to be run as part of the software environment
• a utility to configure the protocol software
Instructions for installing each variant of the Development Package are provided later in this chapter.
3.1.2User Part Development Package
The User Part Development Package contains:
• protocol-specific header files for use when building an application
• example source code to illustrate the techniques used for interfacing with the protocol modules
This package is distributed as a ZIP file and a tar file. Both distributions have the same content and are
applicable to all supported operating systems. The contents of the User Part Development Package should be
extracted onto the development machine retaining the sub-directory structure.
3.1.3Binary for Dialogic® DSI SS7MD Network Interface Boards
The binary file contains the operating software for DSI SS7MD Boards. The binary file (also known as the
codefile) is downloaded to the board at runtime by the driver program. Codefiles for DSI SS7MD Boards have
a file suffix .dc6 and should not be confused with codefiles for other products that use different suffixes.
Two code file images are currently available for the DSI SS7MD Board:
• ss7.dc6 codefile includes protocol options SS7 LSL, HSL, and ATM, and a monitoring option
• ima.dc6 codefile includes protocol options ATM and IMA, and support for monitoring these protocols
Other codefiles offering different sets of functionality may also be available. The appropriate codefile is used
in conjunction with the software to determine the protocols that the user is authorized to run.
The codefile must be copied onto the target machine maintaining binary file integrity. Subsequently, the
codefile is downloaded to the board at runtime.
18
®
Dialogic
DSI SS7MD Programmer’s Manual Issue 3
3.2Software Installation for Linux
The Development Package for Linux is distributed as a download from the Dialogic web site. See Section 1.1,
“Related Information” on page 7.
The distribution is in the form of a single compressed file called dpklnx6.Z.
Installation of the software is described in more detail in the following topics:
• Installing the Development Package for Linux
• Installing the DSI SS7MD Source Device Driver
• Support for a Large Number of DSI Messages
• Removing the Development Package for Linux
• RPM Installation
3.2.1Installing the Development Package for Linux
Install the Development Package for Linux on a development system as follows:
1. Login and switch to a user account with root privileges.
2. Create a new directory, referred to as the “install directory”.
The recommended location is /opt/dpklnx.
3. Copy the dpklnx6.Z file to the development system that is running Linux.
Note: Be sure to copy the file with the uppercase Z extension that identifies the file as a compressed
file.
4. Extract the files using the command:
tar -zxvf dpklnx6.Z
Tab l e 2 shows the files that are extracted into the current working directory. A number of additional files
relating to other products in the range are installed at the same time.
Table 2. Files Installed on a System Running Linux
File Name or DirectoryPurpose
libgctlib.so.<x>.<y>.<z>Library to be linked with user's application
INCSub-directory containing header files for use with user’s application
system.txtExample system configuration file
config.txtExample protocol configuration file
gctload
ssdm
tick_lnx
tim_lnx
s7_mgt
s7_log
s7_play
mtpsl
upe
tempmon
SS7MD_DRIVER SS7MD device driver source code together with build and install scripts
Executables for use as described elsewhere in this manual
The /etc/ld.so.conf file should be edited to include the install directory.
The ldconfig utility must be run to update the run linker's configuration:
ldconfig -v
19
3 Installation
The ldconfig utility creates a symbolic link to the GCT library shared object within the install directory.
For example:
/opt/dpklnx:
libgctlib.so.1 -> libgctlib.so.1.0.1
If the installation machine is to be used to build applications, an additional link must be created from
libgctlib.so.1 to libgct.so:
ln -s libgctlib.so.1 libgct.so
3.2.2Installing the DSI SS7MD Source Device Driver
The DSI SS7MD device driver source build and installation scripts are in the Development Package's
SS7MD_DRIVER sub-directory.
3.2.2.1Building the DSI SS7MD Source Device Driver
A build script is included in the SS7MD_DRIVER subdirectory to allow the user to build the appropriate driver
for his system. The DSI SS7MD installation script is named build_ss7md.sh.
To build the script, change into the directory and run the script:
cd /opt/dpklnx/SS7MD_DRIVER
./build_ss7md.sh
The build script assumes that a suitable environment for building kernel modules is available. This must
include the appropriate kernel include files found at: "/lib/modules/'uname -r'/build" (for example:
/lib/modules/2.6.18-92.1.22.el5/build/). If these include files are not found, the build will fail.
The driver is named ss7md.ko.
3.2.2.2Installing the Driver Binary
Install scripts are included in the package to allow the installation of the user-built drivers. The DSI SS7MD
installation script is named install_ss7md.sh.
The script loads the DSI SS7MD device driver, automatically allocates a major device number and creates the
minor device nodes.
./install_ss7md.sh
The DSI SS7MD device driver can be removed by running the install script with the optional remove
parameter:
./install_ss7md.sh remove
Device driver installation and removal must be performed by a user with root privileges.
3.2.2.3Verifying Device Driver Loading
When the device driver is loaded, it outputs status messages to the system log. The system log can be
displayed using the following command:
dmesg | more
Examples of the messages written to the system log by the driver are:
ss7md : found card 0 - type 0x90e5 - SN PX800045
20
®
Dialogic
DSI SS7MD Programmer’s Manual Issue 3
3.2.3Support for a Large Number of DSI Messages
The default Linux configuration may need to be modified to support a large number of DSI messages.
1. Edit the /etc/rc.local (or distribution-specific equivalent) file to add the following line:
sysctl -w kernel.msgmnb=<max_queue_bytes>
where <max_queue_bytes> is set to at least¹ the sum of the number of normal and long DSI messages
allocated by gctload, multiplied by 12.
For example, a system.txt configuration file containing the lines:
NUM_MSGS 1000
NUM_LMSGS 200
Will configure a total of 1,200 DSI messages, so the value should be 1,200 multiplied by 12, giving a value of
14,400:
sysctl -w kernel.msgmnb=14,400
¹ - The kernel.msgmnb values specified are the System V (SYS V) Interprocess Communications (IPC) values
required for the correct operation of DSI messaging. Other application software may use the SYSV IPC
resources and, therefore, their configuration requirements must be added to the kernel.msgmnb total.
2. Save the /etc/rc.local file, then reboot the machine.
3. Verify that this change has taken effect using the sysctl command, for example:
/sbin/sysctl -a
The command prints the Linux configuration, including the entry for the kernel.msgmnb parameter.
3.2.4Removing the Development Package for Linux
Prior to installing a new version of the Development Package for Linux, the previous version should be
removed. This is achieved using the following procedure assuming the user logs on as root:
1. Delete the installed files. See Table 2, “Files Installed on a System Running Linux” on page 19 for a list of
the installed files.
2. Reboot the target machine.
3.2.5RPM Installation
The Development Package also provides support for the generation RPM (RedHat Package Management)
packages.
3.2.5.1RPM Creation Instructions
A number of RPM packages can be created from the Development Package. The RPM packages are created
by executing the following steps:
1. Select a directory to be used when creating the RPM packages.
For this example, “/var/tmp/dpk/rpm” is used.
2. Create a file called “.rpmmacros” in the user account's home directory and enter the location of the
directory from step 1:
5. For 32bit operation systems, the RPM packages are stored in: /var/tmp/dpk/rpm/RPMS/i386/.
For 64bit operation systems, the RPM packages are stored in: /var/tmp/dpk/rpm/RPMS/x86_64/
For example:
Where <ARCH> is i386 for 32bit operation and x86_64 for 64 bit operation systems.
Note: Device driver binaries, including the one for the DSI SS7MD Board, will be built as rpmbuild is
run. Therefore, it is necessary for the machine on which rpmbuild is run to share the same kernel
version as the machine on which the RPM packages will be installed.
3.2.5.2RPM Packages
The following packages are created:
ss7dpk-<DPK>.<ARCH>.rpmRun-time files, including binaries, GCT run-time shared
library and SYSTEM.TXT and CONFIG.TXT configuration
files.
ss7dpk-devel-<DPK>.<ARCH>.rpmDevelopment Package development files, including header
ss7dpk-debuginfo-<DPK>.<ARCH>.rpmRPM build artefact, not required.
3.2.5.3Using the RPM Management Tool
The RPM management tool, “rpm”, is used to maintain packages on a target system. Documentation on how
to use the “rpm” tool is available from www.rpm.org.
Common tasks using the rpm utility include:
1. Installation of an RPM package:
rpm -i <package_name>
2. Removal of an installed RPM package:
rpm -e <package_name>
3. Upgrading an installed RPM package:
rpm -U <package>
4. List all RPM packages on a system:
rpm -qa
22
®
Dialogic
DSI SS7MD Programmer’s Manual Issue 3
3.3Software Installation for Solaris (SPARC)
Installation of the software is described in more detail in the following topics:
• Additional Commands
• Support for Larger Message Queues
• Removing the Development Package for Solaris
• Solaris Interface Name Checking
The Development Package for Solaris is distributed in the form of a compressed file called dpksol64 for use
with 64-bit kernels. This file can be downloaded from
Executables for use as described elsewhere in this manual
23
3 Installation
3.3.1Additional Commands
Customers using Solaris 10 and the DSI SS7MD Boards must perform the following additional commands
after installing the package:
cd/opt/DKseptel
chown root ssdm
chmod +s ssdm
Note: The commands should be executed by a user with super-user permissions.
3.3.2Support for Larger Message Queues
The number of messages available to the system is limited by the number of kernel message headers.
Attempting to use more messages may cause the system to halt. Additional message headers should be
allocated by adding the following lines (with appropriate values) to the file /etc/system:
set msgsys:msginfo_msgmni=50
set msgsys:msginfo_msgtql=10000
The values are read by the kernel at boot time so there is no need to re-build the kernel, just reboot the
system.
The default values for these are given in /usr/include/sys/msg.h.
The new values for these parameters should be set to at least the following values. There may be other users
of these resources so the actual value may need to be greater than the values shown.
• msgmni = At least the number of 'LOCAL' entries in system.txt.
• msgtql = At least the number of MSGs in the system.
3.3.3Removing the Development Package for Solaris
The Development Package for Solaris can be removed using the package removal utility as follows:
pkgrm dpksol64
The Solaris package removal utility (pkgrm) then prompts for further input.
On successful completion of the procedure, the following message is displayed and the user should reboot
the system:
Removal of <dpksol64> was successful.
3.3.4Solaris Interface Name Checking
To use the package under Solaris 9, interface name checking must be disabled. This is done by adding the
following line to the /etc/system file:
set sunddi_netifname_constraints=0
The driver does not start correctly if this line is not added.
Note: This line is not required for installations other than Solaris 9.
24
®
Dialogic
DSI SS7MD Programmer’s Manual Issue 3
Chapter 4: Dialogic® DSI SS7MD Board Configuration and Operation
Before attempting software configuration, you should gain an appreciation of the flexibility of the protocol
stack, the run-time options that exist and the mechanisms that are used to select specific features. This
section gives an overview of these options. You should also read the Software Environment Programmer’s Manual that describes the basic principles of modules and message passing.
This chapter provides information about:
• Regulatory and Geographic Considerations
• System Structure
• Running Host Binaries With Dialogic
®
DSI SS7MD Board
• System Configuration
• Protocol Configuration
• Monitoring
• ATM Monitoring
• Switching Timeslots between LIUs
• Static Initialization
• Received Message Timestamping
• High Speed Link Operation
25
4 Dialogic® DSI SS7MD Board Configuration and Operation
4.1Regulatory and Geographic Considerations
Certain functions of Dialogic® DSI SS7MD Boards, although implemented in hardware, have selectable
options that are configured by the ss7.dc6 codefile. A user or integrator must consider the requirements of
the application when choosing these settings, but must also consider any local regulatory requirements for
the intended deployment location to ensure a compliant overall system. The table below details some of the
areas where the correct selection of configuration options may be required.
Table 4. Quick Reference to Commonly Configured Parameters
Configuration AreaConfiguration Options
Interface typeliu_type parameter in LIU_CONFIG command
Pulse shapeliu_type parameter in LIU_CONFIG command
T1/E1 Ports
LinksLink termination or monitoring mode MTP_LINK or MONITOR_LINK commands
Line codeline_code parameter in LIU_CONFIG command
Frame formatframe_format parameter in LIU_CONFIG command
CRC/E-bit operationCRC_mode parameter in LIU_CONFIG command
Clock prioritiesflags parameter in SS7_BOARD command
26
®
Dialogic
DSI SS7MD Programmer’s Manual Issue 3
4.2System Structure
The Dialogic® DSI Protocol Stacksoftware running on the board communicates with the higher level
protocols running on the main CPU of the host computer. The user’s application may also be running on the
host computer. See Section 4.3, “Running Host Binaries With Dialogic
®
DSI SS7MD Board” on page 28 for
more information. The physical interface to the board uses the PCI Express bus. All communication with the
board is handled by a device driver and all messages passing to and from the board are managed by the
board management and interface process (ssdm, sometimes generically referred to as ssd) that runs on the
host computer.
The board management and interface process (ssdm) is required to run on the host machine. The ssdm
process handles message transfer between the host and the board using the device driver.
The selection of which protocol modules to run on the host is made by editing the system.txt configuration file.
The user then runs the gctload program that reads the system configuration parameters from the system.txt
configuration file and starts the selected processes bringing the system into operation. For further details on
the operation of the gctload program, refer to the Software Environment Programmer’s Manual.
Tab l e 5 shows processes and utilities, for use on the host, that are included in the distribution.
Note: s7_mgt, s7_log and s7_play are optional utilities. A user may choose to implement the functionality
provided by these utilities in their own applications.
Note: Additional files and directories relating to other products in the range are installed at the same
time.
Table 5. Host Processes and Utilities
Process or
Utility
gctload
ssdm
tick_lnx
tick_sol
tim_lnx
tim_sol
s7_mgt
s7_log
s7_play
tempmon
Process to initialize the system environment and start the other related processes running
on the host, deriving the configuration from a text file (system.txt).
Process to interface with the device driver for passing messages to and from the board(s)
and for downloading software to the board(s).
NOTE: This process is referred to in a generic manner as 'ssd' although the name of the
Protocol timer process to send periodic tick notification to the tim_xxx process that in turn
handles protocol timers.
Process to receive periodic tick notification from tick_xxx and handle protocol timers for all
other processes.
Process to perform one time protocol configuration for the protocol modules, deriving the
configuration parameters from a text file (config.txt). This process is optional. As an
alternative to using it, the user may elect to perform protocol configuration by sending
messages directly to the other modules in the system. Refer to Appendix A, “Protocol
Configuration Using Discrete Messages” for more information.
Utility process to allow messages received from the protocol stack to be logged to a text file.
This is useful for diagnostic purposes when getting started. Refer to Section 8.1, “s7_log” on
page 162 for more information.
Utility process used to generate messages from a text file and send them into the system.
This is useful for diagnostic purposes when getting started. Refer to Section 8.2, “s7_play”
on page 165 for more information.
Utility process that runs in isolation from the GCT environment and periodically reads back
the temperature, as recorded by the on-board temperature sensor, of all SS7MD boards
present in the system and logs these together with the date, time, and board serial
numbers. This permits the user to evaluate the suitability of a host chassis for deployment.
Refer to Section 8.8, “tempmon” on page 175 for more information.
Purpose
binary for use with DSI SS7MD Boards is in fact 'ssdm'.
27
4 Dialogic® DSI SS7MD Board Configuration and Operation
4.3Running Host Binaries With Dialogic® DSI SS7MD Board
The Dialogic® DSI MTP2 Layer protocol module runs on the board. The other SS7 protocol modules (MTP3,
ISUP, TUP, SCCP, TCAP, MAP, INAP, and IS41) must be run on the host machine.
Host protocol software is available for Linux and Solaris SPARC operating systems. For more information or
to purchase, contact an authorized distributor or your account manager.
28
®
Dialogic
DSI SS7MD Programmer’s Manual Issue 3
4.4System Configuration
System configuration is handled by the gctload program that reads system configuration data from a file
called system.txt. System initialization requires:
• First, that a pool of message buffers is created for subsequent inter-process communication.
• Second, that a message queue is created for each process that will run and that any message redirection
for modules that are running remotely is initialized.
• Finally, that all processes can be started.
The gctload program handles this initialization sequence and creates the inter-process communication
environment. The program reads input from the system.txt configuration file, carries out all system
initialization and starts all processes.
The system.txt configuration file is a user-configurable file containing details of the module identifiers known
to the system, details of whether they are local modules or remote modules accessed by a local module
(message redirection), and includes the command line for the processes to be started by the gctload
program.
The gctload program creates a message queue for each of the local module identifiers. The program
subsequently expects a process to service its message queue; otherwise messages written to that queue will
never be read causing eventual loss of system messages.
The gctload program initializes the message queue look-up table so that messages destined for modules that
do not exist locally are redirected to a message queue for a module that exists locally.
Having created the system environment, the gctload program proceeds to spawn the processes listed in the
system.txt configuration file in the order listed.
Note: Prior to running the gctload program, the system.txt configuration file must be edited to reflect the
requirements of your system.
4.4.1System Configuration File Syntax
The system.txt configuration file is a text file used by the gctload program to configure the software
environment. The file syntax permits the use of comments to improve the readability of the file. See the
Software Environment Programmer's Manual for more information about this file.
An example system.txt configuration file is shown below:
********************************************************************************
*
* Example System Configuration File (system.txt) for use with
* the Linux Development Package for Dialogic(R) SS7 Boards
*
*
********************************************************************************
*
* Essential modules running on host:
*
**
LOCAL0x20* ssdm - Board interface task
LOCAL0x00* tim_lnx - Timer task
*
* Optional modules running on the host:
*
LOCAL0xcf* s7_mgt - Management/config task
LOCAL0x2d* upe - Example user part task
*
* Modules logically running on the board (all redirected via ssdm):
*
REDIRECT 0x10 0x20 * LIU-Switch Management Module
REDIRECT 0x8e 0x20 * Board Management Module
REDIRECT 0x31 0x20 * ATM Module
REDIRECT 0x41 0x20 * Q.SAAL Module
REDIRECT 0x70 0x20 * Signalling Driver Module
REDIRECT 0x71 0x20 * SP0 MTP2 Module
*
29
4 Dialogic® DSI SS7MD Board Configuration and Operation
NUM_MSGS 1000* Number of standard size messages
*
* Optional Modules that run on the host:
*
* LOCAL 0x23* ISUP module
* LOCAL 0x4a* TUP module
* LOCAL 0x33* SCCP module
* LOCAL 0x14* TCAP module
* LOCAL 0x22* MTP3 module
*
*
* Redirection of status indications:
*
REDIRECT 0xdf 0x2d * LIU/MTP2 status messages -> upe
REDIRECT 0xef 0x2d * Other indications -> upe
*
* Start-up all local tasks:
*
FORK_PROCESS ./ssdm
FORK_PROCESS ./tim_lnx
FORK_PROCESS ./tick_lnx
FORK_PROCESS ./s7_mgt
FORK_PROCESS ./upe
This section describes the procedure for generating a system.txt configuration file and details any operating
system specific differences in behavior among the development packages.
First, the file must contain LOCAL declarations for all modules that are to run on the host computer. At a
minimum, this must include the ssdm module and the timer module. Hence, the following declarations must
exist:
LOCAL declarations are also required for any optional modules running on the host. Typically, this includes
the s7_mgt protocol configuration utility and the user's own application module. It may also include any host-
based protocol modules and the s7_log utility. For example:
LOCAL0xcf* s7_mgt - Management/config task
LOCAL0x2d* upe - Example user part task
LOCAL0x3d* s7_log - Prints messages to screen/file
LOCAL0x22* MTP3 module
Once all the LOCAL declarations are in place, REDIRECT commands should be added for all modules that are
logically running on the board so that any messages destined for these modules are transported via the ssdm
module (module_id = 0x20).
The following REDIRECT commands are always required:
Having ensured that all modules running on the board are accessible, it is then necessary to ensure that any
status indications issued from the board successfully arrive at a module running on the host. If this does not
happen, the system quickly runs out of available messages for inter-process communication.
Two module_ids (0xdf and 0xef) require redirection to a suitable process running on the host; initially these
messages should be redirected to the s7_log utility that prints out a line for each message received.
Ultimately, the user's own application should deal with these notifications.
REDIRECT0xdf 0x3d* LIU/MTP2 status messages -> s7_log
REDIRECT0xef 0x3d* Other indications -> s7_log
30
Loading...
+ 161 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.