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 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 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 Date:November 27, 1998 Expires: June 1999 Glaude, Cable, Blain [Page 39]