STP/SCP SR5129/SR4959 Gateway System

For

Telcordia NetPilot Message Router Access

SMS800 SCP Interface Access

 

Prepared By:

Contact: Sally S. Lee

E-mail: Sally.Lee@SynercomSoftware.com

 

 

Introduction:

SynerCom Inc. is pleased to offer an STP/SCP-SR5129 solution software package to enable customer to connect to the Telcordia CCS Message Routers (CCSMR) via the new ASN.1/TCP protocol as defined in Telcordia SR5129 – Common Channel Signaling (CCS) Message Router (MR) to Network Element (NE) Interface Specification. This software package will provide customer with the following features:

The STP-SR5129 solution software package is delivered in either read-to-run binary code licensing or source code licensing. The source code can be compiled and linked by ANSI standard C/C++ compiler under Sun Solaris Operating System running on either Sun SPARC or Intel platform. The binary code delivery has been fully tested on both Sun SPARC and Intel platforms running under Sun Solaris. The software has been deployed with High Availability architecture on a pair of Sun SPARC machines in production mode by a major telecommunication carrier.

The source code of STP-SR5129 solution software is coded in ANSI C/C++ language. It uses POSIX-conformance APIs and X/OPEN TCP Socket Interfaces. It also contains a set of standalone ASN.1/BER encode and decode routines. Other than Solaris operating system, it needs no other third party software system to compile/link and run. This enables the system be easily ported to other UNIX or POSIX-conformance development and runtime environment.

The performance throughput of this software package has been benchmark tested on a single processor Intel Pentium-II 400Mz CPU platform, it can process 100 messages per second with a constant message size of 550 bytes each.

General System Descriptions:

This software system implements the ASN.1/BER/TCP interface protocol as defined in Telcordia Document SR5129. It can be used as a front-end telecommunication system for customer’s existing STP-UPL or SCP-UPL system to interface with Telcordia CCSMR systems. It contains the following major features:

Detailed Software Component Descriptions:

 

Proposed Customer STP-UPL/CCSMR Architecture

The following diagram depicts the proposed system architecture for customer as a STP-UPL system to access CCSMR system through SR5129 ASN.1/TCP protocol. The shaded boxes represent the production processes needed to support the STP-UPL/CCSMR interfaces. The dotted boxes represent the existing STP-UPL application processes. The non-shaded boxes represent the SR5129 TCP connections to Telcordia CCMSR system.

Application Interface

To simplify the implementation on the existing application side of the customer STP-UPL system, it is proposed that two TCP sockets, one for send and one for receive, to be used on the application side. By using one-way TCP session with application, the UPL-Application-Send and UPL-Application-Receive processes can be implemented by using single threaded blocking-IO TCP sockets. This will simplify the implementation while still maintains high performance throughput. The library of APIs for the UPL-Application is available in this software package offering.

The STP-Send-Queue process will try to receive and enqueue (FIFO) messages from application. The queue will be used if UPL-Application-Send process is sending faster than CCSMR can receive. If the queue is full due to CCSMR slowdown or shutdown, "back pressure" for TCP receive will be applied to Application-Send TCP socket to enable flow control. In this case, the TCP socket in the Application-Send process will be blocked. Therefore, no STP-UPL outbound messages will be lost during congestion.

The STP-Receive process will send as fast as UPL-Application-Receive process can receive. If UPL-Application-Receive process suspends receiving, the STP-UPL-Receive process will apply "back pressure" to the SR5129 TCP Gateway process which in turn propagates "back pressure" to the CCSMR TCP sessions. No messages from CCSMR will be lost during congestion.

The recommended message structure of the application interface supported by APIs is defined as follows:

  1. First four bytes – Message Delimiter (MD) flag must be different from the SR5129 MD flag (e.g. hex’7F7F7F7F’).
  2. Second four bytes – a four-byte binary field represents the length of the message (UPL Header + UPL data) – same format as defined in Message Delimiter (MD) of SR5129.
  3. Next 27 bytes (9 to 36 byte) - UPL Header as defined in SR5129
  4. 37 byte to the end of the message – UPL data as defined in SR5129

SR5129 TCP Gateway process

This gateway process provides one or more TCP full-duplex sessions with CCSMR as defined in SR5129. It maintains connections to CCSMR automatically. It provides both TCP server and client functions. If CCSMR makes connection request, it will accept the connection. If any of the CCSMR ports are not available, it will periodically try to make connection request to them. Once the connections are made, they will be maintained active at all times.

For STP outbound messages from the STP Send-Queue or STP-TEST-SEAS-UPL-Send processes, the Gateway process distributes the messages across all available CCSMR TCP sessions evenly in a round-robin fashion. All messages except the TEST-SEAS-UPL and RSP:TEST messages received from CCSMR are forwarded to STP-Receive process. The TEST-SEAS-UPL messages from CCSMR are forwarded to the STP- RSP:TEST Respond process. The RSP:TEST messages from CCSMR are forwarded to the STP-TEST-SEAS-UPL Send process.

At any time, if any CCSMR ports are not receiving fast enough for the Gateway process to dequeue messages from the STP side, "TCP back pressure" on receive will be applied to all STP sending processes. If any of the STP Receive processes are not receiving fast enough for the Gateway process to dequeue messages from the CCSMR side, "TCP back pressure" on receive will be applied to all CCSMR sending ports. No messages will be dropped during congestion situations.

STP TEST-SEAS-UPL Send process

This process will be scheduled by system administrator on-demand to test the connections between the STP and CCSMR by sending TEST-SEAS-UPL messages (defined in TA-TSY-000310) to CCSMR. This process will generate TEST-SEAS-UPL test messages with "number of messages sent" and "message size" selectable by the user. It will then wait for the corresponding RSP:TEST messages to return. A report will be generated detailing the total number of messages sent and received at the end of the test.

STP RSP:TEST Respond process

This process will receive all TEST-SEAS-UPL messages sent by CCSMR. It will generate the RSP:TEST messages back to CCSMR as specified by TA-TSY-000310.

 

Proposed Customer STP/CCSMR High Availability Deployment

Telcordia CCSMRs are mostly deployed as loosely coupled pairs in order to provide high availability architecture. To match the high availability interface to CCSMRs, the STP-SR5129 software can also be deployed on dual machine environment as depicted in the following diagram.

Where CCSMR-A and CCSMR-B represent a pair of loosely coupled Message Router machines. The STP UPL-Application Send and Receive processes now have alternative paths to dual SR5129 Gateway machines. The cross connections of TCP sessions between the CCSMR machines and SR5129 Gateway machines eliminate a single point of failure for CCSMR and STP SR5129 communications.

Proposed Customer STP/CCSMR Test Environment

If SR5129 ASN.1/TCP internal testing is desired in the customer facility, a test environment with CCSMR simulator is also included in the STP-SR5129 Solution Package. The following diagram describes an internal STP/CCSMR test environment provided by this package.

A number of CCSMR ports can be simulated. Each CCSMR-Port process may connect to a CCSMR RSP:TEST Respond process to process the incoming TEST-SEAS-UPL messages received from STP. An CCSMR TEST-SEAS-UPL-Send process can be constructed to send TEST-SEAS-UPL from CCSMR and receives RSP:TEST messages returned from STP.

UPL Messages other than TEST messages can be routed to an Any-Msg-Display process, which will store messages into a trace file for later examination. An Any-Msg-Send process can also be constructed to send one or more UPL messages from a file to STP.

More customized testing processes can be created via the powerful API library developed by SynerCom Inc.