| draft-ietf-sigtran-sua-05 Description: Request For Comments
You can download source copies of the file as follows:
Listed below is the contents of file draft-ietf-sigtran-sua-05.txt.
INTERNET-DRAFT J. Loughney
Internet Engineering Task Force Nokia
G. Sidebottom, Guy Mousseau
Issued: 1 February 2001 Nortel Networks
Expires: 1 August 2001 S. Lorusso
Unisphere Solutions
L. Coene, G. Verwimp
Siemens
J. Keller
Tekelec
F. Escobar
Ericsson
W. Sully, S. Furniss
Marconi
SS7 SCCP-User Adaptation Layer (SUA)
<draft-ietf-sigtran-sua-05.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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.'
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html .
This draft expires on 1 August 2001
Abstract
This Internet Draft defines a protocol for the transport of any SS7
SCCP-User signaling (e.g., TCAP, RANAP, etc.) over IP using the
Stream Control Transport Protocol. The protocol should be modular
and symmetric, to allow it to work in diverse architectures, such as
a Signaling Gateway to IP Signaling Endpoint architecture as well as
a peer-to-peer IP Signaling Endpoint architecture. Protocol
elements are added to allow seamless operation between peers in the
SS7 and IP domains.
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
Abstract..............................................................1
1. Introduction.......................................................3
1.1 Scope ...........................................................3
1.2 Terminology .....................................................3
1.3 Signaling Transport Architecture ................................5
1.4 Services Provided by the SUA Layer .............................11
1.5 Internal Functions Provided in the SUA Layer ...................13
1.6 Definition of SUA Boundaries ...................................15
2 Conventions........................................................16
3 Protocol Elements..................................................16
3.1 Common Message Header ..........................................16
3.2 SUA Connectionless Messages ....................................19
3.3 Connection Oriented Messages ...................................21
3.4 SS7 Signaling Network Management Messages ......................29
3.5 Application Server Process Maintenance Messages ................34
3.6 ASP Traffic Maintenance Messages ...............................36
3.7 Management Messages ............................................39
3.8 Common Parameters ..............................................40
3.9 SUA-Specific parameters ........................................49
4 Procedures.........................................................62
4.1 SCCP _ SUA Interworking at the SG ..............................62
4.2 Primitives received from the local SUA-user ....................63
4.3 Layer Management Procedures ....................................64
4.4 SUA Management Procedures ......................................65
5 Examples of SUA Procedures.........................................71
5.1 SG Architecture ................................................71
5.2 IP-IP Architecture .............................................74
6 Message Routing Scenarios..........................................76
6.1 Basic case with single SG acting as end- or relay-point ........76
6.2 Replicated SG acting as end-point ..............................77
6.3 Replicated SG acting as relay-point ............................78
7 Security...........................................................79
7.1 Introduction ...................................................79
7.2 Threats ........................................................79
7.3 Protecting Confidentiality .....................................79
8 IANA Considerations................................................80
8.1 SCTP Payload Protocol ID .......................................80
8.2 Port Number ....................................................80
8.3 Protocol Extensions ............................................80
9 Timer Values.......................................................81
10 Acknowledgements..................................................81
10 Authors' Addresses................................................81
11 References........................................................83
Appendix A: Message mapping between SCCP and SUA.....................84
Copyright Statement..................................................85
Loughney, et al. [Page 2]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
1. Introduction
1.1 Scope
There is on-going integration of SCN networks and IP networks.
Network service providers are designing all IP architectures which
include support for SS7 and SS7-like signaling protocols. IP
provides an effective way to transport user data and for operators
to expand their networks and build new services. In these networks,
there may be some need for interworking between the SS7 and IP
domains.
This document details the delivery of SCCP-user messages (MAP & CAP
over TCAP, RANAP, etc.) and new third generation network protocol
messages over IP between two signaling endpoints. Consideration is
given for the transport from an SS7 Signaling Gateway (SG) to an IP
signaling node (such as an IP-resident Database) as described in the
Framework Architecture for Signaling Transport [2719]. This protocol
can also support transport of SCCP-user messages between two
endpoints wholly contained within an IP network.
The delivery mechanism SHOULD meet the following criteria:
* Support for transfer of SS7 SCCP-User Part messages (e.g., TCAP,
RANAP, etc.)
* Support for SCCP connectionless service.
* Support for SCCP connection oriented service.
* Support for the seamless operation of SCCP-User protocol peers
* Support for the management of SCTP transport associations between
a SG and one or more IP-based signaling nodes).
* Support for distributed IP-based signaling nodes.
* Support for the asynchronous reporting of status changes to
management
The protocol is modular in design, allowing different
implementations to be made, based upon the environment that needs to
be supported. Depending upon the upper layer protocol supported, the
SUA will need to support SCCP connectionless service, SCCP connect-
orient service or both services.
1.2 Terminology
Signaling Gateway (SG) - Network element that terminates SCN
signaling and transports SCCP-User signaling over IP to an IP
signaling endpoint. A Signaling Gateway could be modeled as one or
more Signaling Gateway Processes, which are located at the border of
the SS7 and IP networks.
Application Server (AS) - A logical entity serving a specific
Routing Key. An example of an Application Server is a virtual IP
database element handling all request for a SCCP-user. The AS
Loughney, et al. [Page 3]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
contains a set of one or more unique Application Server Processes,
of which one or more is normally actively processing traffic.
Application Server Process (ASP) - An Application Server Process
serves as an active or standby process of an Application Server
(e.g., part of a distributed signaling node or database element).
Examples of ASPs are MGCs, IP SCPs, or IP-based HLRs. An ASP
contains an SCTP end-point and may be configured to process traffic
within more than one Application Server.
Association - An association refers to an SCTP association. The
association provides the transport for the delivery of SCCP-User
protocol data units and SUA adaptation layer peer messages.
Routing Key - The Routing Key describes a set of SS7 parameter and
/or parameter-ranges that uniquely defines the range of signaling
traffic configured to be handled by a particular Application Server.
An example would be where a Routing Key consists of a particular
SS7 network ID and SCCP SSN for which all traffic would be directed
to a particular Application Server. Routing Keys are mutually
exclusive in the sense that a received SS7 signaling message cannot
be directed to more than one Routing Key. In the case of SUA, the
Routing Key should be limited to a combination of SS7 network ID and
SCCP SSN to identify an AS, in order to more easily support SCCP
management procedures.
Routing Context - An Application Server Process may be configured to
process traffic within more than one Application Server. In this
case, the Routing Context parameter is exchanged between two ASPs,
identifying the relevant Application Server. From the perspective
of an ASP, the Routing Context uniquely identifies the range of
traffic associated with a particular Application Server, which the
ASP is configured to receive. There is a 1:1 relationship between a
Routing Context value and a Routing Key within an AS. Therefore the
Routing Context can be viewed as an index into an AS Table
containing the AS Routing Keys.
Fail-over - The capability to re-route signaling traffic as required
to an alternate Application Server Process, or group of ASPs, within
an Application Server in the event of failure or unavailability of a
currently used Application Server Process. Fail-back may apply upon
the return to service of a previously unavailable Application Server
Process.
Network Appearance - The Network Appearance identifies an SS7
network context (network ID) for the purposes of logically
separating the signaling traffic between the SG and the Application
Server Processes over a common SCTP Association. This partitioning
is necessary where an SG is logically partitioned to appear as an
end-node elements in multiple separate national SS7 networks, in
which case there is a separate network appearance for each SS7
Loughney, et al. [Page 4]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
network. It is also necessary when an SG is configured as an STP and
hosts multiple point codes within the same network, in which case
each point code is a separate network appearance.
Network Byte Order - Most significant byte first, a.k.a. Big Endian.
Layer Management - Layer Management is a nodal function in an SG or
ASP that handles the inputs and outputs between the SUA layer and a
local management entity.
Host - The computing platform that the ASP process is running on.
Stream - A stream refers to an SCTP stream; a uni-directional
logical channel established from one SCTP endpoint to another
associated SCTP endpoint, within which all user messages are
delivered in-sequence except for those submitted to the un-ordered
delivery service.
Transport address - an address which serves as a source or
destination for the unreliable packet transport service used by
SCTP. In IP networks, a transport address is defined by the
combination of an IP address and an SCTP port number. Note, only
one SCTP port may be defined for each endpoint, but each SCTP
endpoint may have multiple IP addresses.
1.3 Signaling Transport Architecture
The framework architecture that has been defined for SCN signaling
transport over IP [2719] uses multiple components, including an IP
transport protocol, a signaling common transport protocol and an
adaptation module to support the services expected by a particular
SCN signaling protocol from its underlying protocol layer.
In general terms, the SUA architecture can be modeled as a peer-to-
peer architecture. The first section considers the SS7-IP
interworking architectures for connectionless and connection-
oriented transport. For this case, it is assumed that the ASP
initiates the establishment of the SCTP association with SG.
1.3.1 Protocol Architecture for Connectionless Transport
In this architecture, the SCCP and SUA layers interface in the SG.
There needs to be interworking between the SCCP and SUA layers to
provide for the seamless transfer of the user messages as well as
the management messages. For messages destined for an ASP, there
are two scenarios.
******** SS7 *************** IP ********
* SEP *---------* *--------* *
* or * * SG * * ASP *
Loughney, et al. [Page 5]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
* STP * * * * *
******** *************** ********
+------+ +------+
| TCAP | | TCAP |
+------+ +------+------+ +------+
| SCCP | | SCCP | SUA | | SUA |
+------+ +------+------+ +------+
| MTP3 | | MTP3 | | | |
+------| +------+ SCTP | | SCTP |
| MTP2 | | MTP2 | | | |
+------+ +------+------+ +------+
| L1 | | L1 | IP | | IP |
+------+ +------+------+ +------+
| | | |
+---------------+ +------------+
TCAP - Transaction Capability Application Protocol
STP - SS7 Signaling Transfer Point
1.3.1.1 SG as endpoint
In this case, the connectionless SCCP messages are routed on PC and
SSN. The subsystem identified by SSN and SS7 network appearance is
regarded as local to the SG. This means from SS7 point of view, the
SCCP-user is located at the SG.
By means of configuration, the SG knows the local SCCP-user is
actually representing an AS, serviced by a set of ASPs working in
n+k redundancy mode. An ASP is selected and a CLDT message is sent
on the appropriate SCTP association/stream.
Actually, the primitive interface between SCCP and SCCP-user is
transported here over SUA. An example for a INAP/TCAP message
exchange between SEP and ASP is given below.
Address information in CLDT message (TC_Query) from SG to ASP :
- Association ID : SG-ASP,
- Stream ID : based on SLS (and possibly OPC, SS7 network ID),
- Network appearance : based on SS7 network ID,
- Source address : valid combination of SSN, PC and GT, as
needed for back-routing,
- Destination address : at least SSN, to select the SCCP-user
at the ASP.
The Network Appearance is needed if the SG operates in more than one
SS7 network, since PC and SSN only have meaning within a specific
SS7 network. In the response, the ASP should pass a unique,
unambiguous source address.
Loughney, et al. [Page 6]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
Address information in CLDT message (TC_Response) from ASP to SG :
- Association ID : ASP-SG,
- Stream ID : implementation dependent, but in-sequence-
delivery must be taken care of,
- Network appearance : as received in previous message,
- Source address : unique ASP address that when used as
SCCP called party address in the SEP, MUST yield the
same ASP again; the SSN could be sufficient,
- Destination address : copied from source address in received
CLDT message.
Further messages from the SEP belonging to the same TCAP transaction
will now reach the same ASP.
1.3.1.2 SG as relay-point
A Global Title translation must be executed at the SG, before the
destination of the message can be determined. The actual location
of the SCCP-user is irrelevant to the SS7 network. GT Translation
yields an "SCCP entity set", which now may contain one or more AS.
Selection of the AS is thus based on the SCCP called party address
(and possibly other SS7 parameters depending on the implementation).
Basically this means splitting the SS7 traffic over different AS's
based on GT information. After this, the same as in 1.3.1.1
applies.
1.3.2 Protocol Architecture for Connection-Oriented Transport
In this architecture, the SCCP and SUA layers interface in the SG to
associate the two connection sections needed for the connection-
oriented data transfer between SEP and ASP. Both connection
sections are setup when routing the Connect Request messages from
SEP via SG to ASP. The routing of the Connect Request message is
done in the same wavy as described in 1.3.1.
Further messages for this connection are routed on DPC in the SS7
connection section (MTP routing label), and on IP address in the IP
connection section (SCTP header). No other routing information is
present in the SCCP or SUA messages themselves. Resources are kept
within the SG to forward messages from one section to another and to
populate the MTP routing label or SCTP header, based on the
destination local reference of these messages (Connect Confirm, Data
Transfer, ...)
******** SS7 *************** IP ********
* SEP *---------* *--------* *
* or * * SG * * ASP *
Loughney, et al. [Page 7]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
* STP * * * * *
******** *************** ********
+------+ +------+
| S7AP | | S7AP |
+------+ +------+------+ +------+
| SCCP | | SCCP | SUA | | SUA |
+------+ +------+------+ +------+
| MTP3 | | MTP3 | | | |
+------| +------+ SCTP | | SCTP |
| MTP2 | | MTP2 | | | |
+------+ +------+------+ +------+
| L1 | | L1 | IP | | IP |
+------+ +------+------+ +------+
| | | |
+---------------+ +------------+
S7AP - SS7 Application Protocol (e.g. - RANAP/RNSAP)
STP - SS7 Signaling Transfer Point
The above architecture may simplify, in some cases, to carrying SS7
application protocols between two IP based endpoints. In this
scenario, full SG functionality may not be needed. This
architecture is considered in the next section.
1.3.3 All IP Architecture
This architecture can be used to carry a protocol which uses the
transport services of SCCP, but is contained with an IP network.
This allows extra flexibility in developing networks, especially
when interaction between legacy signaling is not needed. The
architecture removes the need for signaling gateway functionality.
******** IP ********
* *--------* *
* AS * * AS *
* * * *
******** ********
+------+ +------+
| AP | | AP |
+------+ +------+
| SUA | | SUA |
+------+ +------+
| SCTP | | SCTP |
+------+ +------+
| IP | | IP |
+------+ +------+
| |
+----------------+
Loughney, et al. [Page 8]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
AP - Application Protocol (e.g. - RANAP/RNSAP)
In the case where a collision occurs during initiation, there exist
two possible solutions: 1) if there are sufficient resources, both
initiations could be accepted; 2) both ASPs should back-off and
after some amount of time, later re-establish an initiation.
1.3.4 Generalized Point-to-Point Network Architecture
Figure 1 shows an example network architecture which can support
robust operation and failover support. There needs to be some
management resources at the AS to manage traffic.
***********
* AS1 *
* +-----+ * SCTP Associations
* |ASP1 +-------------------+
* +-----+ * | ***********
* * | * AS3 *
* +-----+ * | * +-----+ *
* |ASP2 +-----------------------------------------+ASP1 | *
* +-----+ * | * +-----+ *
* * | * *
* +-----+ * | * +-----+ *
* |ASP3 | * +--------------------------+ASP2 | *
* +-----+ * | | * +-----+ *
*********** | | ***********
| |
*********** | | ***********
* AS2 * | | * AS4 *
* +-----+ * | | * +-----+ *
* |ASP1 +--------------+ +---------------------+ASP1 | *
* +-----+ * * +-----+ *
* * * *
* +-----+ * * +-----+ *
* |ASP2 +-----------------------------------------+ASP1 | *
* +-----+ * * +-----+ *
* * ***********
* +-----+ *
* |ASP3 | *
* +-----+ *
* *
***********
Figure 1: Generalized Architecture
In this example, the Application Servers are shown residing within
one logical box, with ASPs located inside. In fact, an AS could be
distributed among several hosts. In such a scenario, the host
should share state as protection in the case of a failure.
Loughney, et al. [Page 9]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
Additionally, in a distributed system, one ASP could be registered
to more than one AS. This draft should not restrict such systems -
though such a case in not specified.
1.3.5 Generalized Signaling Gateway Network Architecture
When interworking between SS7 and IP domains is needed, the SG acts
as the gateway node between the SS7 network and the IP network. The
SG will transport SCCP-user signaling traffic from the SS7 network
to the IP-based signaling nodes (for example IP-resident
Databases). The Signaling Gateway can be considered as a group of
Application Servers with additional functionality to interface
towards an SS7 network.
The SUA protocol should be flexible enough to allow different
configurations and transport technology to allow the network
operators to meet their operation, management and performance
requirements.
Figure 2 shows a possible realization of this architecture, with
Signaling Gateway functionality.
Signaling Gateway
****************
* +----------+ * **************
* | AS1 | * * AS3 *
* | ******** | * * ******** *
* | * SGP1 +---------------------------------------------+ ASP1 * *
* | ******** | * * ******** *
* | ******** | * * ******** *
* | * SGP2 +--------------------------+ +----------+ ASP2 * *
* | ******** | * | | * ******** *
* +----------+ * | | * . *
* +----------+ * | | * . *
* | AS2 | * | | * . *
* | ******** | * | | * ******** *
* | * SGP1 +----------------------------------+ * * ASPN * *
* | ******** | * SCTP Associations | * ******** *
* | ******** | * | **************
* | * SGP2 +---------------- |
* | ******** | * | | **************
* +----------+ * | | * AS4 *
**************** | | * ******** *
| +------------------+ ASP1 * *
| * ******** *
| * . *
| * . *
| * *
| * ******** *
+-----------------------------+ ASPn * *
* ******** *
Loughney, et al. [Page 10]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
**************
Figure 2: Signaling Gateway Architecture
The pair of SGs can either operate as replicated endpoints or as
replicated relay points from the SS7 network point of view.
Replicated endpoints : only for the first message in a transaction
or connection one of the SGs is chosen, depending on the traffic
mode (primary/backup or loadsharing) and overload conditions. Once
selected, the same SG is used for the subsequent messages.
Replicated relay points : in normal circumstances, the path from SEP
to ASP will always go via the same SG when in-sequence-delivery is
requested. However, linkset failures may cause MTP to re-route to
the other SG.
1.3.6 ASP Fail-over Model and Terminology
The SUA protocol supports ASP fail-over functions in order to
support a high availability of transaction processing capability.
An Application Server can be considered as a list of all ASPs
configured/registered to handle SCCP-user messages within a certain
range of routing information, known as a Routing Key. One or more
ASPs in the list may normally be active to handle traffic, while
others may be inactive but available in the event of failure or
unavailability of the active ASP(s).
1.4 Services Provided by the SUA Layer
1.4.1 Support for the transport of SCCP-User Messages
The SUA needs to support the transfer of SCCP-user messages. The SUA
layer at the SG needs to seamlessly transport the user messages.
1.4.2 SCCP Protocol Class Support
Depending upon the SCCP-users supported, the SUA shall support the 4
possible SCCP protocol classes transparently. The SCCP protocol
classes are defined as follows:
* Protocol class 0 provides unordered transfer of SCCP-user
messages in a connectionless manner.
* Protocol class 1 allows the SCCP-user to select the in-sequence
delivery of SCCP-user messages in a connectionless manner.
* Protocol class 2 allows the bi-directional transfer of SCCP-user
messages by setting up a temporary or permanent signaling
connection.
Loughney, et al. [Page 11]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
* Protocol class 3 allows the features of protocol class 2 with
the inclusion of flow control. Detection of message loss or
mis-sequencing is included.
Protocol classes 0 and 1 make up the SCCP connectionless service.
Protocol classes 2 and 3 make up the SCCP connection-oriented
service.
1.4.3 Native Management Functions
The SUA layer may provide management of the underlying SCTP layer to
ensure that transport is available according to the degree specified
by the SCCP-user application.
The SUA layer provides the capability to indicate errors associated
with the SUA-protocol messages and to provide notification to local
management and the remote peer as is necessary.
1.4.4 Interworking with SCCP Network Management Functions
The SUA layer needs to support the following SCCP network management
primitives (a reference to ITU and ANSI sections where these
primitives and corresponding parameters are described, is also
given):
Generic |Specific |
Name |Name |ANSI/ITU Reference
----------+-----------+---------------------------------------------
N-Coord |Request |ITU-Q.711 Chap 6.3.2.3.1 (Tab 13/Q.711)
|Indication |ANSI-T1.112 Chap 2.3.2.3.1 (Tab 8D/T1.112.1)
|Response |
|Confirm |
----------+-----------+---------------------------------------------
N-State |Request |ITU-Q.711 Chap 6.3.2.3.2 (Tab 14/Q.711)
|Indication |ANSI-T1.112 Chap 2.3.2.3.2 (Tab 8E/T1.112.1)
----------+-----------+---------------------------------------------
N-Pcstate |Indication |ITU-Q.711 Chap 6.3.2.3.3 (Tab 15/Q.711)
| |ANSI-T1.112 Chap 2.3.2.3.4 (Tab 8G/T1.112.1)
1.4.5 Support for the management between the SG and ASP.
The SUA layer should provide interworking with SCCP management
functions at the SG for seamless inter-operation between the SCN
network and the IP network. It should:
* Provide an indication to the SCCP-user at an ASP
that a remote SS7 endpoint/peer is unreachable.
* Provide an indication to the SCCP-user at an ASP
that a remote SS7 endpoint/peer is reachable.
* Provide congestion indication to SCCP-user at an ASP.
Loughney, et al. [Page 12]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
* Provide the initiation of an audit of remote SS7
endpoints at the SG.
1.4.6 Relay function
An SCTP association exists between two SUA endpoints. For network
scalability purposes, the SUA may be enhanced with a relay
functionality to determine the next hop SCTP association towards the
destination SUA endpoint.
The determination of the next hop may be based on Global Title
information (e.g. E.164 number), in analogy with SCCP GTT in SS7
networks, modelled in [ITU-T Q.714]. It may also be based on
Hostname information.
The relay function is invoked when :
- routing is on Global Title,
- routing is on Hostname.
Translation/resolution of the above address information must yield
either of the following :
- Route on SSN : SCTP association ID towards the destination node +
SSN + Network Appearance (optional)
- Route on GT : SCTP association ID towards next relay node + (new)
GT + SSN (optional) + Network Appearance (optional)
- Routing on Hostname : SCTP association ID towards next relay node
+ (new) Hostname + SSN (optional) + Network Appearance (optional)
- A local SUA-user (combined relay/end node)
To prevent endless hopping, the hop counter is used. The originating
end node (be it an SS7 or an IP node) sets the value of the hop
counter to the maximum value (15). Each time the relay function is
invoked within an intermediate (relay) node, the hop counter must be
decremented. When the value reaches zero, and the translation result
is still _Route on GT_ or _Route on Hostname_, the return or refusal
procedures are invoked with reason _Hop counter violation_.
1.5 Internal Functions Provided in the SUA Layer
1.5.1 Address Translation and Mapping at the SG
The SG MUST provide address translation and mapping functions to
direct messages received from the SS7 network to the appropriate IP
destination.
In order to support message distribution, the SG maintains an
address translation table, which maps the incoming SS7 messages to
the appropriate AS. The relevant fields of the incoming SS7 message
is compared to the existing Routing Keys. The Routing Keys
Loughney, et al. [Page 13]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
reference an Application Server, which will have one or more ASPs
processing traffic for the AS. The availability and status of the
ASPs is handled by SUA ASP management messages.
Possible SS7 address/routing information that comprise
a Routing Key entry includes, for example, OPC, DPC, SIO found in
the MTP3 routing label, or other specific fields such as the
SCCP subsystem number, or TCAP transaction ID. Some possibilities
include:
Global Title (+ SSN optionally)
PC (+ SSN optionally)
Host Name (+ SSN optionally)
IP Address(es) (+ SSN optionally)
An Application Server maintains a list of ASPs that are available to
process the traffic. The list is dynamic, based upon the
availability of the individual ASPs in the list. SUA ASP management
messages are used to convey the status of these ASPs and their
availability in failover situations.
Normally, one or more ASPs is active in the ASP (i.e., currently
processing traffic) but in certain failure and transition cases it
is possible that there may not be an active ASP available. Both
load-sharing and backup scenarios are supported.
If there is no Routing Key match for an incoming SS7 message, a
default treatment MUST be specified. Possible solutions are to
provide a default Application Server to direct all unallocated
traffic to a (set of) default ASP(s), or to drop the messages and
provide a notification to management. The treatment of unallocated
traffic is implementation dependent.
1.5.2 Address Translation and Mapping at the ASP
In order to direct messages to the SS7 network, the ASP must also
perform an address translation and mapping function in order to
choose the proper SG or SGP for a given message. This is
accomplished by observing the Destination Point Code and other
elements of the outgoing message, SS7 network status, SG and SGP
availability, and network appearance configuration tables.
A remote Signaling Gateway may be composed of one or more SGPs that
are capable of routing SS7 traffic. As is the case with ASPs, a
dynamic list of SGPs in an SG can be maintained, taking into account
the availability status of the individual SGPs, configuration
changes and fail-over mechanisms. There is, however, no SUA
messaging to manage the status of an SGP. Whenever an SCTP
association to an SGP exists, it is assumed to be available. Also,
every SGP of one SG communicating with one ASP regarding one AS
provides identical SS7 connectivity to this ASP.
Loughney, et al. [Page 14]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
1.5.3 SCTP Stream Mapping
The SUA supports SCTP streams. The SG/AS needs to maintain a list of
SCTP and SUA-users for mapping purposes. SCCP-users requiring
sequenced message transfer need to be sent over a stream supporting
sequenced delivery.
SUA MUST use stream 0 for SUA management messages. It is recommended
that sequenced delivery be in order to preserve the order of
management message delivery.
1.6 Definition of SUA Boundaries
1.6.1 Definition of the upper boundary
The following primitives are supported between the SUA and an SCCP-
user (a reference to ITU and ANSI sections where these primitives
and corresponding parameters are described, is also given):
Generic |Specific |
Name |Name |ANSI/ITU Reference
------------+----------+-------------------------------------------
N-Connect |Request |ITU-Q.711 Chap 6.1.1.2.2 (Tab 2/Q.711)
|Indication|ANSI-T1.112 Chap 2.1.1.2.2 (Tab 2/T1.112.1)
|Response |
|Confirm |
------------+----------+-------------------------------------------
N-Data |Request |ITU-Q.711 Chap 6.1.1.2.3 (Tab 3/Q.711)
|Indication|ANSI-T1.112 Chap 2.1.1.2.3 (Tab 3/T1.112.1)
------------+----------+-------------------------------------------
N-Expedited |Request |ITU-Q.711 Chap 6.1.1.2.3 (Tab 4/Q.711)
Data |Indication|ANSI-T1.112 Chap 2.1.1.2.3 (Tab 4/T1.112.1)
------------+----------+-------------------------------------------
N-Reset |Request |ITU-Q.711 Chap 6.1.1.2.3 (Tab 5/Q.711)
|Indication|ANSI-T1.112 Chap 2.1.1.2.3 (Tab 5/T1.112.1)
|Response |
|Confirm |
------------+----------+-------------------------------------------
N-Disconnect|Request |ITU-Q.711 Chap 6.1.1.2.4 (Tab 6/Q.711)
|Indication|ANSI-T1.112 Chap 2.1.1.2.4 (Tab 6/T1.112.1)
------------+----------+-------------------------------------------
N-Inform |Request |ITU-Q.711 Chap 6.1.1.3.1 (Tab 7/Q.711)
|Indication|ANSI-T1.112 Chap 2.1.1.2.5 (Tab 6A/T1.112.1)
------------+----------+-------------------------------------------
N-Unit Data |Request |ITU-Q.711 Chap 6.2.2.3.1 (Tab 10/Q.711)
|Indication|ANSI-T1.112 Chap 2.2.2.3.1 (Tab 8A/T1.112.1)
------------+----------+-------------------------------------------
N-Notice |Indication|ITU-Q.711 Chap 6.2.2.3.2 (Tab 11/Q.711)
| |ANSI-T1.112 Chap 2.2.2.3.2 (Tab 8B/T1.112.1)
Loughney, et al. [Page 15]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
1.6.2 Definition of the lower boundary
The upper layer primitives provided by the SCTP are provided in
[SCTP].
2 Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as described in
[RFC2119].
3 Protocol Elements
The general message format includes a Common Message Header together
with a list of zero or more parameters as defined by the Message
Type.
For forward compatibility, all Message Types may have attached
parameters even if none are specified in this version.
3.1 Common Message Header
The protocol messages for the SCCP-User Adaptation Protocol requires
a message structure which contains a version, message type, message
length and message contents. This message header is common among
all signaling protocol adaptation layers:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Reserved | Message Class | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg data |
Note that the 'data' portion of SUA messages SHALL contain SCCP-User
data, not the encapsulated SCCP message.
Optional parameters can only occur at most once in an SUA message.
3.1.1 SUA Protocol Version
The version field (ver) contains the version of the SUA adaptation
layer. The supported versions are:
01 SUA version 1.0
3.1.2 Message Classes
Loughney, et al. [Page 16]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
Message Classes
0 Management (MGMT) Message
1 Reserved
2 SS7 Signaling Network Management (SSNM) Messages
3 ASP State Maintenance (ASPSM) Messages
4 ASP Traffic Maintenance (ASPTM) Messages
5 Reserved
6 Reserved
7 Connectionless Messages
8 Connection-Oriented Messages
9 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
3.1.3 Message Types
SUA Management Messages
0 Error (ERR)
1 Notify (NTFY)
2 - 127 Reserved by the IETF
128- 255 Reserved for IETF-Defined Message Class Extensions
SS7 Signaling Network Management (SSNM) Messages
0 Reserved
1 Destination Unavailable (DUNA)
2 Destination Available (DAVA)
3 Destination State Audit (DAUD)
4 SS7 Network Congestion (SCON)
5 Destination User Part Unavailable (DUPU)
6 SCCP Management (SCMG)
7 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
Application Server Process Maintenance (ASPM) Messages
0 Reserved
1 ASP Up (UP)
2 ASP Down (DOWN)
3 Heartbeat (BEAT)
4 ASP Up Ack (UP ACK)
5 ASP Down Ack (Down ACK)
6 Heartbeat Ack (BEAT ACK)
7 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
ASP Traffic Maintenance (ASPTM) Messages
0 Reserved
1 ASP Active (ACTIVE)
Loughney, et al. [Page 17]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
2 ASP Inactive (INACTIVE)
3 ASP Active Ack (ACTIVE ACK)
4 ASP Inactive Ack (INACTIVE ACK)
5 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
Connectionless Messages
0 Reserved
1 Connectionless Data Transfer (CLDT)
2 Connectionless Data Response (CLDR)
3 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
Connection-Oriented Messages
0 Reserved
1 Connection Request (CORE)
2 Connection Acknowledge (COAK)
3 Connection Refused (COREF)
4 Release Request (RELRE)
5 Release Complete (RELCO)
6 Reset Confirm (RESCO)
7 Reset Request (RESRE)
8 Connection Oriented Data Transfer (CODT)
9 Connection Oriented Data Acknowledge (CODA)
10 Connection Oriented Error (COERR)
11 Inactivity Test (COIT)
12 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
3.1.4 Message Length
The Message Length defines the length of the message in octets,
including the header.
3.1.5 Tag-Length-Value Format
SUA messages consist of a Common Header followed by zero or more
parameters, as defined by the message type. The Tag-Length-Value
(TLV) parameters contained in a message are defined in a Tag-
Length-Value format as shown below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Tag | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Parameter Value /
\ \
Loughney, et al. [Page 18]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Tag: 16 bits (unsigned integer)
Tag field is a 16-bit identifier of the type of parameter. It
takes a value of 0 to 65534.
Parameter Length: 16 bits (unsigned integer)
The Parameter Length field contains the size of the parameter in
bytes, including the Parameter Tag, Parameter Length, and
Parameter Value fields. The Parameter Length does not include any
padding bytes.
Parameter Value: variable-length.
The Parameter Value field contains the actual information to be
transferred in the parameter.
The total length of a parameter (including Tag, Parameter Length
and Value fields) MUST be a multiple of 4 bytes. If the length of
the parameter is not a multiple of 4 bytes, the sender pads the
Parameter at the end (i.e., after the Parameter Value field) with
all zero bytes. The length of the padding is NOT included in the
parameter length field. A sender should NEVER pad with more than
3 bytes. The receiver MUST ignore the padding bytes.
Implementation note : the use of TLV in principle allows the
parameters to be placed in a random order in the message. However,
some guidelines should be considered for easy processing in the
following order :
- parameters needed to correctly process other message parameters,
preferably should precede these parameters (such as Network
Appearance), mandatory parameters preferably should precede any
optional parameters,
- the data parameter will normally be the final one in the message.
3.2 SUA Connectionless Messages
The following section describes the SUA Connectionless transfer
messages and parameter contents. The general message format
includes a Common Message Header together with a list of zero or
more parameters as defined by the Message Type. All Message Types
can have attached parameters.
3.2.1 Connectionless Data Transfer (CLDT)
This message transfers data between one SUA to another.
0 1 2 3
Loughney, et al. [Page 19]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0101 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0102 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Source Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Network Appearance Optional
Flags Mandatory
Source Address Mandatory
Destination Address Mandatory
Data Mandatory
Implementation Note:
This message covers the following SCCP messages: unitdata (UDT),
extended unitdata (XUDT), long unitdata (LUDT).
3.2.2 Connectionless Data Response (CLDR)
This message is used as a response message by the peer to report
errors in the received CLDT message, when the return on error option
is set.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
Loughney, et al. [Page 20]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0101 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCCP Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0102 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Source Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Network Appearance Optional
Flags Mandatory
SCCP Cause Mandatory
Source Address Mandatory
Destination Address Mandatory
Data Optional
Implementation note:
This message covers the following SCCP messages: unitdata service
(UDTS), extended unitdata service (XUDTS) and long unitdata service
(LUDTS).
3.3 Connection Oriented Messages
3.3.1 Connection Oriented Data Transfer (CODT)
This message transfers data between one SUA to another for
connection oriented service.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0107 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loughney, et al. [Page 21]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
| Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Sequence number Mandatory *1
Destination Reference Number Mandatory
Data Mandatory
NOTE *1: Mandatory when CODT message maps a DT2 message.
Otherwise, the parameter is not be present.
Implementation note:
This message covers the following SCCP messages: data form 1 (DT1),
data form 2 (DT2), expedited data (ED).
3.3.2 Connection Oriented Data Acknowledge (CODA)
This message is used to acknowledge receipt of data by the peer.
This message is used only with protocol class 3.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0108 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010A | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Loughney, et al. [Page 22]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
Network Appearance Optional
Destination Reference Number Mandatory
Receive Sequence number Mandatory *1
Credit Mandatory *1
NOTE *1: Mandatory when representing Data Acknowledgement (AK).
Implementation note:
This message covers the following SCCP messages: Data
Acknowledgement (AK), Expedited Data Acknowledgement (EA).
3.3.3 Connection Request (CORE)
This message is used for establishing a signaling connection between
two peer endpoints. This is used for connection oriented service.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0101 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0104 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0102 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Source Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010A | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loughney, et al. [Page 23]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
Parameters
Flags Mandatory
Source Reference Number Mandatory
Destination Address Mandatory
Source Address Optional
Credit Optional
Data Optional
3.3.4 Connection Acknowledge (COAK)
This message is used to acknowledge a connection request between two
peer endpoints.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0101 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0104 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010A | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Flags Mandatory
Destination Reference Number Mandatory
Source Reference Number Mandatory
Credit Optional *2
Destination Address Optional *1
Data Optional
Loughney, et al. [Page 24]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
NOTE *1: Destination Address parameter will be present in case
that the received CORE message conveys the Source
Address parameter.
Note *2: Used for protocol class 3.
Implementation note:
This message covers the following SCCP message: Connection Confirm
(CC).
3.3.5 Connection Refused (COREF)
This message is used to refuse a connection request between two peer
endpoints.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCCP Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Destination Reference Number Mandatory
SCCP Cause Mandatory
Destination Address Optional *1
Data Optional
Note *1: Destination Address parameter will be present in case
that the received CORE message conveys the Source
Address parameter.
Loughney, et al. [Page 25]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
3.3.6 Release Request (RELRE)
This message is used to request a signaling connection between two
peer endpoints be released. All associated resources can then be
released.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0104 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCCP Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0101 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Destination Reference Number Mandatory
Source Reference Number Mandatory
SCCP Cause Mandatory
Flags Optional
Data Optional
Implementation Note:
This message covers the following SCCP message: Connection Refused
(RLSD).
3.3.7 Release Complete (RELCO)
This message is used to acknowledge the release of a signaling
connection between two peer endpoints. All associated resources
should be released.
0 1 2 3
Loughney, et al. [Page 26]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0104 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Destination Reference Number Mandatory
Source Reference Number Mandatory
Implementation Note:
This message covers the following SCCP message: Release Complete
(RLC).
3.3.8 Reset Request (RESRE)
This message is used to indicate that the sending SCCP/SUA wants to
initiate a reset procedure (re-initialization of sequence numbers)
the peer endpoint.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0104 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCCP Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Destination Reference Number Mandatory
Source Reference Number Mandatory
SCCP Cause Mandatory
Implementation note:
This message covers the following SCCP message: reset request (RSR).
Loughney, et al. [Page 27]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
3.3.9 Reset Confirm (RESCO)
This message is used to confirm the Reset Request.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0104 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Destination Reference Number Mandatory
Source Reference Number Mandatory
Implementation note:
This message covers the following SCCP message: Reset Confirmation
(RSC).
3.3.10 Connection Oriented Error (COERR)
The COERR message is sent to indicate a protocol data unit error.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCCP Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Destination Reference Number Mandatory
SCCP Cause Mandatory
Implementation Note:
This message covers the following SCCP message: Protocol Data Unit
Error (ERR)
Loughney, et al. [Page 28]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
3.3.11 Connection Oriented Inactivity Test (COIT)
This message is used for auditing the signaling connection state and
the consistency of connection data at both ends of the signaling
connection.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0101 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0104 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0107 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010A | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Flags Mandatory
Source Reference Number Mandatory
Destination Reference number Mandatory
Sequence number Mandatory *1
Credit Mandatory *1
NOTE *1: Information in these parameter fields reflect those
values sent in the last data form 2 or data
acknowledgement message. They are ignored if the
protocol class indicates class 2.
Implementation note:
This message covers the following SCCP message: Inactivity Test
(IT).
3.4 SS7 Signaling Network Management Messages
3.4.1 Destination Unavailable (DUNA)
Loughney, et al. [Page 29]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
In the scope of SUA, this message is covered by the PC state
indication passed between SCCP and local SCCP-user. The DUNA message
is sent from the SG to all concerned ASPs (servicing SCCP-users
considered local to the SG, see chapter 1.3.1.1), when an SS7
destination has become unreachable. The SUA-User at the ASP is
expected to stop traffic to the affected destination through the SG
initiating the DUNA.
The format for DUNA Message parameters is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0005 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Affected Point Code /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Network Appearance Optional
Affected Point Code Mandatory
Info String Optional
3.4.2 Destination Available (DAVA)
In the scope of SUA, this message is covered by the PC state
indication passed between SCCP and local SCCP-user. The DAVA message
is sent from the SG to all concerned ASPs (servicing SCCP-users
considered local to the SG, see chapter 1.3.1.1) to indicate that an
SS7 destination is now reachable. The ASP SUA-User protocol is
expected to resume traffic to the affected destination through the
SG initiating the DAVA.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0005 | Length |
Loughney, et al. [Page 30]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Affected Point Code /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Network Appearance Optional
Affected Point Code Mandatory
Info String Optional
3.4.3 Destination State Audit (DAUD)
The DAUD message can be sent from the ASP to the SG to query the
availability state of the SS7 routes to an affected destination. A
DAUD may be sent periodically after the ASP has received a DUNA,
until a DAVA is received. The DAUD can also be sent when an ASP
recovers from isolation from the SG.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0005 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Affected Point Code /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Network Appearance Optional
Affected Point Code Mandatory
Info String Optional
3.4.4 SS7 Network Congestion (SCON)
The SCON message can be sent from the SG to all concerned ASPs to
indicate that the congestion level in the SS7 network to a specified
destination has changed.
Loughney, et al. [Page 31]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0010 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000E | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ Affected PC \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ info string /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Network Appearance Optional
Congestion Level Mandatory
Affected PC Mandatory
Info String Optional
3.4.5 Destination User Part Unavailable (DUPU)
The DUPU message is used in local broadcast procedures (SUA for SCCP
- SCCP user interface). In remote broadcast procedures, use SCMG
message formatID SSP (peer SUA message)
The format for DUPU Message parameters is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0005 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Affected Point Code /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0009 | Length |
Loughney, et al. [Page 32]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause/User |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ info string /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Network Appearance Optional
Affected Point Code Mandatory Note *1
Cause/User Mandatory
Info String Optional
3.4.6 SCCP Management Message (SCMG)
The SCMG message is sent between SUA Peers to indicate status of
subsystems. Only one SCMG message type can be sent per message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010B | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCMG Format Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010C | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMI/Subsystem |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0005 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Affected PC /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000E | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ INFO String \
\ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Loughney, et al. [Page 33]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
Network Appearance Optional
SCMG Format Identifier Mandatory
Subsystem/SMI Mandatory
Affected Point Code Mandatory *1
Congestion Level Mandatory *2
Info String Optional
Note *1: In the SCMG message, the Affected Point Code Parameter
MUST contain, at most, a single Affected Point Code.
Note *2: When the SCMG Message Type is SSC, then the Congestion
Level parameter is Mandatory, otherwise it is not
present.
3.5 Application Server Process Maintenance Messages
3.5.1 ASP Up (UP)
The ASP UP (UP) message is used to indicate to a remote SUA peer
that the Adaptation layer is up and running.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0109 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
ASP Capabilities Optional
Info String Optional
3.5.2 ASP Up Ack (UP ACK)
The ASP UP Ack message is used to acknowledge an ASP-Up message
received from a remote SUA peer.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0109 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
Loughney, et al. [Page 34]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
ASP Capabilities Optional
Info String Optional
3.5.3 ASP Down (DN)
The ASP Down (DN) message is used to indicate to a remote SUA peer
that the adaptation layer is not running.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000A | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Reason Mandatory
Info String Optional
3.5.4 ASP Down Ack (DOWN ACK)
The ASP DOWN Ack message is used to acknowledge an ASP-Down message
received from a remote SUA peer.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000A | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Reason Mandatory
Loughney, et al. [Page 35]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
Info String Optional
3.5.5 Heartbeat (BEAT)
The Heartbeat message is optionally used to ensure that the SUA
peers are still available to each other.
The format for the BEAT message is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0008 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Heartbeat Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Heartbeat Data Optional
3.5.6 Heartbeat Ack (BEAT ACK)
The Heartbeat ACK message is sent in response to a BEAT message. A
peer MUST send a BEAT ACK in response to a BEAT message. It includes
all the parameters of the received Heartbeat message, without any
change.
The format for the BEAT ACK message is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0008 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Heartbeat Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Heartbeat Data Optional
3.6 ASP Traffic Maintenance Messages
3.6.1 ASP Active (ACTIVE)
The ASPAC message is sent by an ASP to indicate to a remote SUA peer
that it is Active and ready to process signaling traffic for a
particular Application Server
The format for the ACTIVE message is as follows:
Loughney, et al. [Page 36]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000B | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Traffic Mode Type Mandatory
Routing Context Optional
Info String Optional
3.6.2 ASP Active Ack (ACTIVE ACK)
The ASPAC Ack message is used to acknowledge an ASP-Active message
received from a remote SUA peer.
The format for the ACTIVE Ack message is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000B | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Mode Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Traffic Mode Type Mandatory
Loughney, et al. [Page 37]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
Routing Context Optional
Info String Optional
The format of the Traffic Mode Type and Routing Context parameters
is the same as for the ASP-Active message.
The format and description of the optional Info String parameter is
the same as for the ASP-Active message.
3.6.3 ASP Inactive (INACTIVE)
The INACTIVE message is sent by an ASP to indicate to a remote SUA
peer that it is no longer processing signaling traffic within a
particular Application Server.
The format for the ASPIA message parameters is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Optional
INFO String Optional
3.6.4 ASP Inactive Ack (INACTIVE ACK)
The INACTIVE Ack message is used to acknowledge an ASP-Inactive
message received from a remote SUA peer.
The format for the INACTIVE Ack message is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
Loughney, et al. [Page 38]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ INFO String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Optional
INFO String Optional
The format of the Traffic Mode Type and Routing Context parameters
is the same as for the ASP-Active message.
The format and description of the optional Info String parameter is
the same as for the ASP-Active message.
3.7 Management Messages
These messages are used for managing SUA and the representations of
the SCCP subsystems in the SUA layer.
3.7.1 Error (ERR)
The ERR message is sent between two SUA peers to indicate an error
situation. The Data parameter is optional, possibly used for error
logging and/or debugging.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000C | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0007 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Diagnostic Info /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Error Code Mandatory
Diagnostic Info Optional
3.7.2 Notify (NTFY)
The Notify message used to provide an autonomous indication of SUA
events to an SUA peer.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loughney, et al. [Page 39]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
| Tag = 0x000D | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type/ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The NTFY message contains the following parameters:
Parameters
Status Type/ID Mandatory
Routing Context Optional
Info String Optional
3.8 Common Parameters
These TLV parameters are common across the different adaptation
layers.
Parameter Name Parameter ID
============== ============
Network Appearance 0x0001
Not used in SUA 0x0002
Data 0x0003
Info String 0x0004
Affected Point Code 0x0005
Routing Context 0x0006
Diagnostic Info 0x0007
Heartbeat Data 0x0008
Cause/User 0x0009
Reason 0x000A
Traffic Mode Type 0x000B
Not used 0x000C
Status Type 0x000D
Congestion Level 0x000E
3.8.1 Network Appearance
The Network Appearance parameter identifies the SS7 network context
for the message, for the purposes of logically separating the
signaling traffic between the SG and the Application Server Process
over a common SCTP Association. An example is where an SG is
Loughney, et al. [Page 40]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
logically partitioned to appear as an element in several different
national SS7 networks.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| network appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Network Appearance implicitly defines the SS7 Point Code format
used, the SS7 Network Indicator value and SCCP protocol
type/variant/version used within the SS7 network partition. Where
an SG operates in the context of a single SS7 network, or individual
SCTP associations are dedicated to each SS7 network context, the
Network Appearance parameter is not required.
The Network Appearance parameter value is of local significance
only, coordinated between the SG and ASP.
Where the optional Network Appearance parameter is present, it must
be the first parameter in the message as it defines the format of
the Protocol Data field.
3.8.2 Not used
Parameter ID 0x02 is not used in SUA.
3.8.3 Data
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Data parameter field contains the SS7 SCCP-User application
message, for example an INAP/TCAP message.
3.8.4 Info String
The INFO String parameter can carry any meaningful 8-BIT ASCII
character string along with the message. Length of the INFO String
parameter is from 0 to 255 characters. No procedures are presently
identified for its use but the INFO String may be used by Operators
for debugging purposes.
Loughney, et al. [Page 41]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ info string /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.8.5 Affected Point Code
The Affected Point Code parameter contains one or more Affected
Destination Point Codes, each a three-octet parameter to allow for
4-, 16- and 24-bit binary formatted SS7 Point Codes. Affected Point
codes that are less than 24-bits, are padded on the left to the 24-
bit boundary.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0005 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Affected PC 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ . . . /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The encoding is shown below for ANSI and ITU Point Code examples.
ANSI 24-bit Point Code:
0 1 2 3-->
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask | Network | Cluster | Member |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MSB-----------------------------------------LSB|
ITU 14-bit Point Code:
0 1 2 3-->
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask |0 0 0 0 0 0 0 0 0 0|Zone | Region | SP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MSB--------------------LSB|
Loughney, et al. [Page 42]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
It is optional to send an Affected Pointe Code parameter with more
than one Affected PC but it is mandatory to receive it. All the
Affected PCs included must be within the same Network Appearance.
Including multiple Affected PCs may be useful when reception of an
management message or a linkset event simultaneously affects the
availability status of a list of destinations at an SG.
Mask: 8-bits
The Mask parameter can be used to identify a contiguous range of
Affected Destination Point Codes, independent of the point code
format. Identifying a contiguous range of Affected PCs may be
useful when reception of an MTP3 management message or a linkset
event simultaneously affects the availability status of a series of
destinations at an SG.
The Mask parameter is an integer representing a bit mask that can be
applied to the related Affected PC field. The bit mask identifies
how many bits of the Affected PC field is significant and which are
effectively "wild-carded". For example, a mask of "8" indicates
that the last eight bits of the PC is "wild-carded". For an ANSI
24-bit Affected PC, this is equivalent to signaling that all PCs in
an ANSI Cluster are unavailable. A mask of "3" indicates that the
last three bits of the PC is "wild-carded". For a 14-bit ITU
Affected PC, this is equivalent to signaling that an ITU Region is
unavailable.
3.8.6 Routing Context
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Routing Context parameter contains (a list of) 4-byte unsigned
integers indexing the Application Server traffic that the sending
ASP is configured/registered to receive. There is one-to-one
relationship between an index entry and a SG Routing Key or AS Name.
Since an AS can only appear in one Network Appearance, the Network
Appearance parameter is not required in the ASP Active message.
An Application Server Process may be configured to process traffic
for more than one logical Application Server. From the perspective
of an ASP, a Routing Context defines a range of signaling traffic
that the ASP is currently configured to receive from the SG.
Loughney, et al. [Page 43]
Internet Draft SS7 SCCP-User Adaptation Layer February 1, 2000
3.8.7 Diagnostic Information
The Diagnostic Information can be used to convey any information
relevant to an error condition, to assist in the identification of
the error condition. In the case of an Invalid Network Appearance,
Adaptation Layer Identifier or Traffic Handling Mode, the Diagnostic
information includes the received parameter. In the other cases,
the Diagnostic information may be the first 40 bytes of the
offending message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0007 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Diagnostic Information* /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.8.8 Heartbeat Data
The Heartbeat Data field contents are defined by the sending node.
It may include a Heartbeat Sequence Number and/or Timestamp, other
implementation specific details.
The receiver of a Heartbeat message does not process this field as
it is only of significance to the sender. The receiver echoes the
content of the Heartbeat Data in a BEAT-Ack message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0008 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Heartbeat Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The data field can be used to store information in the heartbeat
message useful to the sending node (e.g. the data field can contain
a time stamp, a sequence number, etc.).
3.8.9 Cause/User
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0009 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause | User |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- |
Documentation