| draft-ietf-sigtran-sua-06 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-06.txt.
INTERNET-DRAFT J. Loughney (Editor)
Internet Engineering Task Force Nokia
G. Sidebottom, Guy Mousseau
Issued: 15 June 2001 Nortel Networks
Expires: 15 December 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-06.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 15 December 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 June 15, 2001
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 .............................12
1.5 Internal Functions Provided in the SUA Layer ...................14
1.6 Definition of SUA Boundaries ...................................16
2 Conventions........................................................17
3 Protocol Elements..................................................17
3.1 Common Message Header ..........................................17
3.2 SUA Connectionless Messages ....................................21
3.3 Connection Oriented Messages ...................................23
3.4 Signaling Network Management Messages ..........................30
3.5 Application Server Process State Maintenance Messages ..........34
3.6 ASP Traffic Maintenance Messages ...............................36
3.7 SUA Management Messages ........................................39
3.8 Common Parameters ..............................................40
3.9 SUA-Specific parameters ........................................48
4 Procedures.........................................................59
4.1 SCCP _ SUA Interworking at the SG ..............................59
4.2 Primitives received from the local SUA-user ....................61
4.3 Layer Management Procedures ....................................62
4.4 SUA Management Procedures ......................................62
5 Examples of SUA Procedures.........................................69
5.1 SG Architecture ................................................69
5.2 IP-IP Architecture .............................................72
6 Security...........................................................73
6.1 Introduction ...................................................74
6.2 Threats ........................................................74
6.3 Protecting Confidentiality .....................................74
7 IANA Considerations................................................74
7.1 SCTP Payload Protocol ID .......................................74
7.2 Port Number ....................................................75
7.3 Protocol Extensions ............................................75
8 Timer Values.......................................................76
9 Acknowledgements...................................................76
10 Authors' Addresses................................................76
11 References........................................................78
Appendix A: Message mapping between SCCP and SUA.....................80
Copyright Statement..................................................81
Loughney, et al. [Page 2
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
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 SCCP-User Part messages (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-
oriented 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
Loughney, et al. [Page 3
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
database element handling all requests for a SCCP-user. The AS
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.
IP Server Process (IPSP) - A process instance of an IP-based
application. An IPSP is essentially the same as an ASP, except that
it uses SUA in a peer-to-peer fashion. Conceptually, an IPSP does
not use the services of a Signaling Gateway.
Signaling Gateway Process (SGP) - A process instance of a Signaling
Gateway. It serves as an active, standby or load-sharing process of
a Signaling Gateway.
Signaling Process - A process instance that uses SUA to communicate
with other signaling process. An ASP, a signaling gateway process
and an IPSP are all signaling processes.
Association - An association refers to an SCTP association. The
association provides the transport for the delivery of SCCP-User
protocol data units and SUA layer peer messages.
Routing Key - The Routing Key describes a set of SS7 parameters
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. Routing Keys should be
provisioned, for example, by a MIB.
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.
Address Mapping Function (AMF) - The AMF is an implementation
dependent function which is responsible for resolving the address
Loughney, et al. [Page 4
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
presented in the incoming SCCP/SUA message to correct SCTP
association for the desired endpoint. The AMF MAY use routing
context / rouging key information as selection criteria for the
appropriate SCTP association.
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-over may apply upon
the return to service of a previously unavailable Application Server
Process.
Network Appearance - The Network Appearance uniquely identifies an
SS7 entity (point code) into a SS7 network, as presented by the SG.
It is used 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 element in
multiple separate SS7 networks, in which case there is a separate
network appearance for each point code in the SS7 networks. It is
also necessary when an SG is configured as an STP hosting multiple
point codes, or when configured as multiple end nodes 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
Loughney, et al. [Page 5
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
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 *
* STP * * * * *
******** *************** ********
+------+ +------+
| SUAP | | SUAP |
+------+ +------+------+ +------+
| SCCP | | SCCP | SUA | | SUA |
+------+ +------+------+ +------+
| MTP3 | | MTP3 | | | |
+------| +------+ SCTP | | SCTP |
| MTP2 | | MTP2 | | | |
+------+ +------+------+ +------+
| L1 | | L1 | IP | | IP |
+------+ +------+------+ +------+
| | | |
+---------------+ +------------+
SUAP - SCCP/SUA User Protocol (TCAP, for example)
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 represented by an AS, and serviced by a set of ASPs
Loughney, et al. [Page 6
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
working in n+k redundancy mode. An ASP is selected and a CLDT
message is sent on the appropriate SCTP association/stream.
The selection criterion can be based on a round robin mechanism, or
any other method that guarantees a balanced load-sharing over the
active ASPs. However, when TCAP messages are transported, load-
sharing is only possible for the first message in a TCAP dialogue
(TC_Begin, TC_Query, TC_Unidirectional). All other TCAP messages in
the same dialogue must be sent to the same ASP that was selected for
the first message, unless the ASPs are able to share state and
maintain in sequence delivery. To this end, the SG must know the TID
allocation policy of the ASPs in a single AS :
- state sharing
- fixed range of TIDs per ASP in the AS
This information may be preconfigured in the SG, or may be
dynamically exchanged via the ASP_Active message.
An example for a INAP/TCAP message exchange between SEP and ASP is
given below.
Address information in CLDT message (e.g. TC_Query) from SG to ASP,
with association ID = SG-ASP, stream ID based on SLS and possibly
other parameters, e.g. OPC or network ID :
- Network appearance : based on SS7 network ID, so that the
message can be transported to the correct ASP.
- Source address : valid combination of SSN, PC and GT, as
needed for back-routing to the SEP,
- Destination address : at least SSN, to select the SCCP/SUA-
user at the ASP.
The Network Appearance is needed if the SG operates in more than one
SS7 network domain, since PC and SSN only have meaning within a
specific SS7 network domain.
Address information in CLDT message (e.g. TC_Response) from ASP to
SG, with association ID = ASP-SG, stream ID selected by
implementation dependent means with regards to in-sequence-delivery:
- Network appearance: as received in previous message,
- Source address: unique address provided so that when used as
SCCP called party address in the SEP, MUST yield the same AS
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.
Loughney, et al. [Page 7
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
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's.
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 AS or the other way. The routing of the Connect
Request message is done in the same way 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, ...)
This means that in the SG, two local references are allocated, one 3
byte value used for the SS7 section and one 4 byte value for the IP
section. Also a resource containing the connection data for both
sections is allocated, and either of the two local references can be
used to retrieve this data e.g. for an incoming DT1 or CODT, for
example.
******** SS7 *************** IP ********
* SEP *---------* *--------* *
* or * * SG * * ASP *
* STP * * * * *
******** *************** ********
+------+ +------+
| SUAP | | SUAP |
+------+ +------+------+ +------+
| SCCP | | SCCP | SUA | | SUA |
+------+ +------+------+ +------+
| MTP3 | | MTP3 | | | |
+------| +------+ SCTP | | SCTP |
Loughney, et al. [Page 8
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
| MTP2 | | MTP2 | | | |
+------+ +------+------+ +------+
| L1 | | L1 | IP | | IP |
+------+ +------+------+ +------+
| | | |
+---------------+ +------------+
SUAP - SCCP/SUA 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 is not 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 ********
* *--------* *
* IPSP * * IPSP *
* * * *
******** ********
+------+ +------+
| SUAP | | SUAP |
+------+ +------+
| SUA | | SUA |
+------+ +------+
| SCTP | | SCTP |
+------+ +------+
| IP | | IP |
+------+ +------+
| |
+----------------+
SUAP - SCCP/SUA 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 Peer-to-Peer Network Architecture
Loughney, et al. [Page 9
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
Figure 1 shows an example network architecture which can support
robust operation and failover. There need 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.
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 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).
Loughney, et al. [Page 10
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
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.
An ASP may be connected to multiple SGs (see figure 2). In such a
case, a particular SS7 destination may be reachable via more than
SG, therefore, more than one route. Given that proper SLS selection,
loadsharing, and SG selection based on point code availability must
be performed at the ASP, it will be necessary for the ASP to
maintain the status of each distant signalling point to which it
communicates on the basis of the SG through which it may route.
Signaling Gateway
SCTP Associations
+----------+ **************
| SG1 | * AS3 *
| ******** | * ******** *
| * SGP11+--------------------------------------------+ ASP1 * *
| ******** | / * ******** *
| ******** | | * ******** *
| * SGP12+--------------------------------------------+ ASP2 * *
| ******** | \ / | * ******** *
+----------+ \ | | * . *
\ | | * . *
+----------+ \ | | * . *
| SG2 | \ | | * . *
| ******** | \ | | * ******** *
| * SGP21+---------------------------------+-+ * * ASPN * *
| ******** | \ * ******** *
| ******** | \ **************
| * SGP22+---+--+ \
| ******** | | | \ **************
+----------+ | | \ * AS4 *
| | \ * ******** *
| +-------------------------------------+ ASP1 * *
| * ******** *
| * . *
| * . *
| * *
| * ******** *
+----------------------------------------+ ASPn * *
* ******** *
**************
Figure 2: Signaling Gateway Architecture
Loughney, et al. [Page 11
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
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 12
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
* 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
SUA uses the existing ASP management messages for ASP status
handling. The interworking with SCCP management consists on the
sending of DUNA, DAVA, DAUD or SCON messages on receipt of SSP, SSA,
SST or SSC to the appropriate ASPs. See also chapter 1.4.5. The
primitives below are considered to be sent between the SCCP and SUA
management functions in the SG to trigger events in the IP and SS7
domain.
Generic |Specific |
Name |Name |ANSI/ITU Reference
----------+-----------+---------------------------------------------
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.
* Provide the initiation of an audit of remote SS7 endpoints at
the SG.
Loughney, et al. [Page 13
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
1.4.6 Relay function
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, modeled in [ITU-T Q.714]. It may also be based on Hostname
information, IP address, or pointcode contained in the called party
address.
This allows for greater scalability, reliability and flexibility in
wide-scale deployments of SUA. The usage of a relay function is a
deployment decision.
1.5 Internal Functions Provided in the SUA Layer
In order to perform its addressing and relaying capabilities, the
SUA makes use of a Address Mapping Function (AMF). This function is
considered part of SUA, but the way it is realized is left
implementation / deployment dependent (local tables, DNS (ENUM),
LDAP, etc.)
The AMF is invoked when a message is received at the incoming
interface. The AMF is responsible for resolving the address
presented in the incoming SCCP/SUA message to SCTP associations to
destinations within the IP network. The AMF will select the
appropriate SCTP association based upon routing context / routing
key information available. The destination might be the end SUA node
or a SUA relay node. The Routing Keys 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, SCCP subsystem number, or Transaction ID. IP addresses and
host names can also be used as Routing Key information.
It is expected that the routing keys are provisioned via a MIB or
external process, such as a database.
1.5.1 Address Mapping at the SG
Normally, one or more ASPs are active in the AS (i.e., currently
processing traffic) but in certain failure and transition cases it
is possible that there may not be an active ASP available. The SG
will buffer the message destined for this AS for a time t(r) or
until an ASP becomes available. When no ASP becomes available before
Loughney, et al. [Page 14
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
expiry of t(r), the SG will flush the buffered messages and initiate
the appropriate return or refusal procedures.
If there is no match for an incoming 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 Mapping at the ASP
In order to direct messages to the SS7 network, the ASP must also
perform an address mapping in order to choose the proper SG for a
given message. This is accomplished by observing the Destination
Point Code and other elements of the outgoing message, SS7 network
status, SG availability, and network appearance configuration
tables.
A remote Signaling Gateway may be composed of one or more SGPs.
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.
1.5.3 Address Mapping Function at a Relay Node
The relay function is invoked when:
- routing is on Global Title
- routing is on Hostname
- routing is on SSN+PC or SSN+IP Address and the address
presented is not the one of the relay node
Translation/resolution of the above address information must yield
either of the following:
- Route on SSN: SCTP association ID towards the destination
node, SSN and optionally Network Appearance and/or IP
address.
- Route on GT: SCTP association ID towards next relay node,
(new) GT and optionally SSN and/or Network Appearance.
- Routing on Hostname: SCTP association ID towards next relay
node, (new) Hostname and optionally SSN and/or Network
Appearance.
- A local SUA-user (combined relay/end node)
To prevent looping, a 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 or less). Each time the relay function is
invoked within an intermediate (relay) node, the hop counter must be
Loughney, et al. [Page 15
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
decremented. When the value reaches zero, the return or refusal
procedures are invoked with reason "Hop counter violation".
1.5.4 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 is used to preserve the order of management
message delivery.
Stream selection based on protocol class :
- protocol class 0: SUA SHOULD select an unordered stream;
- protocol class 1: SUA MUST select an ordered stream, based on
a sequence parameter given by the upper layer over the
primitive interface;
- protocol classes 2 and 3: SUA will select an ordered stream,
based on its own source local reference.
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)
Loughney, et al. [Page 16
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
|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)
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Me sa s ge Data
|
Note that the 'data' portion of SUA messages SHALL contain SCCP-User
data, not the encapsulated SCCP message.
Loughney, et al. [Page 17
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
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
Message Classes
0 SUA Management (MGMT) Message
1 Reserved
2 Signaling Network Management (SNM) 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
Signaling Network Management (SNM) Messages
0 Reserved
1 Destination Unavailable (DUNA)
2 Destination Available (DAVA)
3 Destination State Audit (DAUD)
4 SS7 Network Congestion (SCON)
5 Reserved
6 Reserved
7 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
Application Server Process State Maintenance (ASPSM) Messages
0 Reserved
1 ASP Up (UP)
2 ASP Down (DOWN)
Loughney, et al. [Page 18
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
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)
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 and including all padding bytes.
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
Loughney, et al. [Page 19
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
(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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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. However, composite parameters will contain all
padding bytes, since all parameters contained within this
composite parameter will be considered multiples of 4 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,
Loughney, et al. [Page 20
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
- the data parameter will normally be the final one in the
message.
- the receiver SHOULD accept parameters in any order, except
where explicitly mandated.
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
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
Loughney, et al. [Page 21
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
Loughney, et al. [Page 22
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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: This parameter is not present in case of Expedited Data
(ED).
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 = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loughney, et al. [Page 23
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
| Tag = 0x0108 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x010A | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
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.
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 |
Loughney, et al. [Page 24
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Network Appearance Optional
Flags Mandatory
Source Reference Number Mandatory
Destination Address Mandatory
Source Address Optional
Credit Mandatory, protocol class 3 only
Data Optional
Implementation note: This message covers the following SCCP message:
Connection Request (CR).
3.3.4 Connection Acknowledge (COAK)
This message is used to acknowledge a connection request from 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 = 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 |
Loughney, et al. [Page 25
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Flags Mandatory
Destination Reference Number Mandatory
Source Reference Number Mandatory
Credit Mandatory, protocol class 3 only
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.
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 = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Reference Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCCP Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Destination Reference Number Mandatory
SCCP Cause Mandatory
Destination Address Optional *1
Data Optional
Loughney, et al. [Page 26
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
Note *1: Destination Address parameter will be present in case
that the received CORE message conveys the Source
Address parameter.
Implementation note: This message covers the following SCCP
message: Connection REFused (CREF).
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 ReLeaSeD (RLSD).
3.3.7 Release Complete (RELCO)
Loughney, et al. [Page 27
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
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
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)
to 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
Loughney, et al. [Page 28
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
Implementation note: This message covers the following SCCP message:
ReSet Request (RSR).
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).
3.3.11 Connection Oriented Inactivity Test (COIT)
Loughney, et al. [Page 29
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
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 Signaling Network Management Messages
3.4.1 Destination Unavailable (DUNA)
In the scope of SUA, this message is covered by the PC- or N-state
indication passed between SCCP and local SCCP-user. The DUNA message
is sent from the SG or relay node to all concerned ASPs (servicing
SCCP-users considered local to the SG or relay node, see chapter
Loughney, et al. [Page 30
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
1.3.1.1), when a destination or SCCP-user has become unreachable.
The SUA-User at the ASP is expected to stop traffic to the affected
destination or SCCP-user through the SG or relay node 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 = 0x0103 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Network Appearance Optional
Destination Address Mandatory *1
Info String Optional
Note 1: The destination address refers to the node that has
become unavailable. It SHOULD include only:
- point code + SSN (optional): case for interworking with a SS7
network, with already defined actions for the SG.
- IP address + SSN (optional): case for an all-IP environment.
3.4.2 Destination Available (DAVA)
In the scope of SUA, this message is covered by the PC- and N-state
indication passed between SCCP and local SCCP-user. The DAVA message
is sent from the SG or relay node to all concerned ASPs (servicing
SCCP-users considered local to the SG or relay node, see chapter
1.3.1.1) to indicate that a destination (PC or SCCP-user) is now
reachable. The ASP SUA-User protocol is expected to resume traffic
to the affected destination through the SG or relay node 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loughney, et al. [Page 31
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Network Appearance Optional
Destination Address Mandatory *1
Info String Optional
Note 1: The destination address refers to the node that has
become available. It SHOULD include only:
- point code + SSN (optional): case for interworking with a SS7
network, with already defined actions for the SG.
- IP address + SSN (optional): case for an all-IP environment.
3.4.3 Destination State Audit (DAUD)
The DAUD message can be sent from the ASP to the SG (or relay node)
to query the availability state of the 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 (or relay node).
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 = 0x0103 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
Loughney, et al. [Page 32
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Network Appearance Optional
Destination Address Mandatory *1
Info String Optional
Note 1: The destination address refers to the node that is being
audited. It SHOULD include only:
- point code + SSN (optional): case for interworking with a SS7
network, with already defined actions for the SG.
- IP address + SSN (optional): case for an all-IP environment.
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.
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 = 0x0103 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000E | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Network Appearance Optional
Congestion Level Mandatory
Destination Address Mandatory *1
Info String Optional
Note 1: The destination address refers to the node that is
experiencing congestion. It SHOULD include only:
Loughney, et al. [Page 33
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
- point code + SSN (optional): case for interworking with a SS7
network, with already defined actions for the SG.
- IP address + SSN (optional): case for an all-IP environment.
3.5 Application Server Process State 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
ASP Capabilities Optional
Info String Optional
Loughney, et al. [Page 34
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
3.5.3 ASP Down (DOWN)
The ASP Down (DOWN) 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
Note: The reason is only relevant for layer management and/or
logging.
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
Info String Optional
Note: ASP DOWN ACK will always be sent to acknowledge an ASP DOWN.
The Reason received in the ASP DOWN is only relevant for layer
management and/or logging.
Loughney, et al. [Page 35
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
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:
0 1 2 3
Loughney, et al. [Page 36
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
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
Routing Context Optional
Info String Optional
Loughney, et al. [Page 37
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
The value of the Traffic Mode Type and Routing Context parameters is
the same as for the ASP-Active message.
The value 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ INFO String /
Loughney, et al. [Page 38
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Routing Context Optional
INFO String Optional
The value of the optional Info String parameter is the same as for
the ASP-Active message.
3.7 SUA 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000D | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Type/ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
Loughney, et al. [Page 39
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ 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
Not used in SUA 0x0009
Reason 0x000A
Traffic Mode Type 0x000B
Error Code 0x000C
Status Type/ID 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
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Loughney, et al. [Page 40
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
| Tag = 0x0001 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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. It also
defines the network context for the PC and SSN values. 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
and/or interpretation of the parameters containing a PC or SSN
value.
3.8.2 Not used
Use of Parameter ID 0x0002 (Routing Key) in SUA messages is not
supported.
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.
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 41
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
| 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
14-, 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|
It is optional to send an Affected Point 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.
Loughney, et al. [Page 42
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
Including multiple Affected PCs may be useful when reception of a
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 are 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.
For use in SUA, the mask parameter MUST always be coded zero and
there MUST be only a single point code present.
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 a one-to-one
relationship between an index entry and a 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 June 15, 2001
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, or
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
Parameter ID 0x0009 (Cause/User) is not used in SUA.
3.8.10 Reason
The Reason parameter indicates the reason why the remote SUA
adaptation layer is unavailable.
Loughney, et al. [Page 44
Internet Draft SS7 SCCP-User Adaptation Layer June 15, 2001
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 = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- |
Documentation