Internet DRAFT - draft-glaude-ss7-gw
draft-glaude-ss7-gw
Internet Engineering Task Force Authors
INTERNET DRAFT Normand Glaude
Transport Working Group Tom Blain
November 27 1998 Reg Cable
Expires: June 1999 MicroLegend Telecom Systems Inc.
SS7 to IP Signaling Gateway Transport Architecture
<draft-glaude-ss7-gw-00.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This memo defines an architectural framework for transporting SS7
signaling information over Internet Protocol networks. It describes a
Signaling Gateway which acts as a bridge between the SS7 and IP
networks. The Signaling Gateway can be configured as an SS7 end-node
or as a Signal Transfer Point (STP) deployed singly or in a mated pair
configuration. An application program interface (API) allows multiple
remote devices, such as Media Gateways and Media Gateway Controllers,
to register with the Signaling Gateway using TCP or UDP. The API
consists of MTP and SCCP primitives which remote devices can use to
send and receive ISUP and TCAP messages to effect PSTN call control and
access Intelligent Network databases. The MTP and SCCP primitives
ensure that application states (available, unavailable or congested)
are propagated into the SS7 network.
This memo also identifies some functional and performance requirements
for SS7 signaling transport to IP-based application processes residing
on one or more client hosts.
Glaude, Cable, Blain [Page 1]
Internet draft SS7/IP Signaling Gateway November 27, 1998
Table of Contents Page
1.0 INTRODUCTION................................................. 4
1.1 Overview..................................................... 4
2.0 Signaling Gateway Architecture............................... 7
3.0 TCP/IP Socket Connection Performance......................... 8
3.1 Delaying of packets.......................................... 8
3.2 Non-Blocking Interface....................................... 8
3.3 Detection of IP Network Failure.............................. 9
3.4 Fragmentation of Messages.................................... 9
3.5 Signaling Gateway Message Header............................. 9
3.5.1 Message Header Formatting.................................... 9
3.5.2 Header Processing and Procedures............................ 10
4.0 MTP INTERFACE............................................... 11
4.1 Signaling Gateway MTP Message Format........................ 11
4.2 MTP Primitives.............................................. 14
4.2.1 MTP-TRANSFER................................................ 14
4.2.2 MTP-PAUSE................................................... 15
4.2.3 MTP-RESUME.................................................. 15
4.2.4 MTP-STATUS.................................................. 16
4.3 Signaling Gateway MTP User Part Management.................. 17
4.3.1 SG-REGISTER-UP.............................................. 18
4.3.2 SG-REGISTER-UP-ACK.......................................... 19
4.3.3 SG-DEREGISTER-UP............................................ 19
4.3.4 SG-DEREGISTER-UP-ACK........................................ 19
4.3.5 SG-MTP-LOCAL-STATUS......................................... 20
4.4 Configuring the MTP Interface............................... 21
5.0 SCCP INTERFACE.............................................. 21
5.1 Signaling Gateway SCCP Message Format....................... 22
5.2 SCCP Primitives............................................. 24
5.2.1 N-UNITDATA.................................................. 25
5.2.2 N-NOTICE.................................................... 26
5.2.3 N-COORD..................................................... 26
5.2.4 N-STATE..................................................... 27
5.2.5 N-PCSTATE................................................... 27
5.3 Signaling Gateway SCCP User Part Management................. 27
5.3.1 N-REGISTER.................................................. 28
5.3.2 N-DEREGISTER-SSN............................................ 28
5.4 SCCP Parameters............................................. 29
5.4.1 SCCP-CALLED-ADDR............................................ 29
5.4.2 SCCP-CALLING-ADDR........................................... 29
5.4.3 SCCP-QUALITY-OF-SERV........................................ 30
5.4.4 SCCP-USER-DATA.............................................. 30
5.4.5 SCCP-REASON-FOR-RET......................................... 30
5.4.6 SCCP-AFFECTED-USER.......................................... 30
5.4.7 SCCP-CONFIRM-STATUS......................................... 31
5.4.8 SCCP-SS-MULTI-IND........................................... 31
5.4.9 SCCP-USER-STATUS............................................ 31
5.4.10 SCCP-AFFECTED-DPC........................................... 31
5.4.11 SCCP-SP-STATUS.............................................. 32
5.4.12 SCCP-REGISTER-USER.......................................... 32
5.4.13 SCCP-REGISTER-USER-ACK...................................... 33
5.4.14 SCCP-DEREGISTER-USER........................................ 33
Glaude, Cable, Blain [Page 2]
Internet draft SS7/IP Signaling Gateway November 27, 1998
Table of Contents (cont.) Page
5.4.15 SCCP-DEREGISTER-USER-ACK.................................... 33
5.4.16 SCCP-ROUTING-LABEL.......................................... 34
5.5 Configuring the SCCP Interface.............................. 35
6.0 SAMPLE APPLICATION.......................................... 38
6.1 Setup....................................................... 38
6.2 Operation................................................... 38
6.3 Shutdown.................................................... 38
7.0 Future Enhancements......................................... 39
8.0 Authors Addresses........................................... 39
List of Figures Page
1.0 SS7 End Node - Signaling Gateway Functional Model............ 5
2.0 SS7 STP - Signaling Gateway Functional Model................. 6
3.0 Signaling Gateway Architecture............................... 7
List of Tables Page
1 SG Message Header Format.................................... 10
2 SG Message Header Commands.................................. 10
3 SG MTP Message Format....................................... 12
4 SG MTP Message Types........................................ 13
5 SG MTP Message Cause Values................................. 13
6 MTP Primitives.............................................. 14
7 MTP-Transfer Parameters..................................... 15
8 MTP-Pause Parameters........................................ 15
9 MTP-Resume Parameters....................................... 16
10 MTP-Status Parameters....................................... 16
11 MTP-Status Causes........................................... 17
12 SG MTP User Part Management messages........................ 18
13 SG-REGISTER-UP Parameters................................... 18
14 SG-REGISTER-UP-ACK Parameters............................... 19
15 SG-DEREGISTER-UP Parameters................................. 19
16 SG-DEREGISTER-UP-ACK Parameters............................. 20
17 SG-MTP-LOCAL-STATUS......................................... 20
18 SG SCCP Message Format...................................... 22
19 Signaling Gateway SCCP Message Type......................... 23
20 SCCP Parameter Identifier Values............................ 24
21 SCCP Primitives............................................. 25
22 N-UNITDATA Parameters....................................... 25
23 N-NOTICE Parameters......................................... 26
24 N-COORD Parameters.......................................... 26
25 N-STATE Parameters.......................................... 27
26 N-PCSTATE Parameters........................................ 27
27 Signaling Gateway SCCP User Part Management Primitives...... 27
28 N-REGISTER Parameters....................................... 28
29 N-DEREGISTER Parameters..................................... 28
30 SCCP-CALLED-ADDR Format..................................... 29
31 SCCP-QUALITY-OF-SERV Format................................. 30
32 SCCP-AFFECTED-USER Format................................... 30
33 SCCP-AFFECTED-DPC Format.................................... 31
34 SCCP-SP-STATUS Value........................................ 32
35 SCCP-REGISTERED-USER Format................................. 32
Glaude, Cable, Blain [Page 3]
Internet draft SS7/IP Signaling Gateway November 27, 1998
1.0 Introduction
This document describes an SS7 to TCP/IP interface architecture for
transport of signaling messages between PSTN and IP based networks.
1.1 Overview
The Signaling Gateway (SG) architecture allows remote devices, such
as Media Gateway Controllers and Media Gateways, to exchange messages
with an SS7 network via an application program interface over TCP or
UDP. The interface between remote device applications and the Signaling
Gateway consists of messages and procedures that are described in this
draft document.
The messages are based on MTP primitives defined in GR-246 T1.111.1,
and on SCCP primitives defined in GR-246 T1.112.1. The messages allow
the user to take advantage of the flexibility offered by a Signaling
Gateway that can be configured as an SS7 End Node or as a Signal
Transfer Point (STP).
The Signaling Gateway can be configured as an end node with 'A' links
to a pair of STPs. It also has the capability to be deployed as an STP,
based on the model proposed in GR-82-CORE Bellcore recommendation.
It can be deployed singly or in a mated pair configuration, using
SS7 network capabilities to support load sharing and redundancy.
Global Title Translation and Gateway Screening applications may also
be provided in an Signaling Gateway STP configuration.
Glaude, Cable, Blain [Page 4]
Internet draft SS7/IP Signaling Gateway November 27, 1998
End-Node End-Node
Signaling Gateway Signaling Gateway (opt)
+---------------+ +--------------+
| | SG-SG transport | |
PSTN<-------->[SG] <--+---------O------------+--> [SG] |
signal | | | | | |
+-------|-------+ +-----|--------+
| |
O O
| |
+-------|-------+ +-----|--------+
| | | MC-MC signaling | | |
| [SA] <---+--------O-------------+--> [SA] |
| [MC] | | [MC] |
| | | | | |
+-------|-------+ +-----|--------+
Gateway | controller Gateway |Controller (opt)
O O
| |
+-------|-------+ +-----|--------+
| | | | | |
<-IMT--+---->[MG] <---+-----RTP stream-------+-> [MG] <----+-IMT-->
| | | |
+---------------+ +--------------+
Media gateway Media gateway
Figure 1: SS7 End Node - Signaling Gateway Functional Model
Notes:
- IMT stands for Inter-Machine Trunk
Glaude, Cable, Blain [Page 5]
Internet draft SS7/IP Signaling Gateway November 27, 1998
PSTN STP PAIR PSTN STP PAIR (opt)
+-------+ +-------+ +-------+ +-------+
| / | | / | | / | | / |
| / +---+ / | | / +---+ / |
| / | | / | | / | | / |
+--+--+-+ +-+--+--+ +--+--+-+ +-+--+--+
| \ / | | \ / |
| \ / | QUAD | \ / |
| \ / | SS7 | \ / |
| X | "B" LINKS | X |
| / \ | | / \ |
| / \ | | / \ |
| / \ | | / \ |
+--+--+-+ +-+--+--+ +-+---+-+ +-+--+--+
|[SG] / | | / | STP - | / | | / |
| / | | / | Signaling | / | | / |
| /[STP]| | / | Gateway | / | | / |
+-----|-+ +--|----+ Pairs +-----|-+ +--|----+
| | | |
| | Dual | |
O O TCP/IP O O
| | Socket | |
| | Connections | |
+-|--------|--+ +-|--------|---+
| \ / | MC-MC signaling | \ / |
| [SA] <---+--------O----------+--> [SA] |
| [MC] | | [MC] |
| | | | | |
+-----|-------+ +-----|--------+
Gateway | controller Gateway | Controller (opt)
O O
| |
+-------|-------+ +-----|--------+
| | | | | |
<-IMT--+---->[MG] <---+----RTP stream-----+-> [MG] <----+-IMT----->
| | | |
+---------------+ +--------------+
Media gateway Media gateway
Figure 2: SS7 STP - Signaling Gateway Functional Model
The Signaling Gateway should support a point code aliasing feature
called "virtual point code emulation". To the network, a virtual point
code appears, and is used in the same way as, the alias point code
of an STP pair. The Signaling Gateway virtual point codes concept
supports all level 4 applications such as trunk signaling and SCCP.
Glaude, Cable, Blain [Page 6]
Internet draft SS7/IP Signaling Gateway November 27, 1998
2.0 Signaling Gateway Architecture
The Signaling Gateway contains a complete SS7 protocol stack up to the
SCCP layer. It may use BSD sockets over TCP to communicate with
applications registered as users of the SCCP layer and of the MTP
layer.
Since the MTP and the SCCP layers are implemented as separate tasks on
the Signaling Gateway, the API interfaces use different ports to
discriminate between the MTP and the SCCP modules.
Figure 3 describes the Signaling Gateway architecture and a simple
application to both layers.
+---------------+ +----------------+
| | | |
| MTP USER | | SCCP USER |
| APPLICATION | | APPLICATION |
| | | |
+-------|-------+ +-------|--------+
| TCP/IP | TCP/IP
O SOCKETS O SOCKETS
| |
+----------|---------------------------------|-------------+
| | | |
| | +---+-------|----+---+ |
| | | | SCCP PORTS | | |
| | | +------------+ | |
| | | SS7 SCCP LAYER | |
| | +-----------|--------+ |
| | | |
| +---+---|---------------------------------|----+---+ |
| | | MTP PORTS | | |
| | +------------------------------------------+ | |
| | SS7 MTP LAYER | |
| +--------------------------------------------------+ |
| |
| Signaling Gateway |
+----------------------------------------------------------+
Figure 3 - Signaling Gateway Architecture
Multiple applications can register onto the same socket for both MTP
and SCCP ports. Applications can establish one or more socket
connections to both MTP and SCCP layers.
Registered applications must be unique within the Signaling Gateway.
For example, registration parameters for the MTP layer are the point
code and the SIO. Only one application can register with the MTP layer
for a given combination of point code and SIO. For SCCP users, only one
application can register with the SCCP layer for a given combination of
point code and subsystem number.
Glaude, Cable, Blain [Page 7]
Internet draft SS7/IP Signaling Gateway November 27, 1998
3.0 TCP/IP Socket Connection Performance
In establishing a socket connection to the Signaling Gateway, there are
a number of considerations about the intent TCP/IP and its usability in
a near real-time context. This section examines a few concerns and
exposes the solutions that can be used to provide a higher quality of
service.
3.1 Delaying of packets
TCP/IP was originally designed for supporting multiple user sessions
over a slow network. In order to optimize network utilization, the
Nagle algorithm was introduced for keyboard input users. Essentially,
this algorithm delays the transmission of a packet until a sufficiently
large transmit buffer is accumulated or until a certain period of time
(usually around 200 milliseconds) elapses.
Due to the real-time nature of SS7 traffic, it best advised to disable
the Nagle algorithm for socket communication with the Signaling
Gateway. Not disabling this feature would introduce unnecessary delay
in the flow of SS7 messages.
On most UNIX based platforms, the Nagle algorithm can be disable by
issuing the following system call on the socket's file descriptor:
Example 1
Setting the TCP_NODELAY Option
/* set the TCP No-delay flag (disable Nagle algorithm) */
int flag = 1;
setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(flag));
Most other languages and platforms have a similar feature to disable
the Nagle algorithm, usually known as the TCP_NODELAY option.
3.2 Non-Blocking Interface
By default, most operating systems provide a blocking interface for
TCP/IP sockets. Although it may allow for an improved error recovery
scheme, it has an impact on the performance of the communication
channel. Essentially, a system call such as send() with blocking
interface never returns until the operating system confirms that the
message was successfully stored in the transmit buffer.
It may be desirable for user parts of the Signaling Gateway to use a
non-blocking interface in order to improve performance and to support
asynchronous events using the select() function call on a UNIX based
architecture. A non-blocking socket interface can be setup by using
the following call on the newly created socket.
Glaude, Cable, Blain [Page 8]
Internet draft SS7/IP Signaling Gateway November 27, 1998
Example 2
Setting the O_NONBLOCK Option
/* set the socket to non blocking */
fcntl( fd, F_SETFL, O_NONBLOCK );
Most other languages and platform have a similar feature.
3.3 Detection of IP Network Failure
As mentioned previously, the original goal of TCP/IP was to provide a
reliable connection-oriented session between to remote computers across
a slow and unreliable network. In trying to achieve this, an elaborate
retransmission scheme was designed and implemented, allowing for
network failures to be undetected under a no load situation, and a
retry period of up to 10 minutes when awaiting acknowledgment for a
transmitted message. It proved to be quite valuable for most
applications (like http and ftp), but insufficient for near real-time
applications such as SS7 over TCP/IP.
The most common way of detecting network failures is to use an probing
message that forces the remote system to provide an immediate answer.
Such 'is alive' message has been implemented in Signaling Gateway
message suite and is further explained in Section 3.5 of this document.
3.4 Fragmentation of Messages
The nature of the sliding window acknowledgment scheme that IP uses
creates a possibility of fragmentation of messages at the TCP/IP level.
For example, one system may send 48 octets at once, and the other one
may receive 16 octets, and then in a subsequent system call would
receive the remaining 32 octets. On the other hand, a system may send
two messages of 48 octets each by issuing two separate system calls,
yet the receiving end would receive a single 96-octet message.
In order to separate messages, every message sent between the Signaling
Gateway and the User Parts over TCP/IP is prefixed with a four-octet
header that contains the type and the length of the message to follow.
The following section describes the formatting and the procedures
involved with this header.
3.5 Signaling Gateway Message Header
As a prefix to every message between the Signaling Gateway and the User
Part, a four-octet header is introduced, describing the nature and the
size of the content of the message to follow. This message header is
necessary to reassemble fragmented messages.
3.5.1 Message Header Formatting
The format of the Signaling Gateway Message Header is as described in
the table below. The offsets are indicated in number of bytes from the
beginning of the message.
Glaude, Cable, Blain [Page 9]
Internet draft SS7/IP Signaling Gateway November 27, 1998
Table 1. Signaling Gateway Message Header Format
----------+-----+------+-----------------------------------------------
Field Name| |Offset| Notes
==========+=====+======+===============================================
msgClass | | 0 | Message class, always coded as 0x00 (not used)
----------+-----+------+-----------------------------------------------
msgCmd | | 1 | Message command
---------+-----+------+------------------------------------------------
msgLength |(MSB)| 2 | The length of the message excluding the
|(LSB)| 3 | Signaling Gateway Message Header and fields.
| | | Stored as a binary number, with a maximum
| | | value of 4095.
----------+-----+------+-----------------------------------------------
The parameters are described as follows:
msgClass:
This parameter is reserved for future use.
msgCmd:
This parameter contains commands pertaining to the connection. They
can be sent in either direction. They are listed as follows:
Table 2. Signaling Gateway Message Header Commands
----------+-----------+----------------------------------------------
Name | Values | Description
==========+===========+==============================================
NO_CMD | 0 | No command (message only)
----------+-----------+----------------------------------------------
IS_ALIVE | 1 | Request Acknowledgment (are you alive?)
----------+-----------+----------------------------------------------
ACK_ALIVE | 2 | Acknowledgment (I'm alive.)
----------+-----------+----------------------------------------------
n/a | OTHER | Reserved for future use.
----------+-----------+----------------------------------------------
msgLength:
This parameter contains the length of the message to follow. A length
of zero indicates that no message follows. Although the Signaling
Gateway can receive messages of up 4096 octets in length, any MSU
with a total encoded length greater that 273 octets will be rejected.
3.5.2 Header Processing and Procedures:
Following is an explanation of the procedures associated with the
Signaling Gateway Message Header:
Glaude, Cable, Blain [Page 10]
Internet draft SS7/IP Signaling Gateway November 27, 1998
* If the msgLength parameter has a non-zero value, a message of size
<msgLength> follows, and it should be passed on to the user part. If
msgLength has a zero value, no message is following.
* Receiving a NO_CMD invokes no procedures.
* Upon reception of an IS_ALIVE command both Signaling Gateway and
User Part are required to respond immediately with an ACK_ALIVE.
Failure to do so may cause the user to close the TCP/IP socket.
* If a user part does not receive an ACK_ALIVE after a predetermined
period of time and/or a number of retries, it may conclude that a
network failure occurred and try to reestablish its connection to the
Signaling Gateway at a later time.
4.0 MTP Interface
The MTP socket interface consists of an exchange of messages between
the MTP layer that resides on the Signaling Gateway and the User Part,
as defined by the third party software developer. These messages are of
one of two categories: MTP Primitives, and Signaling Gateway User Part
Management.
First, the generic format of the messages is explained. An explanation
of message types and their parameters follow.
4.1 Signaling Gateway MTP Message Format
The MTP Messages are exchanged using the Signaling Gateway Message
Header format as described in the previous section. The messages
exchanged between the user parts and the MTP layer use network bit
ordering. All MTP primitives and MTP user part management messages
use this following format. All parameters are present for all types
of messages, although some of them are not used in all cases.
Glaude, Cable, Blain [Page 11]
Internet draft SS7/IP Signaling Gateway November 27, 1998
Table 3. SG MTP Message Format
--------------+------+-----------------------------------------------
Field Name |Offset| Notes
==============+======+===============================================
SGMsgHeader | 0 | The Signaling Gateway Message Header is
| 1 | encoded as specified in section 3.5.1.
| 2 |
| 3 |
--------------+------+-----------------------------------------------
msgType | 4 | The message type.
--------------+------+-----------------------------------------------
cause | 5 | The message cause.
--------------+------+-----------------------------------------------
n/a | 6 | This field is reserved, and is coded as 0x00.
--------------+------+-----------------------------------------------
(network) | 7 | The destination, affected or registration
dpc (cluster) | 8 | point code of the message, depending on the
(member) | 9 | message type.
--------------+------+-----------------------------------------------
n/a | 10 | This field is reserved, and is coded as 0x00.
--------------+------+-----------------------------------------------
(network) | 11 | The oringination point code of the message,
opc (cluster) | 12 | it uses the same encoding scheme as the
(member) | 13 | destination point code.
--------------+------+-----------------------------------------------
sio | 14 | The service indicator octet.
--------------+------+-----------------------------------------------
sls | 15 | The signaling link selection field.
--------------+------+-----------------------------------------------
userDataLen | 16 | (MSB) The length of the userData field to
| 17 | (LSB) follow coded in binary. If the userData
| | field is not present, the length will
| | be coded as zero.
--------------+------+-----------------------------------------------
userData | 18 | The user data field will usually contain
| 19 | the signaling information of the message.
| : |
| n |
--------------+------+-----------------------------------------------
An explanation of some of the parameters follows.
SGMsgHeader:
The Signaling Gateway Message Header is encoded as explained in
Section 3.5.
msgType:
The message type indicates the nature of the message being conveyed.
The following table indicates their type and their values. The
message type is a mandatory parameter in all messages.
Glaude, Cable, Blain [Page 12]
Internet draft SS7/IP Signaling Gateway November 27, 1998
Table 4. SG MTP Message Types
---------------------+--------------+-------------------------------
Message Type | Category | Value
=====================+==============+===============================
MTP-TRANSFER | Primitive | 0
---------------------+--------------+-------------------------------
MTP-PAUSE | Primitive | 1
---------------------+--------------+-------------------------------
MTP-RESUME | Primitive | 2
---------------------+--------------+-------------------------------
MTP-STATUS | Primitive | 3
---------------------+--------------+-------------------------------
SG-REGISTER-UP | Management | 4
---------------------+--------------+-------------------------------
SG-REGISTER-UP-ACK | Management | 5
---------------------+--------------+-------------------------------
SG-DEREGISTER-UP | Management | 6
---------------------+--------------+-------------------------------
SG-DEREGISTER-UP-ACK | Management | 7
---------------------+--------------+-------------------------------
SG-MTP-LOCAL-STATUS | Management | 8
---------------------+--------------+-------------------------------
cause:
The cause indicates a reason for some of the message types listed
above. They are explained further.
Table 5. SG MTP Cause Values
---------------------+-------------------------------
Message Type | Value
=====================+===============================
DPC-CONG-LEVEL0 | 0
---------------------+-------------------------------
DPC-CONG-LEVEL1 | 1
---------------------+-------------------------------
DPC-CONG-LEVEL2 | 2
---------------------+-------------------------------
DPC-CONG-LEVEL3 | 3
---------------------+-------------------------------
UPU-UNKNOWN | 4
---------------------+-------------------------------
UPU-UNEQUIPPED-USER | 5
---------------------+-------------------------------
UPU-INACCESSIBLE | 6
---------------------+-------------------------------
MTP-AVAILABLE | 7
---------------------+-------------------------------
MTP-UNAVAILABLE | 8
---------------------+-------------------------------
MTP-SUCCESS | 254
---------------------+-------------------------------
MTP-ERROR | 255
---------------------+-------------------------------
Glaude, Cable, Blain [Page 13]
Internet draft SS7/IP Signaling Gateway November 27, 1998
4.2 MTP Primitives
MTP Primitives are used as defined in ANSI T1.111.1, as well as
defined in ITU-T Q.701. Following is a list of MTP primitives,
as well as the parameters that they use in the Signaling Gateway
MTP message. Requests are sent to the Signaling Gateway and
indications are sent from the Signaling Gateway (SG) and received by
user parts.
Table 6. MTP Primitives
----------------+--------------+------------------------------------
Primitive Name | Type | Description
================+==============+====================================
MTP-TRANSFER | Request or | An indication or request of the
| Indication | transfer of an MSU.
----------------+--------------+------------------------------------
MTP-PAUSE | Indication | An indication to pause the
| | transfer of MSUs to a specific
| | destination.
----------------+--------------+------------------------------------
MTP-RESUME | Indication | An indication to resume the
| | transfer of MSUs to a specific
| | destination.
----------------+--------------+------------------------------------
MTP-STATUS | Indication | An indication of the change of
| | status of a specific destination
----------------+--------------+------------------------------------
4.2.1 MTP-TRANSFER
The MTP-TRANSFER primitive is the means by which data is transmitted
to and from other MTP User Parts on the SS7 network. It contains all
parameters of the routing label along with the user data.
Glaude, Cable, Blain [Page 14]
Internet draft SS7/IP Signaling Gateway November 27, 1998
Table 7. MTP-Tranfser Parameters
---------------------+-------------------------------------------------
Primitive Name | Description
=====================+=================================================
cause | n/a - set to 0
---------------------+-------------------------------------------------
DPC | Destination Point Code of the MSU to be
| transmitted or received.
---------------------+-------------------------------------------------
OPC | Origination Point Code of the MSU to be
| transmitted or received.
---------------------+-------------------------------------------------
SIO | Service Indicator Octet, part of the routing
| label.
---------------------+-------------------------------------------------
SLS | Signaling Link Selection, part of the routing
| label.
---------------------+-------------------------------------------------
UserDataLen | The length of the user data field, must be
| greater than zero.
---------------------+-------------------------------------------------
UserData | Contains the signaling information following
| the routing label.
---------------------+-------------------------------------------------
4.2.2 MTP-PAUSE
The primitive MTP-PAUSE indicates to the user part the total inability
to provide the MTP service to the specified destination. This
primitive is invoked when the MTP detects the inaccessibility of a
signaling point through link failures, transfer prohibited messages
or a combination of both.
Table 8. MTP-PAUSE Parameters
---------------+-----------------------------------------------------
Parameter | Description
===============+=====================================================
DPC | Point Code of the affected destination
---------------+-----------------------------------------------------
4.2.3 MTP-RESUME
The primitive MTP-PAUSE indicates to the user the ability to provide
the MTP service to the specified destination. This primitive is
invoked when the MTP detects the accessibility of a signaling point
through link recovery and controlled rerouting procedures.
Glaude, Cable, Blain [Page 15]
Internet draft SS7/IP Signaling Gateway November 27, 1998
Table 9. MTP-RESUME Parameters
---------------+-----------------------------------------------------
Parameter | Description
===============+=====================================================
DPC | Point Code of the affected destination
---------------+-----------------------------------------------------
4.2.4 MTP-STATUS
This primitive indicates to the user the partial inability to provide
MTP service to the specified destination. Possible causes for this
state are congestion and remote user unavailability, as per the
following list:
Table 10. MTP-STATUS Parameters
---------------+-----------------------------------------------------
Parameter | Description
===============+=====================================================
DPC | Point Code of the affected destination
---------------+-----------------------------------------------------
Cause | The cause of the status change indication
---------------+-----------------------------------------------------
The possible cause values and their explanations are listed in the
following table. The associated cause values are listed in Table 5
on page 10.
Glaude, Cable, Blain [Page 16]
Internet draft SS7/IP Signaling Gateway November 27, 1998
Table 11. MTP-STATUS Causes
--------------------+--------------------------------------------------
Cause | Description
====================+==================================================
DPC-CONG-LEVEL0 | No congestion exists at the affected destination.
| This cause will be sent to user parts in order to
| clear a previous higher congestion level.
--------------------+--------------------------------------------------
DPC-CONG-LEVEL1 | Congestion level 1 exists at the affected
| destination. This message is sent to the user
| parts when MTP Level 3 receives a TFC with
| congestion level 1.
--------------------+--------------------------------------------------
DPC-CONG-LEVEL2 | Congestion level 2 exists at the affected
| destination. This message is sent to the user
| parts when MTP level 3 receives a TFC with
| congestion level 2.
--------------------+--------------------------------------------------
DPC-CONG-LEVEL3 | Congestion level 3 exists at the affected
| destination. This message is sent to the user
| parts when MTP level 3 receives a TFC with
| congestion level 3.
--------------------+--------------------------------------------------
UPU-UNKNOWN | User Part Unavailable for reasons unknown. (a)
--------------------+--------------------------------------------------
UPU-UNEQUIPPED-USER | User Part Unavailable because of a remote
| unequipped user. (a)
--------------------+--------------------------------------------------
UPU-INACCESSIBLE | User Part Unavailable because of the
| inaccessibility of resources. (a)
--------------------+--------------------------------------------------
(a) These messages are sent to the user parts when MTP Level 3 receives
UPU messages. Since UPU messages are not used in most networks, these
causes will most likely never be received.
4.3 Signaling Gateway MTP User Part Management
The primitives defined in this section are required to support the
enhanced SS7 services offered by the Signaling Gateway MTP layer.
These primitives use the "SG" prefix which stands for "Signaling
Gateway".
Glaude, Cable, Blain [Page 17]
Internet draft SS7/IP Signaling Gateway November 27, 1998
Table 12. SG MTP User Part Management Messages
---------------------+--------------+-------------------------------
Primitive Name | Type | Description
=====================+==============+===============================
SG-REGISTER-UP | Request | A request by the user to
| | register a user part.
---------------------+--------------+-------------------------------
SG-REGISTER-UP-ACK | Response | Response to SG-REGISTER-UP
---------------------+--------------+-------------------------------
SG-DEREGISTER-UP | Request | Deregistration of User Parts.
---------------------+--------------+-------------------------------
SG-DEREGISTER-UP-ACK | Response | Response to SG-DEREGISTER-UP
---------------------+--------------+-------------------------------
SG-MTP-LOCAL-STATUS | Indication | An indication of the change
| | of the local status of the
| | signaling point.
---------------------+--------------+-------------------------------
4.3.1 SG-REGISTER-UP
This user part management message is used to register a user part
with the MTP layer of the Signaling Gateway. The user specifies
the point code and the service indicator of the application that
is registering. The Signaling Gateway then ensures proper delivery
of MSUs to the proper registered application on a point code and
service indicator basis. Up to 256 applications can register with
the Signaling Gateway on a single socket interface. Once an
application successfully registers, the proper MTP procedures are
initiated to broadcast the availability of the user part.
Table 13. SG-REGISTER-UP Parameters
----------------+----------------------------------------------------
Parameter | Description
================+====================================================
DPC | The Point Code of the user part to register.
| When the Signaling Gateway is deployed as an End
| Node, this parameter must contain the local point
| code. When the Signaling Gateway is deployed
| with virtual node capability, this parameter may
| also contain one of the virtual point codes.
----------------+----------------------------------------------------
SIO | The Service Indicator of the user part to register.
| User parts 0 (SNM), 1 (STMR) and 2 (STMS) cannot be
| registered since they are part of MTP Level 3.
----------------+----------------------------------------------------
UserDataLen | The length of the user data field.
----------------+----------------------------------------------------
UserData | The application name. This name, stored as an ASCII
| printable string, is used for loging and reporting
| purposes only. It is not mandatory.
----------------+----------------------------------------------------
Glaude, Cable, Blain [Page 18]
Internet draft SS7/IP Signaling Gateway November 27, 1998
4.3.2 SG-REGISTER-UP-ACK
This message will be returned to the user part in response to the
registration request. The success of the registration procedure is
noted in the cause field, which may have a value of MTP-SUCCESS or
MTP-ERROR. Causes for error include invalid parameters and
duplication of user part.
Table 14. SG-REGISTER-UP-ACK Parameters
----------------+----------------------------------------------------
Parameter | Description
================+====================================================
DPC | The Point Code of the user part as provided in
| When the Signaling Gateway is deployed as an End
| the Signaling Gateway-REGISTER-UP message.
----------------+----------------------------------------------------
SIO | The Service Indicator of the user part as provided
| in the Signaling Gateway-REGISTER-UP message.
----------------+----------------------------------------------------
Cause | The status indication of the registration. The
| cause will either be MTP-SUCCESS or MTP-ERROR.
----------------+----------------------------------------------------
4.3.3 Signaling Gateway-DEREGISTER-UP
This user part management message is used to de-register a user
part from the MTP layer. Upon de-registration, the proper MTP
procedures are initiated to broadcast the status change of the
point code if necessary.
Table 15. Signaling Gateway-DEREGISTER-UP Parameters
----------------+----------------------------------------------------
Parameter | Description
================+====================================================
DPC | The Point Code of the user part to deregister.
----------------+----------------------------------------------------
SIO | The Service Indicator of the user part to
| deregister.
----------------+----------------------------------------------------
4.3.4 Signaling Gateway-DEREGISTER-UP-ACK
This message will be returned to the user part in response to the
deregistration request. The success of the registration procedure
is noted in the cause field, which may have a value of MTP-SUCCESS
or MTP-ERROR. Causes for error include previously unregistered
user parts.
Glaude, Cable, Blain [Page 19]
Internet draft SS7/IP Signaling Gateway November 27, 1998
Table 16. Signaling Gateway-DEREGISTER-UP-ACK Parameters
----------------+----------------------------------------------------
Parameter | Description
================+====================================================
DPC | The Point Code of the user part as provided in
| When the Signaling Gateway is deployed as an End
| the Signaling Gateway-DEREGISTER-UP message.
----------------+----------------------------------------------------
SIO | The Service Indicator of the user part as provided
| in the Signaling Gateway-DEREGISTER-UP message.
----------------+----------------------------------------------------
Cause | The status indication of the deregistration. The
| cause will either be MTP-SUCCESS or MTP-ERROR.
----------------+----------------------------------------------------
4.3.5 Signaling Gateway-MTP-LOCAL-STATUS
This user part management message is used to inform all user parts
of the status of the local SS7 node. The status of the Signaling
Gateway is stored in the cause field and may have a value of
MTP-AVAILABLE or MTP-UNAVAILABLE.
Table 17. Signaling Gateway-MTP-LOCAL-STATUS Parameters
---------------+--------------------------------------------------
Paramter | Description
===============+==================================================
DPC | The local point code of the MTP Level 3
---------------+--------------------------------------------------
Cause | The status indication of the local MTP Level 3.
| The cause will either be MTP-AVAILABLE or
| MTP-UNAVAILABLE.
---------------+--------------------------------------------------
MTP-AVAILABLE:
This state indicates the availability of MTP Level 3 to transfer MSUs
to the SS7 Network. MTP Level 3 is available whenever it has active
connectivity to the network.
MTP-UNAVAILABLE:
This state indicates the unavailability of MTP Level 3 to transfer
MSUs to the SS7 Network. MTP Level 3 is unavailable whenever it has
no active connectivity to the network.
When the user part receives a MTP-UNAVAILABLE indication, it must clear
all tables related to the accessibility and congestion status of remote
signaling points. All previously received MTP-PAUSE and MTP-STATUS
messages no longer have significance. Once the SS7 connectivity is re-
established, a MTP-AVAILABLE local status message will be sent to user
parts, and MTP-PAUSE and MTP-STATUS messages will be resent to the user
parts in reflecting the current status of the network.
Glaude, Cable, Blain [Page 20]
Internet draft SS7/IP Signaling Gateway November 27, 1998
4.4 Configuring the MTP Interface
The configuration of the MTP interface is done through the use of the
MTP provisioning user interface provided with the Signaling Gateway.
Aside from configuring the linkset and routeset tables, the
provisioning user interface can also be used to configure the L4 API
Feature parameters. The specifics of the MTP provisioning user
interface are left to the vendor.
The parameters that are of concern to the MTP Interface are the
following:
External Application Feature:
This boolean field enables or disables the socket interface. The
Signaling Gateway may require rebooting in order for changes to this
parameter to take effect.
External Application Port:
This numeric field specifies on which port the MTP is listening for
external applications to connect and register. The Signaling Gateway
may require rebooting in order for changes to this parameter to take
effect.
Virtual Node Definitions:
If the Signaling Gateway is deployed in a mated pair configuration
for enhanced reliability reasons, applications may register to
virtual nodes (equivalent to alias point codes). These virtual nodes
must be defined through the MTP provisioning user interface.
5.0 SCCP Interface
The SCCP socket interface comprises of an exchange of messages between
the SCCP layer that resides on the Signaling Gateway and the User Part,
as defined by the third party software developer. These messages are of
one of two categories: SCCP Primitives, and Signaling Gateway User Part
Management.
SCCP provides additional network services to MTP to transfer signaling
information and other type of information between exchanges and
specialized centers in telecommunication networks. It makes routing of
messages more flexible and thus creates opportunities in enhancing
network functionality. SCCP also provides management services to
communication networks.
The Signaling gateway SCCP is based on GR-246-CORE (Revision 2 12/94)
and ITU-T Q.713(03/93). Both specifications specify two services:
connection oriented service and connectionless service. It supports
most functions of connectionless service with a few minor omissions.
The traffic mix information, which is optional, is not supported, and
LUDT and XUDT related messages used for segmentation, are not supported
either.
Glaude, Cable, Blain [Page 21]
Internet draft SS7/IP Signaling Gateway November 27, 1998
The SCCP interface is built on the MTP interface as described in the
previous section. It dynamically registers to the MTP layer as SCCP
users become available.
5.1 Signaling Gateway SCCP Message Format
The messages exchanged between the user parts and the SCCP layer use
network bit ordering. It uses the following format:
Table 18. Signaling Gateway SCCP Message Format
-------------------+------+--------------------------------------------
Field Name |Offset| Notes
===================+======+============================================
| 0 | The Signaling Gateway Message Header is
| 1 | encoded as specified in section 3.5.1.
SGMsgHeader | 2 |
| 3 |
-------------------+------+--------------------------------------------
sccpMsgType | 4 | The primitive identifier, as specified in
| 5 | the previous section.
-------------------+------+--------------------------------------------
parameterID (1) | 6 | An identifier for the parameter to follow.
| 7 |
-------------------+------+--------------------------------------------
parameterLength (1)| 8 | The length of the parameter to follow.
| 9 |
-------------------+------+--------------------------------------------
parameterValue (1) | 10 | The parameter value.
| : | The offset n is equal to
| n | 10+(parameterLength-1).
-------------------+------+--------------------------------------------
parameterID (2) | n+1 | An additional identifier for the parameter
| n+2 | to follow, if necessary.
-------------------+------+--------------------------------------------
parameterLength (2)| n+3 | The length of the additional parameter to
| n+4 | follow.
-----------------+------+----------------------------------------------
parameterValue (2) | n+5 | The additional parameter value.
| : |
| m |
-------------------+------+--------------------------------------------
:
More Parameters, if necessary
:
-------------------+------+--------------------------------------------
Signaling GatewayMsgHeader:
The Signaling Gateway Message Header is encoded as explained in
Section 3.5.
Glaude, Cable, Blain [Page 22]
Internet draft SS7/IP Signaling Gateway November 27, 1998
sccpMsgType:
The SCCP message type indicates the nature of the message being
conveyed. The following table indicates the types and their
respective values. The SCCP message type is a mandatory parameter for
all messages.
Table 19. Signaling Gateway SCCP Message Type
---------------------+--------------+-------------------------------
SCCP Message Type | Category | Value
=====================+==============+===============================
N-UNIDATA-REQ | Primitive | 0
---------------------+--------------+-------------------------------
N-UNIDATA-IND | Primitive | 1
---------------------+--------------+-------------------------------
N-NOTICE-IND | Primitive | 2
---------------------+--------------+-------------------------------
N-COORD-REQ | Primitive | 3
---------------------+--------------+-------------------------------
N-COORD-RSP | Primitive | 4
---------------------+--------------+-------------------------------
N-COORD-IND | Primitive | 5
---------------------+--------------+-------------------------------
N-COORD-CNF | Primitive | 6
---------------------+--------------+-------------------------------
N-STATE-REQ | Primitive | 7
---------------------+--------------+-------------------------------
N-STATE-IND | Primitive | 8
---------------------+--------------+-------------------------------
N-PCSTATE-IND | Primitive | 9
---------------------+--------------+-------------------------------
N-REGISTER-REQ | Management | 10
---------------------+--------------+-------------------------------
N-REGISTER-RSP | Management | 11
---------------------+--------------+-------------------------------
N-DEREGISTER-REQ | Management | 12
---------------------+--------------+-------------------------------
N-DEREGISTER-RSP | Management | 13
---------------------+--------------+-------------------------------
parameterID:
The SCCP parameter identifier provides an indication of the value to
follow. A list of all parameter identifiers and their values follows.
Glaude, Cable, Blain [Page 23]
Internet draft SS7/IP Signaling Gateway November 27, 1998
Table 20. SCCP Parameter Identifier Values
----------------------------+------+--------------------------------
Parameter |Value | Section
============================+======+================================
SCCP-CALLED-ADDR | 0 |
----------------------------+------+--------------------------------
SCCP-CALLING-ADDR | 1 |
----------------------------+------+--------------------------------
SCCP-QUALITY-OF-SERV | 2 |
----------------------------+------+--------------------------------
SCCP-USER-DATA | 3 |
----------------------------+------+--------------------------------
SCCP-REASON-FOR-RETURN | 4 |
----------------------------+------+--------------------------------
SCCP-AFFECTED-USER | 5 |
----------------------------+------+--------------------------------
SCCP-CONFIRM-STATUS | 6 |
----------------------------+------+--------------------------------
SCCP-SS-MULTI-IND | 7 |
----------------------------+------+--------------------------------
SCCP-USER-STATUS | 8 |
----------------------------+------+--------------------------------
SCCP-AFFECTED-DPC | 9 |
----------------------------+------+--------------------------------
SCCP-SP-STATUS | 10 |
----------------------------+------+--------------------------------
SCCP-REGISTER-USER | 11 |
----------------------------+------+--------------------------------
SCCP-REGISTER-USER-ACK | 12 |
----------------------------+------+--------------------------------
SCCP-DEREGISTER-USER | 13 |
----------------------------+------+--------------------------------
SCCP-DEREGISTER-USER-ACK | 14 |
----------------------------+------+--------------------------------
SCCP-ROUTING-LABEL | 15 |
----------------------------+------+--------------------------------
5.2 SCCP Primitives
Table 21 lists the SCCP connectionless primitives supported by the
Signaling Gateway.
Glaude, Cable, Blain [Page 24]
Internet draft SS7/IP Signaling Gateway November 27, 1998
Table 21. SCCP Primitives
-----------------+--------------+--------------------------------------
Primitive Name | Type | Description
=================+==============+======================================
N-UNITDATA | Request | Used to transfer UnitData messages,
| Indication | usually containing a TCAP message.
-----------------+--------------+--------------------------------------
N-NOTICE | Indication | Used to indicate the failure of the
| | transfer of a UnitData message.
-----------------+--------------+--------------------------------------
N-COORD | Request | Used to coordinate the transfer of
| Indication | traffic between replicated systems.
| Response |
| Confirmation |
-----------------+--------------+--------------------------------------
N-STATE | Request | Used to inform about the status of a
| Indication | local or remote subsystem.
-----------------+--------------+--------------------------------------
N-PCSTATE | Indication | Used to inform about the status of
| | a remote point code.
-----------------+--------------+--------------------------------------
5.2.1 N-UNITDATA
The N-UNITDATA primitive is the means by which data is transmitted to
and from other SCCP User Parts on the SS7 network. It contains a
destination, an origination, a quality of service identifier and the
user data to be sent or received.
Table 22. N-UNITDATA parameters
---------------------+-----+-----+----------------------------------
Parameter | REQ | IND | Description
=====================+=====+=====+==================================
SCCP-ROUTING-LABEL | X | | MTP Routing lable to be put into
| | | outgoing message
---------------------+-----+-----+----------------------------------
SCCP-CALLED-ADDR | X | X | Called Address
---------------------+-----+-----+----------------------------------
SCCP-CALLING-ADDR | X | X | Calling Address
---------------------+-----+-----+----------------------------------
SCCP-QUALITY-OF-SERV | X | | Quality of Service
---------------------+-----+-----+----------------------------------
SCCP-USER-DATA | X | X | User Data ususally consisting of
| | | a TCAP message
---------------------+-----+-----+----------------------------------
Glaude, Cable, Blain [Page 25]
Internet draft SS7/IP Signaling Gateway November 27, 1998
5.2.2 N-NOTICE
In the event of a failure to reach the final destination using a
N-UNITDATA, the SCCP layer sends a N_NOTICE back to the originator
of the message, stating the cause of the failure.
Table 23. N-NOTICE parameters
---------------------+-----+----------------------------------
Parameter | IND | Description
=====================+=====+==================================
SCCP-CALLED-ADDR | X | Called Address
---------------------+-----+----------------------------------
SCCP-CALLING-ADDR | X | Calling Address
---------------------+-----+----------------------------------
SCCP-REASON-FOR-RET | X | Reason for Return
---------------------+-----+----------------------------------
SCCP-USER-DATA | X | User Data ususally consisting of
| | a TCAP message
---------------------+-----+----------------------------------
5.2.3 N-COORD
This primitive is used to coordinate the transfer of traffic
between replicated systems in the event of failures.
Table 24. N-COORD parameters
---------------------+-----+-----+-----+-----+-----------------------
Parameter | REQ | IND | REQ | IND |Description
=====================+=====+=====+=====+=====+=======================
SCCP-AFFECTED-USER | X | X | X | X | Affected User(PC-SSN)
---------------------+-----+-----+-----+-----+-----------------------
SCCP-USER-STATUS | | | | X | Status
---------------------+-----+-----+-----+-----+-----------------------
SCCP-SS-MULTI-IND | | X | | X | Subsystem multiplicity
| | | | | indicator
------------------ --+-----+-----+-----+-----+-----------------------
Glaude, Cable, Blain [Page 26]
Internet draft SS7/IP Signaling Gateway November 27, 1998
5.2.4 N-STATE
This primitive is used to inform the SCCP layer and the user about
the status of a local or a remote affected user.
Table 25. N-STATE parameters
---------------------+-----+-----+----------------------------------
Parameter | REQ | IND | Description
=====================+=====+=====+==================================
SCCP-AFFECTED-USER | X | X | Affected user (PC-SSN)
---------------------+-----+-----+----------------------------------
SCCP-USER-STATUS | X | X | Status
---------------------+-----+-----+----------------------------------
SCCP-SS-MULTI-IND | | X | Subsystem multiplicity indicator
---------------------+-----+-----+----------------------------------
5.2.5 N-PCSTATE
This primitive is used to inform a local user about the status of a
signaling point.
Table 26. N-PCSTATE parameters
---------------------+-----+----------------------------------
Parameter | IND | Description
=====================+=====+==================================
SCCP-AFFECTED-DPC | X | Affected user (PC)
---------------------+-----+----------------------------------
SCCP-SP-STATUS | X | Status
---------------------+-----+----------------------------------
5.3 Signaling Gateway SCCP User Part Management
The primitives defined in this section are required to support the
enhanced SS7 services offered by the Signaling Gateway SCCP Management
layer.
Table 27. Signaling Gateway SCCP User Part Management Primitives
---------------------+--------------+-------------------------------
Primitive Name | Type | Description
=====================+==============+===============================
N-REGISTER | Request | Registration of User Parts
| Response |
---------------------+--------------+-------------------------------
N-DEREGISTER | Request | Deregistration of User Parts
| Response |
---------------------+--------------+-------------------------------
Glaude, Cable, Blain [Page 27]
Internet draft SS7/IP Signaling Gateway November 27, 1998
5.3.1 N-REGISTER
This primitive is used to register a user part with the SCCP layer of
the Signaling Gateway. The user specifies the point code and the
subsystem associated with the application that is registering. The
Signaling Gateway then ensures proper delivery of UDT messages to the
proper registered application on a point code and subsystem basis. Up
to 256 applications can register with the Signaling Gateway on a single
socket interface. Once an application successfully registers, the
proper SCCP procedures are initiated to broadcast the availability of
the SSN.
Table 28. N-REGISTER Parameters
-----------------------+-----+-----+----------------------------------
Parameter | REQ | RSP | Description
=======================+=====+=====+==================================
SCCP-REGISTER-USER | X | | User point code and subsystem
-----------------------+-----+-----+----------------------------------
SCCP-REGISTER-USER-ACK | | X | User point code, subsystem and
| | | status
-----------------------+-----+-----+----------------------------------
5.3.2 N-DEREGISTER-SSN
This primitive is used to de-register a user part from the SCCP layer.
Upon de-registration, the proper SCCP procedures are initiated to
broadcast the status change of the SSN.
Table 29. N-DEREGISTER Parameters
-------------------------+-----+-----+---------------------------------
Parameter | REQ | RSP | Description
=========================+=====+=====+=================================
SCCP-DEREGISTER-USER | X | | User point code and subsystem
-------------------------+-----+-----+---------------------------------
SCCP-DEREGISTER-USER-ACK | | X | User point code, subsystem and
| | | status
-------------------------+-----+-----+---------------------------------
Glaude, Cable, Blain [Page 28]
Internet draft SS7/IP Signaling Gateway November 27, 1998
5.4 SCCP Parameters
This section describes the parameter formats used with the SCCP layer.
5.4.1 SCCP-CALLED-ADDR
The SCCP called address is encoded as follows.
Table 30. SCCP-CALLED-ADDR Format
-----------------+------+---------------------------------------------
Field Name |Offset| Notes
=================+======+=============================================
addressIndicator | 0 | The address indicator format is shown below.
-----------------+------+---------------------------------------------
subsystemNumber | 1 | The subsystem number.
-----------------+------+---------------------------------------------
n/a | 2 | This field is reserved, and coded as 0x00.
-----------------+------+---------------------------------------------
(network)| 3 | The destination point code.
dpc (cluster)| 4 |
(member) | 5 |
-----------------+------+---------------------------------------------
gttLength | 6 | A single octet length indicator fopr the GTT
| | parameter to follow.
-----------------+------+---------------------------------------------
globalTitle | 7 | The global title information whose length
| : | is defined by the gttLength parameter.
| 7+n |
-----------------+------+---------------------------------------------
The address indicator octet is further broken down into the following
sub-fields:
Bit 8: Network Indicator, 0 - international and 1 - national
Bit 7: Routing Indicator, 0 - route on GTT, 1 - route on DPC/SSN
Bits 6-3: Global Title Type
Bit 2: SSN Present in ITU, PC Present in ANSI when set to 1.
Bit 1: PC Present in ITU, SSN Present in ITU when set to 1.
5.4.2 SCCP-CALLING-ADDR
The SCCP calling address is encoded in the same manner as the called
address.
Glaude, Cable, Blain [Page 29]
Internet draft SS7/IP Signaling Gateway November 27, 1998
5.4.3 SCCP-QUALITY-OF-SERV
The quality of service parameter is encoded as follows:
Table 31. SCCP-QUALITY-OF-SERV Format
-----------------+------+---------------------------------------------
Field Name |Offset| Notes
=================+======+=============================================
sequenceControl | 0 | 0 - sequence guaranteed
| | 1 - sequence not guaranteed
-----------------+------+---------------------------------------------
returnOption | 1 | 0 - return on error
| | 1 - discard on error
-----------------+------+---------------------------------------------
priority | 2 | 0,1 or 2. Not used in ITU, and should be set
| | to zero.
-----------------+------+---------------------------------------------
5.4.4 SCCP-USER-DATA
The user data parameter contains the stream of octets transferred.
It usually contains an encoded TCAP message.
5.4.5 SCCP-REASON-FOR-RET
The SCCP reason for return is a single octet parameter and is encoded
as specified in GR-246-CORE, T1.112.3 Section 3.12 when used in ANSI
mode. For ITU, the format of the reason for return is specified in
Q.713 Section 3.12.
5.4.6 SCCP-AFFECTED-USER
This parameter contains the identification of an affected SCCP user.
Its encoding is as follows.
Table 32. SCCP-AFFECTED-USER Format
-----------------+------+---------------------------------------------
Field Name |Offset| Notes
=================+======+=============================================
subsystemNumber | 0 | The subsystem number.
-----------------+------+---------------------------------------------
n/a | 1 | This field is reserved, and coded as 0x00.
-----------------+------+---------------------------------------------
(network)| 2 | The affected point code.
apc (cluster)| 3 |
(member) | 4 |
-----------------+------+---------------------------------------------
Glaude, Cable, Blain [Page 30]
Internet draft SS7/IP Signaling Gateway November 27, 1998
5.4.7 SCCP-CONFIRM-STATUS
The confirmation status indicates whether the out-of-service request
was granted or denied. A value of 0 indicates acceptance, and 1
indicates a denial.
5.4.8 SCCP-SS-MULTI-IND
This parameter contains the subsystem multiplicity indicator. 0 is
unknown, 1 indicates solitary and 2 indicates a replicated subsystem.
5.4.9 SCCP-USER-STATUS
This parameter contains the status of an SCCP user. 0 indicates that
the user is out of service. 1 indicates that the user is in service.
5.4.10 SCCP-AFFECTED-DPC
This parameter contains the point code of an affected destination. It
is encoded as follows.
Table 33. SCCP-AFFECTED-DPC format
-----------------+------+---------------------------------------------
Field Name |Offset| Notes
=================+======+=============================================
n/a | 0 | This field is reserved, and coded as 0x00.
-----------------+------+---------------------------------------------
(network)| 1 | The affected point code.
apc (cluster)| 2 |
(member) | 3 |
-----------------+------+---------------------------------------------
Glaude, Cable, Blain [Page 31]
Internet draft SS7/IP Signaling Gateway November 27, 1998
5.4.11 SCCP-SP-STATUS
This single octet parameter contains the status of a destination
encoded as follows.
Table 34 SCCP-SP-STATUS Values
------+---------------------+---------------------
Value | ANSI | ITU-T
======+=====================+=====================
0 | No Congestion | No Congestion
------+---------------------+---------------------
1 | Congestion Level 1 | Congestion
------+---------------------+---------------------
2 | Congestion Level 2 | n/a
------+---------------------+---------------------
3 | Congestion Level 3 | n/a
------+---------------------+---------------------
254 | Accessible | Accessible
------+---------------------+---------------------
255 | Inaccessible |Inaccessible
------+---------------------+---------------------
5.4.12 SCCP-REGISTER-USER
This parameter contains the identity of a registered user. Its format
is as follows.
Table 35. SCCP-REGISTERED-USER Format
-----------------+------+---------------------------------------------
Field Name |Offset| Notes
=================+======+=============================================
subsystemNumber | 0 | The subsystem number.
-----------------+------+---------------------------------------------
n/a | 1 | This field is reserved, and coded as 0x00.
-----------------+------+---------------------------------------------
(network)| 2 | The point code.
pc (cluster)| 3 |
(member) | 4 |
-----------------+------+---------------------------------------------
Glaude, Cable, Blain [Page 32]
Internet draft SS7/IP Signaling Gateway November 27, 1998
5.4.13 SCCP-REGISTER-USER-ACK
This parameter contains the identity of a registered user and the
status of the registration request. Its format is as follows.
Table 36. SCCP-REGISTERED-USER-ACK Format
-----------------+------+---------------------------------------------
Field Name |Offset| Notes
=================+======+=============================================
subsystemNumber | 0 | The subsystem number.
-----------------+------+---------------------------------------------
n/a | 1 | This field is reserved, and coded as 0x00.
-----------------+------+---------------------------------------------
(network)| 2 | The point code.
pc (cluster)| 3 |
(member) | 4 |
-----------------+------+---------------------------------------------
status | 5 | 0 - failure, 1 - success
-----------------+------+---------------------------------------------
5.4.14 SCCP-DEREGISTER-USER
The format of this parameter is the same as SCCP-REGISTER-USER.
5.4.15 SCCP-DEREGISTER-USER-ACK
The format of this parameter is the same as SCCP-REGISTER-USER-ACK.
Glaude, Cable, Blain [Page 33]
Internet draft SS7/IP Signaling Gateway November 27, 1998
5.4.16 SCCP-ROUTING-LABEL
This parameter contains the MTP level 3 routing label. Its format is as
follows.
Table 37. SCCP-ROUTING-LABEL Format
-----------------+------+---------------------------------------------
Field Name |Offset| Notes
=================+======+=============================================
sio | 0 | The service indicator octet.
-----------------+------+---------------------------------------------
n/a | 1 | This field is reserved, and coded as 0x00.
-----------------+------+---------------------------------------------
(network)| 2 | The destination, affected or registration
dpc (cluster)| 3 | point code of the message, depending on the
(member) | 4 | message type.
-----------------+------+---------------------------------------------
n/a | 5 | This field is reserved, and coded as 0x00.
-----------------+------+---------------------------------------------
(network)| 6 | The origination point code of the message.
opc (cluster)| 7 | It has the same encoding scheme as the dpc
(member) | 8 | field.
-----------------+------+---------------------------------------------
sls | 9 | The signaling link selection field.
-----------------+------+---------------------------------------------
Glaude, Cable, Blain [Page 34]
Internet draft SS7/IP Signaling Gateway November 27, 1998
5.5 Configuring the SCCP Interface
The configuration of the SCCP Interface can be done through the
modification of an ASCII configuration file. The specifics of the SCCP
interface configuration is left to the vendor.
A sample configuration file and explanation of the parameters follows.
Example 3 Sample SCCP Configuration File
########## SCCP node
$SCCPNODE
LPC=100.100.100
DEBUGLEVEL=4
MAJORFLAVOR=SCCP_ANSI_FLVR
MINORFLAVOR=SCCP_ITU_FLVR
CONNDELAY=30000 # milliseconds
SSTDELAY=30000 # milliseconds
IGNOREDELAY=30000 # milliseconds
COORDDELAY=30000 # milliseconds
OPMODE=USERONLY
DESC="SCCP"
MONPORT=6789
MTPPORT=6230
########## Replicated subsystem
$RSSGROUP GID=1 RSCOUNT=3 MODE=DOMINANT
$RSS GID=1 RPC=51.68.85 SSN=7 PRIORITY=1
$RSS GID=1 RPC=68.85.102 SSN=7 PRIORITY=2
$RSS GID=1 RPC=85.102.119 SSN=6 PRIORITY=3
$RSSGROUP GID=2 RSCOUNT=1 MODE=LOADSHARE
$RSS GID=2 RPC=18.52.86 SSN=1 PRIORITY=1
Lines that start with pound sign "#" are comments. Everything appearing
after the # and to the end of the line is ignored by SCCP. To have
multiple line comments, each line has to be proceded with #. The dollar
sign ($) serves as an identifier of a Tag, followed by Tag name,
identifying a configurable object. The rest of the file are variable
and value pairs.
The following table explains the parameters used in the configuration
of an $SCCPNODE object.
The SCCPNODE is the "top" object that represents the SCCP entity.
All parameters listed under the SCCPNODE object can be considered as
global values for the SCCP task.
Glaude, Cable, Blain [Page 35]
Internet draft SS7/IP Signaling Gateway November 27, 1998
Table 38 $SCCPNODE Parameters
-----------------+----------------------------------------------------
Parameter | Notes
=================+====================================================
LPC | The local point code of the SCCP layer.
-----------------+----------------------------------------------------
DEBUGLEVEL | The Debug Level Parameter indicates the nature of
| the information to be sent to the Signaling
| Gateway Debug Log used during troubleshooting.
| Ranges from 0 (no debug) to 4 (verbose).
-----------------+----------------------------------------------------
MAJORFLAVOR | The major flavor identifies which version of
| SS7 the MTP is using. Valid values are
| SCCP_ANSI_FLVR, SCCP_ITU_FLVR and SCCP_CHINA_FLVR.
-----------------+----------------------------------------------------
MINORFLAVOR | The minor flavor identifies what version of SS7 the
| SCCP must use when the address indicator bit 8 is
| set to zero in the called and the calling party
| address. Valid values are SCCP_ANSI_FLVR,
| SCCP_ITU_FLVR and SCCP_CHINA_FLVR.
-----------------+----------------------------------------------------
CONNDELAY | The delay between connection attempts to the MTP.
| The value is stored in milliseconds.
-----------------+----------------------------------------------------
SSTDELAY | T(stat. info.) Delay between requests for sub-
| system status information. The value is stored in
| milliseconds.
-----------------+----------------------------------------------------
IGNOREDELAY | T(ignore SST) Delay for sub-system between
| receiving grant to go out of service and actually
| going out of service. The value is stored in
| milliseconds.
-----------------+----------------------------------------------------
COORDDELAY | T(coord. chg.) Waiting for grant for sub-system
| to go out of service. The value is stored in
| milliseconds.
-----------------+----------------------------------------------------
OPMODE | The operation mode of the SCCP layer. Valid values
| are USERONLY, GTTONLY and USERGTT.
-----------------+----------------------------------------------------
DESC | This a description field, and is used as the
| identifier in the Signaling Gateway system and
| debug logs.
-----------------+----------------------------------------------------
USRPORT | This is the port to which the SCCP is listening,
| waiting for SCCP user connections.
-----------------+----------------------------------------------------
GTTPORT | This is the port to which the SCCP listens for GTT
| applications.
-----------------+----------------------------------------------------
MTPPORT | This is the port which the SCCP uses for connecting
| with the MTP. This value should match the External
| Application Port parameter found in the MTP
| Provisioning Interface.
-----------------+----------------------------------------------------
Glaude, Cable, Blain [Page 36]
Internet draft SS7/IP Signaling Gateway November 27, 1998
This next table explains the parameters of the $RSSGROUP object, which
represents a group of replicated subsystems.
Table 39. $RSSGROUP Parameters
-----------------+----------------------------------------------------
Parameter | Notes
=================+====================================================
GID | This numeric parameter is used to uniquely identify
| a group of replicated subsystems.
-----------------+----------------------------------------------------
RSCOUNT | The count of replicated subsystems in the
| replicated system group.
-----------------+----------------------------------------------------
MODE | The mode in which the replicated systems operate.
| Valide values are DOMINANT and LOADSHARE.
-----------------+----------------------------------------------------
The next table lists the parameters associated with the $RSS object,
which represents an entry in the table of a replicated subsystem.
Table 40. $RSS Parameters
-----------------+----------------------------------------------------
Parameter | Notes
=================+====================================================
GID | This numeric parameter is used to correlate this
| entry with a unique group of replicated subsystems.
-----------------+----------------------------------------------------
RPC | The remote point code servicing the replicated
| subsystem.
-----------------+----------------------------------------------------
SSN | The remote subsystem number.
| Valide values are DOMINANT and LOADSHARE.
-----------------+----------------------------------------------------
PRIORITY | The priority of the subsystem among its replicates.
| The range is from 0 to 99.
-----------------+----------------------------------------------------
Glaude, Cable, Blain [Page 37]
Internet draft SS7/IP Signaling Gateway November 27, 1998
6.0 Sample Application
A typical application would use the following sequence of operations.
6.1 Setup
(1) Connect to the Signaling Gateway.
Using BSD socket library calls, an application would connect to a
socket on the Signaling Gateway.
(2) Receive local status
The first thing that the Signaling Gateway sends is the status of the
local system.
(3) Register with the Signaling Gateway
The application then sends a registration request to the Signaling
Gateway, specifying a point code and a subsystem number for the SCCP
interface, and a point code and a service indicator for the MTP
interface.
(4) Receive registration acknowledgment
The Signaling Gateway will return a message indicating the status of
the registered user part.
6.2 Operation
(5) Send and Receive messages
The application can the send and receive UDT or MTP messages to the SS7
network. Standard BSD library functions will provide a non-blocking
interface to the TCP/IP LAN servicing the application platform and
the Signaling Gateway.
6.3 Shutdown
(6) De-register from the Signaling Gateway
At any given time, a user part may de-register itself from the
Signaling Gateway. A sudden closure of the TCP/IP socket would have the
same effect.
(7) Receive de-registration acknowledgement
The Signaling Gateway will return a message indicating the status of
the de-registered user part.
(8) Close the connection to the Signaling Gateway
Properly closing the connection to the Signaling Gateway is necessary
in order to ensure maximum performance of the Signaling Gateway.
Glaude, Cable, Blain [Page 38]
Internet draft SS7/IP Signaling Gateway November 27, 1998
7 Future Enhancements
Enhancements to the Signaling Gateway API would include the ability to
allow applications to register with the MTP layer of the SS7 protocol
stack and request to send and receive ISUP messages for a specified
range of circuit identification codes (CICs). This would permit
multiple application processes such as Media Gateway Controllers to
register with the Signaling Gateways utilizing the same point code and
load-share the call processing traffic load by only registering for
control over a specified range of PSTN Trunk circuits.
A similar type of registration could be provided at the SCCP level.
Application processes would register with the SCCP layer of the SS7
protocol stack and request to send and receive TCAP messages for a
specified range of Transaction Identifiers for a shared point code and
subsystem number.
8 Authors
Normand Glaude
MicroLegend Telecom Systems Inc.
150 Metcalfe Street, Suite 2201
Ottawa, Ontario, Canada
K2P 1P1
Email: nglaude@microlegend.com
Tom Blain
MicroLegend Telecom Systems Inc.
150 Metcalfe Street, Suite 2201
Ottawa, Ontario, Canada
K2P 1P1
Email: tblain@microlegend.com
Reg Cable
MicroLegend Telecom Systems Inc.
150 Metcalfe Street, Suite 2201
Ottawa, Ontario, Canada
K2P 1P1
Email: rcable@microlegend.com
INTERNET DRAFT
Transport SS7 Signalling Over IP
<draft-glaude-ss7-gw-00.txt>
Date:November 27, 1998
Expires: June 1999
Glaude, Cable, Blain [Page 39]
