| draft-hou-sigtran-tua-00Description: Request For CommentsYou can download source copies of the file as follows:
Listed below is the contents of file draft-hou-sigtran-tua-00.txt.
TERNET-DRAFT Jianxing Hou
Internet Engineering Task Force Ming Lin
Huawei Technologies
Issued: 1 April 2001
Expires: 1 October 2001
SS7 TCAP-User Adaptation Layer (TUA)
<draft-hou-sigtran-tua-00.txt>
Status of This Memo
This document is in full conformance with all provisions of Section
10 of RFC 2026.Internet-Drafts are working ocuments 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.
To learn the current status of any Internet-Draft, please check the
'1id-abstracts.txt' listing contained in the Internet- Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This document defines a protocol for the transport of any SS7
TCAP-User signaling (e.g.,INAP,MAP , 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 . Protocol elements are added to allow
seamless operation between peers in the SS7 and IP domains.
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
Abstract.............................................................1
1. Introduction......................................................2
1.1 Scope...........................................................3
1.2 Terminology.....................................................3
1.3 Signaling Transport Architecture................................5
1.4 Services Provided by the TUA Layer.............................10
1.5 Internal Functions Provided in the TUA Layer...................10
1.6 Definition of TUA Boundaries...................................12
2. Conventions......................................................14
3. Protocol Elements................................................14
3.1 Common Message Header..........................................15
3.2 TUA Message Header............................................18
3.3 Dialogue Handling(DH)Message..................................18
3.4 Component Handling(CH) Message.................................26
3.5 SS7 Signaling Network Management Messages......................31
3.6 Application Server Process Maintenance Messages................34
3.7 ASP Traffic Maintenance Messages...............................36
3.8 Management Messages............................................39
3.9 SGP Traffic Maintenance (SGPTM) Messages.......................40
3.10 Common Parameters.............................................40
3.11 TUA-Specific parameters.......................................50
4. Procedures.......................................................62
4.1 TCAP _ TUA Interworking at the SG..............................62
4.2 Primitives received from the local TUA-User....................63
4.3 Layer Management Procedures....................................63
4.4 TUA Management Procedures......................................64
5. Examples of TUA Procedures.......................................74
5.1 Establishment of Association and Traffic between SGPs and ASPs.74
5.2 IP-IP Architecture.............................................79
6. Security.........................................................81
6.1 Introduction...................................................81
6.2 Threats........................................................81
6.3 Protecting Confidentiality.....................................82
7. IANA Considerations..............................................82
7.1 SCTP Payload Protocol ID.......................................82
7.2 Protocol Extensions............................................82
8. Timer Values.....................................................83
9. Acknowledgements.................................................83
10. Authors' Addresses..............................................83
11. References......................................................84
Jianxing Hou, et al [Page 2]
Internet Drift SS7 TCAP-User Adaptation Layer April1,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 TCAP-user messages 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].
The delivery mechanism SHOULD meet the following criteria:
* Support for transfer of SS7 TCAP-User Part messages (e.g.,INAP,
MAP, etc.)
* Support for the seamless operation of TCAP-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.
1.2 Terminology
Signaling Gateway (SG) - Network element that terminates SCN signaling
and transports TCAP-User signaling over IP to an IP signaling endpoint.
Signalling Gateway Process (SGP) - A process instance of a Signalling
Gateway. It serves as an active, standby or load-sharing process of a
Signalling Gateway.
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 TCAP-user. The AS contains a set
of one or more unique Application Server Processes,of which one or more
is normally actively processing traffic.
Jianxing Hou, et al [Page 3]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
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 TCAP-User
protocol data units and TUA 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 TCAP DID 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 TUA, the Routing Key should be limited to TCAP SSN or a
combination of TCAP DID and SCCP SSN to identify an AS,in order to more
easily support TCAP 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 protocol's type
(ITU or ANSI ect)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
Jianxing Hou, et al [Page 4]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
SS7 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 TUA 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.
1.3.1 Protocol Architecture
In this architecture, the TCAP and TUA layers interface in the SG.
There needs to be interworking between the TCAP and TUA layers to
provide for the seamless transfer of the user messages as well as
the management messages.
******** SS7 *************** IP ********
* SEP *---------* *--------* *
* or * * SG * * ASP *
* STP * * * * *
******** *************** ********
+------+ +------+
| TC_U | | TC_U |
Jianxing Hou, et al [Page 5]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
+------+ +------+------+ +------+
| TCAP | | TCAP | TUA | | TUA |
+------+ +------+------+ +------+
| SCCP | | SCCP | | | |
+------+ +------+ | | |
| MTP3 | | MTP3 | SCTP | | |
+------| +------+ | | SCTP |
| MTP2 | | MTP2 | | | |
+------+ +------+------+ +------+
| L1 | | L1 | IP | | IP |
+------+ +------+------+ +------+
| | | |
+---------------+ +------------+
TC_U - TCAP USER (e.g. - MAP/INAP)
STP - SS7 Signaling Transfer Point
In this case, the TCAP messages are routed on SSN or SSN+DID. The
TCAP-User identified by SSN or SSN+DID is regarded as local to the
SG. This means from SS7 point of view, the TCAP-user is located at
the SG.
By means of configuration, the SG knows the local TCAP-user is
actually representing an AS, serviced by a set of ASPs working in
n+k redundancy mode. An ASP is selected and a TCAP message is sent
on the appropriate SCTP association/stream.
Actually, the primitive interface between TCAP and TCAP-user is
transported here over TUA. An example for a INAP/MAP message
exchange between SEP and ASP is given below.
Address information in message from SG to ASP :
- Network appearance : based on SS7 network ID and Protocol Type,
- Source address : valid combination of SSN, PC and GT, as
needed for back-routing,
- Destination address : at least SSN , to select the
TCAP-user at the ASP.
The Network Appearance is needed if the SG operates in more than one
SS7 network or protocol type(ITU or ANSI,etc), since PC and SSN only
have meaning within a specific SS7 network. If SG receives a message
from SS7 network,it will determine which AS the message is sent to
(based on SSN or SSN+DID within the message),then it will select an
active ASP based on implementation,and select a Stream ID for the
message,and then the message can be sent to proper ASP.
Address information in message from ASP to SG :
Jianxing Hou, et al [Page 6]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
- 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
and response message.
When ASP receives a message from TCAP-User,it will select a SGP
through TCAP DID based on implementation,then select a Stream ID to
the message,and then the message can be sended to SG.
1.3.2 All IP Architecture
This architecture can be used to carry a protocol which uses the
transport services of TCAP, 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 |
+------+ +------+
| TUA | | TUA |
+------+ +------+
| SCTP | | SCTP |
+------+ +------+
| IP | | IP |
+------+ +------+
| |
+----------------+
AP - Application Protocol (e.g. - MAP/INAP)
The SCTP protocol takes care about the case where a collision occurs
during initiation.
1.3.3 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.
Jianxing Hou, et al [Page 7]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
***********
* 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.4 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.
Jianxing Hou, et al [Page 8]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
The SG will transport TCAP-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 TUA 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
************
* SG * AS1
* ******** * **************
* * *_*________________________________________* ******** *
* * * * _________* * ASP1 * *
* * SGP1 * * SCTP Associations | * ******** *
* * *_*______________________ | * *
* ******** * | | * ******** *
* * | | * * ASP2 * *
* * | | * ******** *
* * | | * . *
* * | | * . *
* * | | * . *
* ******** * | | * ************
* * *_*______________________|_______|
* * * * |
* * SGP2 * * SCTP Associations |
* * *_*___________ |
* * * * | | AS2
* ******** * | | **************
* * | |_________________* ******** *
* * |____________________________* * ASP1 * *
* * * ******** *
* * * *
************ * ******** *
* * ASP2 * *
* ******** *
* . *
* . *
* . *
**************
Figure 2: Signaling Gateway Architecture
Jianxing Hou, et al [Page 9]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
1.3.5 ASP Fail-over Model and Terminology
The TUA 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 TCAP-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 TUA Layer
1.4.1 Support for the transport of TCAP-User Messages
The TUA needs to support the transfer of TCAP-user messages.The TUA
layer at the SG needs to seamlessly transport the user messages.
1.4.2 Native Management Functions
The TUA layer may provide management of the underlying SCTP layer to
ensure that transport is available according to the degree specified by
the TCAP-user application.
The TUA layer provides the capability to indicate errors associated
with the TUA-protocol messages and to provide notification to local
management and the remote peer as is necessary.
1.4.3 Support for passing the SCCP management message
The TUA layer should provide passing transparently availability and
non-availability of SCCP (local or remote) between the SCN network and
the IP network. (see ITU-T Q.771 chap 2.2.3) It should:
-Provide an indication to the TCAP-user at an ASP that a remote SS7
endpoint/peer is unreachable.
-Provide an indication to the TCAP-user at an ASP that a remote SS7
endpoint/peer is reachable.
-Provide congestion indication to TCAP-user at an ASP.
1.5 Internal Functions Provided in the TUA 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
Jianxing Hou, et al [Page 10]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
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 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 TUA
ASP management messages.
Possible SS7 address/routing information that comprise a Routing Key
entry includes, for example,SCCP subsystem number, or TCAP transaction
ID. Some possibilities include:
SSN
SSN+TCAP DID
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.TUA 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 choose
the proper SGP for a given message. This is accomplished by observing
SGP availability and is implementation dependent.
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 TUA 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.
Jianxing Hou, et al [Page 11]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
1.5.3 SCTP Stream Mapping
The TUA supports SCTP streams. The SG/AS needs to maintain a list of
SCTP and TUA-users for mapping purposes.TCAP-users requiring sequenced
message transfer need to be sent over a stream supporting sequenced
delivery.
TUA MUST use stream 0 for TUA management messages. It is recommended
that sequenced delivery be in order to preserve the order of management
message delivery.
1.5.4 TCAP DID Mapping
Because Both TCAP and TCAP-User can assign DID independently,it is
possible that TCAP and TCAP-User assign same value to different
message at the same time, but it brings some problems. To solve this
problem, TUA need support TCAP DID mapping. The TUA needs to maintain
a list of incoming message's DID and outgoing message's DID for
mapping purposes.The solution in more details will be lodged via
discussion.
1.6 Definition of TUA Boundaries
1.6.1 Definition of the upper boundary
The following primitives are supported between the TUA and an
TCAP-user (a reference to ITU and ANSI sections where these primitives
and corresponding parameters are described, is also given).
1.6.1.1 Primitives for ITU
Name | Type | Reference (ITU) | TUA Message
----------------------------------------------------------------------
TC-UNI | Request | ITU-Q.711 chap3.1.2.2.1 |Unidirectional
|Indication | |
----------------------------------------------------------------------
TC-BEGIN | Request |ITU-Q.711 chap3.1.2.2.2.1 | Query
|Indication | |
----------------------------------------------------------------------
TC-CONTINUE | Request | ITU-Q.711 chap3.1.2.2.2.2| Conversation
| Indication | ITU-Q.711 chap3.1.2.2.2.3|
----------------------------------------------------------------------
TC-END | Request | ITU-Q.711 chap3.1.2.2.2.4| End
|Indication | |
----------------------------------------------------------------------
TC-U-ABORT | Request | ITU-Q.711chap3.1.2.2.2.4 | U-Abort
|Indication | |
----------------------------------------------------------------------
TC-P-ABORT |Indication | ITU-Q.711 chap3.1.4.2 | P_Abort
Jianxing Hou, et al [Page 12]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
---------------------------------------------------------------------
TC-NOTICE | Indication | ITU-Q.711 chap3.1.2.2.3 | Notice
----------------------------------------------------------------------
TC_INVOKE | Request | ITU-Q.711 chap3.1.3.2 | Invoke
| Incation | |
----------------------------------------------------------------------
TC_RESULT_L | Request | ITU-Q.711 chap3.1.3.3 | Result
---------------| | |
TC_RESULT_NL | Indication | |
----------------------------------------------------------------------
TC_U-ERROR | Request | ITU-Q.711 chap3.1.3.4 | U_Error
|Indication | |
----------------------------------------------------------------------
TC_U_REJECT | Request | ITU-Q.711 chap3.1.3.5 |
|Indication | |
----------------------------| |
TC_L_REJECT | Request | | Reject
|Indication | |
----------------------------| ITU-Q.711 chap3.1.4.1 |
TC_R_REJECT | Request | |
| Indication | |
----------------------------------------------------------------------
TC-U-CANCEL | Request | |
---------------| | ITU-Q.711 chap3.1.3.6 | Cancel
TC-L-CANCEL |Indication | |
----------------------------------------------------------------------
TC_TIMER_RESET | Request | ITU-Q.711 chap3.1.3.6 | Timer_Reset
----------------------------------------------------------------------
1.6.1.2 Messages for ANSI
TCAP Message | TUA Message
--------------------------------------------------------------------
Undirectional | Unidirectional
-------------------------------------------------------------------
Query with Permission |
--------------------------------| Query
Query without Permission |
--------------------------------------------------------------------
Conversation with Permission |
--------------------------------| Conversation
Conversation without Permission |
--------------------------------------------------------------------
Respone | End
--------------------------------------------------------------------
U_Abort | U_Abort
--------------------------------------------------------------------
Jianxing Hou, et al [Page 13]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
P_Abort | P_Abort
--------------------------------------------------------------------
Invoke Last |
--------------------------------| Invoke
Invoke Not Last |
--------------------------------------------------------------------
Return Result(Last) |
--------------------------------| Result
Return Result( Not Last) |
--------------------------------------------------------------------
Return Error | U_Error
--------------------------------------------------------------------
Reject | Reject
--------------------------------------------------------------------
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].
In this document, the following conventions are used to describe how
a parameter is used in the message :
M parameter is mandatory in this message.
O parameter is optional in this message.
(A) parameter is applicable only in the ANSI TCAP message .
(I) parameter is applicable only in the ITU TCAP message.
(Ind) parameter is applicable only when this message's type is
Indication.
(Req) parameter is applicable only when this message's type is
Request.
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.
Jianxing Hou, et al [Page 14]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
3.1 Common Message Header
The protocol messages for the TCAP-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 TUA messages SHALL contain TCAP-User
data, not the encapsulated TCAP message.
Optional parameters can only occur at most once in an TUA message.
3.1.1 TUA Protocol Version
The version field (ver) contains the version of the TUA adaptation
layer. The supported versions are:
01 TUA version 1.0
3.1.2 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 Dialogue Handling(DH) Message
6 Component Handling(CH) Message
7 SGP Traffic Maintenance (SGPTM) Messages
8 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
3.1.3 Message Types
TUA Management Messages
0 Error (ERR)
1 Notify (NTFY)
2 - 127 Reserved by the IETF
Jianxing Hou, et al [Page 15]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
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 SS7 Network Congestion (SCON)
4 Destination User Part Unavailable (DUPU)
5 - 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 ASP Up Ack (UP ACK)
4 ASP Down Ack (Down ACK)
5 - 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
Dialogue Handling(DH) Message
0 Unidirectional(UNI)
1 Query
2 Conversation (CON)
3 End
4 U_Abort
5 P_Abort
6 Notice
7 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
Component Handling(CH)Message
0 Invoke
1 Result
2 U_Error
3 Reject
Jianxing Hou, et al [Page 16]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
4 Cancel
5 Timer_Reset
6 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
SGP Traffic Maintenance (SGPTM) Messages
0 Reserved
1 SGP Active(SGP Act)
2-277 Reserved by the IETF
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
TUA 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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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
Jianxing Hou, et al [Page 17]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
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 TUA Message Header
In addition to the common message header, there will be a specific
message header for TUA Diagolue Handling messages and Component
Handling messages. The TUA message header will immediately follow the
Common header in these messages.
This message header contains the Dialogue ID(DID) and SSN.The format of
the DID parameter and SSN parameter are integer.
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 = 0x0502 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSN value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0501 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dialogue ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3 Dialogue Handling(DH)Message
The following section describes the TUA dialogue handling 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.
Jianxing Hou, et al [Page 18]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
3.3.1 Unidirectional(UNI)
A UNI request message is for transmission of one,or several components
invoking class 4 operations or reporting protocol errors in these
invocations, grouped in a message to the remote TCAP-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 = 0x0102 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Originatiting Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Components present |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0101 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Quality of Service |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0104 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Application context name /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ User information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0301 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Security Context /
\ \
Jianxing Hou, et al [Page 19]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0302 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Confidentiality /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Destination address M
Originating address M
Components present M(Ind)
Network Appearance O
Quality of Service O
Application context name O
User information O
Security Context O(A)
Confidentiality O(A)
3.3.2 Query
The Query request message may be issued prior to passing any component
to the Component sublayer.At the receiving side, the destination
TCAP-user is informed that a new dialogue starts by means of a Query
indication 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 = 0x0102 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Originatiting Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Components present |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0506 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Query Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
Jianxing Hou, et al [Page 20]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0101 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Quality of Service |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0104 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Application context name /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ User information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0301 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Security Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0302 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Confidentiality /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Destination address M
Originating address M
Query Type M(A)
Components present M(Ind)
Network Appearance O
Quality of Service O
Application context name O
User information O
Security Context O(A)
Confidentiality O(A)
3.3.3 Conversation
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 = 0x0503 | Length |
Jianxing Hou, et al [Page 21]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Conversation Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Components present |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0101 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Quality of Service |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0102 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Application context name /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Originatiting Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ User information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0301 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Security Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0302 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Confidentiality /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Conversation Type M(A)
Components present M(Ind)
Network Appearance O
Quality of Service O
Jianxing Hou, et al [Page 22]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
Application context name O
Originating address O
User information O
Security Context O(A)
Confidentiality O(A)
3.3.4 End
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 = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Components present |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0107 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Termination |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0101 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Quality of Service |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0104 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Application context name /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ User information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0301 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Security Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0302 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Confidentiality /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jianxing Hou, et al [Page 23]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
Parameters
Components present M(Ind)
Termination M(Req)
Network Appearance O
Quality of Service O
Application context name O
User information O
Security Context O(A)
Confidentiality O(A)
3.3.5 U_Abort
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Quality of Service |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0104 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Application context name /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0105 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ User information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0401 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Abort reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0301 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Security Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0302 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Confidentiality /
Jianxing Hou, et al [Page 24]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0303 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ User Abort Information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Network Appearance O
Quality of Service O
Application context name O
User information O
Abort Reason O(I)
Security Context O(A)
Confidentiality O(A)
User Abort Information O(A)
3.3.6 P_Abort
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 = 0x0108 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P-Abort |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0101 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Quality of Service |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
P-Abort M
Network Appearance O
Quality of Service O
3.3.7 Notice
Jianxing Hou, et al [Page 25]
Internet Drift SS7 TCAP-User Adaptation Layer April1,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 = 0x0109 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0103 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Originatiting Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0102 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Destination Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Report cause M
Network Appearance O
Destination address O
Originating address O
3.4 Component Handling(CH) Message
The following section describes the TUA Component handling
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.4.1 Invoke
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 = 0x0201 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Invoke ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0204 | Length |
Jianxing Hou, et al [Page 26]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Operation /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0504 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Invoke Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0203 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last component |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0202 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0402 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Class |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0205 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0208 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Invoke ID M
Operation M
Invoke Type M(A)
Last component M(Ind)
Timeout M(Req)
Class M(I)(Req)
Network Appearance O
Parameters O
Correlation ID O
3.4.2 Result
Jianxing Hou, et al [Page 27]
Internet Drift SS7 TCAP-User Adaptation Layer April1,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 = 0x0201 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Invoke ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0203 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last component |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0204 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Operation /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0205 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0208 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Invoke ID M
Last component M(Ind)
Network Appearance O
Operation O
Parameters O
Correlation ID O(A)
3.4.3 U_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 = 0x0201 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Invoke ID |
Jianxing Hou, et al [Page 28]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0206 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Error /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0203 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last component |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0205 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0208 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Invoke ID M
Error M
Last component M(Ind)
Network Appearance O
Parameters O
Correlation ID O(A)
3.4.4 Reject
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 = 0x0207 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Problem code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0203 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last component |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0505 | Length |
Jianxing Hou, et al [Page 29]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reject Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0201 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Invoke ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0208 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0205 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Problem code M
Last component M(Ind)
Reject Type M(I)
Network Appearance O
Invoke ID O
Correlation ID O(A)
Parameters O(A)
3.4.5 Cancel
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 = 0x0201 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Invoke ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Jianxing Hou, et al [Page 30]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
Invoke ID M
Network Appearance O
3.4.6 Timer_reset
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 = 0x0201 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Invoke ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Invoke ID M
Network Appearance O
3.5 SS7 Signaling Network Management Messages
3.5.1 Destination Unavailable (DUNA)
In the scope of TUA, this message is covered by the PC state
indication passed between TCAP and local TCAP-user. The DUNA message is
sent from the SG to all concerned ASPs (servicing TCAP-usersconsidered
local to the SG), when an SS7 destination has become unreachable. The
TUA-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 = 0x0005 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Affected Point Code /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
Jianxing Hou, et al [Page 31]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Affected Point Code M
Network Appearance O
Info String O
3.5.2 Destination Available (DAVA)
In the scope of TUA, this message is covered by the PC state
indication passed between TCAP and local TCAP-user. The DAVA message is
sent from the SG to all concerned ASPs (servicing TCAP-users considered
local to the SG) to indicate that an SS7 destination is now reachable.
The ASP TUA-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 = 0x0005 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Affected Point Code /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Affected Point Code M
Network Appearance O
Info String O
3.5.3 SS7 Network Congestion (SCON)
Jianxing Hou, et al [Page 32]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
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 = 0x0010 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x000E | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ Affected PC \
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ info string /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Congestion Level M
Affected PC M
Network Appearance O
Info String O
3.5.4 Destination User Part Unavailable (DUPU)
The DUPU message is used in local broadcast procedures (TUA for TCAP
- TCAP user interface).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 = 0x0009 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause/User |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0005 | Length |
Jianxing Hou, et al [Page 33]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Affected Point Code /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ info string /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Cause/User M
Affected Point Code M*
Network Appearance O
Info String O
Note *: In the DUPU message, the Affected Point Code Parameter
MUST contain, at most, a single Affected Point Code.
3.6 Application Server Process Maintenance Messages
3.6.1 ASP Up (UP)
The ASP UP (UP) message is used to indicate to a remote TUA 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 O
Info String O
Jianxing Hou, et al [Page 34]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
3.6.2 ASP Up Ack (UP ACK)
The ASP UP Ack message is used to acknowledge an ASP-Up message
received from a remote TUA 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 O
Info String O
3.6.3 ASP Down (DN)
The ASP Down (DN) message is used to indicate to a remote TUA 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 M
Info String O
3.6.4 ASP Down Ack (DOWN ACK)
Jianxing Hou, et al [Page 35]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
The ASP DOWN Ack message is used to acknowledge an ASP-Down message
received from a remote TUA 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 M
Info String O
3.7 ASP Traffic Maintenance Messages
3.7.1 ASP Active (ACTIVE)
The ASPAC message is sent by an ASP to indicate to a remote TUA 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
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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jianxing Hou, et al [Page 36]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
Parameters
Traffic Mode Type M
Routing Context O
Info String O
3.7.2 ASP Active Ack (ACTIVE ACK)
The ASPAC Ack message is used to acknowledge an ASP-Active message
received from a remote TUA 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 = 0x000F | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SGP Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Traffic Mode Type M
Routing Context O
Info String O
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.3 ASP Inactive (INACTIVE)
Jianxing Hou, et al [Page 37]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
The INACTIVE message is sent by an ASP to indicate to a remote TUA
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 O
INFO String O
3.7.4 ASP Inactive Ack (INACTIVE ACK)
The INACTIVE Ack message is used to acknowledge an ASP-Inactive
message received from a remote TUA 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 /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameters
Jianxing Hou, et al [Page 38]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
Routing Context O
INFO String O
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.8 Management Messages
These messages are used for managing TUA .
3.8.1 Error (ERR)
The ERR message is sent between two TUA 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 M
Diagnostic Info O
3.8.2 Notify (NTFY)
The Notify message used to provide an autonomous indication of TUA
events to an TUA 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 |
Jianxing Hou, et al [Page 39]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Routing Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The NTFY message contains the following parameters:
Parameters
Status Type/ID M
Routing Context O
Info String O
3.9 SGP Traffic Maintenance (SGPTM) Messages
3.9.1 SGP Active
This messages is used to notify ASP that SGP's status is 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 = 0x000F | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SGP Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The message contains the following parameters:
Parameters
SGP Status M
3.10 Common Parameters
These TLV parameters are common across the different adaptation
layers.
Parameter Name Parameter ID
============== ============
Network Appearance 0x0001
Not used in TUA 0x0002
Not used in TUA 0x0003
Jianxing Hou, et al [Page 40]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
Info String 0x0004
Affected Point Code 0x0005
Routing Context 0x0006
Diagnostic Info 0x0007
Not used in TUA 0x0008
Cause/User 0x0009
Reason 0x000A
Traffic Mode Type 0x000B
Error Code 0x000C
Status Type 0x000D
Congestion Level 0x000E
SGP Status 0x000F
3.10.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.10.2 Not used
Parameter ID 0x02 is not used in TUA.
Jianxing Hou, et al [Page 41]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
3.10.3 Not used
Parameter ID 0x03 is not used in TUA.
3.10.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ info string /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.10.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
Jianxing Hou, et al [Page 42]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 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.10.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
Jianxing Hou, et al [Page 43]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
3.10.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.10.8 Not Used
Parameter ID 0x08 is not used in TUA.
3.10.9 Cause/User
0 1 2 3
Jianxing Hou, et al [Page 44]
Internet Drift SS7 TCAP-User Adaptation Layer April1,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 = 0x0009 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause | User |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unavailability Cause field: 16-bits (unsigned integer)
The Unavailability Cause parameter provides the reason for the
unavailability of the TUA-User. The valid values for the
Unavailability Cause parameter are shown in the following table.
0 Unknown
1 Unequipped Remote User
2 Inaccessible Remote User
User Identity field: 16-bits (unsigned integer)
The User Identity describes the specific TUA-User that is
unavailable. Some of the valid values for the User Identity are
shown below.
0 - 2 Reserved by M3UA
3 SCCP/SUA
4 - 10 Reserved by M3UA
11 TCAP/TUA
3.10.10 Reason
The Reason parameter indicates the reason that the remote TUA
adaptation layer is unavailable.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reason: 32-bit (unsigned integer)
The valid values for Reason are shown in the following table.
0 Unspecified
Jianxing Hou, et al [Page 45]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
1 User Unavailable
2 Management Blocking
3 ASP Fault
3.10.11 Traffic Mode Type
The Traffic Mode Type parameter identifies the traffic mode of
operation of the ASP within an AS.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Type are shown in the following table.
1 Over-ride
2 Load-share
3 Over-ride (Standby)
4 Loadshare (Standby)
Within a Routing Context, Over-ride and Loadshare Types cannot be
mixed. The Over-ride value indicates that the ASP is operating in
Over-ride mode, and the ASP wishes to take over all traffic for an
Application Server (i.e., primary/back-up operation), over-riding
any currently active ASP in the AS. In Load-share mode, the ASP
wishes to share in the traffic distribution with any other currently
active ASPs. The Standby versions of the Over-ride and Loadshare
Types indicate that the ASP is declaring itself ready to accept
traffic but leaves it up to the sender as to when the traffic is
started. Over-ride (Standby) indicates that the traffic sender
continues to use the currently active ASP until it can no longer
send/receive traffic (i.e., the currently active ASP transitions to
Down or Inactive). At this point the sender may immediately move
the ASP to Active and commence traffic. Loadshare (Standby) is
similar - the sender continues to loadshare to the current ASPs
until there it is determined that there is insufficient resources in
the Loadshare group. When there is insufficient ASPs, the sender
may immediately move the ASP to Active.
3.10.12 Error Code
0 1 2 3
Jianxing Hou, et al [Page 46]
Internet Drift SS7 TCAP-User Adaptation Layer April1,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 =0x000C | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Error Code parameter indicates the reason for the Error Message.
The Error parameter value can be one of the following values:
Invalid Version 0x01
Invalid Network Appearance 0x02
Unexpected Message Class 0x03
Invalid Message Type 0x04
Unsupported Traffic Handling Mode 0x05
Unexpected Message 0x06
Protocol Error 0x07
Invalid Routing Context 0x08
Invalid Stream Identifier 0x09
Parameter Field Error 0x0B
Unexpected Parameter 0x0C
Duplicated Parameter 0x0D
The "Invalid Version" error would be sent if a message was received
with an invalid or unsupported version.The Error message would contain
the supported version in the Common header.The Error message could
optionally provide the supported version in the Diagnostic Information
area.
The "Invalid Network Appearance" error would be sent by a SG if an
ASP sends a message with an invalid (unconfigured) Network Appearance
value.
The "Unsupported Traffic Handling Mode" error would be sent by a SG
if an ASP sends an ASP Active with an unsupported Traffic Handling
Mode.An example would be a case in which the SG did not support
load-sharing.
The "Unexpected Message" error would be sent by an ASP if it received
a message while it was in the Inactive state.
The "Protocol Error" error would be sent for any protocol anomaly
(i.e. a bogus message).
The "Invalid Routing Context" error would be sent by a SG if the
routing context cannot be supported, e.g. not unique.
Jianxing Hou, et al [Page 47]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
The "Invalid Stream Identifier" error would be sent if a message
was received on an unexpected SCTP stream (i.e. a stream that did not
have an Interface Identifier associated with it).
The "Unexpected Message Class" error would be sent if a message with
an unexpected or unsupported Message Class is received.
The "Parameter Field Error" would be sent if a message with a
parameter having a wrong length field.
The "Unexpected Parameter" error would be sent if a message contains
an invalid parameter.
The "Duplicated Parameter" error would be sent if a message contains
a parameter more than once.
The Cause parameter can be one of the following values:
Invalid Version 0x1
Invalid Network Appearance 0x2
Invalid Adaptation Layer Identifier 0x3
Invalid Message Type 0x4
Invalid Traffic Handling Mode 0x5
Unexpected Message Type 0x6
Protocol Error 0x7
Invalid Routing Context 0x8
Unsupported Message Type 0x9
3.10.13 Status Type
The Status Type parameter identifies the type of the status that is
being notified.
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 | Status ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Status Type (16 bit unsigned integer) are:
1 Application Server state change (AS_State_Change)
2 Other
The Status ID parameter contains more detailed information for the
Jianxing Hou, et al [Page 48]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
notification, based on the value of the Status Type.
If the Status Type is AS_STATE_CHANGE, then the Status ID (16 bit
unsigned integer) values are:
1 reserved
2 Application Server Inactive (AS-Inactive)
3 Application Server Active (AS-Active)
4 Application Server Pending (AS-Pending)
These notifications are sent from an SG to an ASP upon a change in
status of a particular Application Server. The value reflects the new
state of the Application Server.
If the Status Type is Other, then the following Status Information
values are defined:
1 Insufficient ASP resources active in AS
2 Alternate ASP Active
These notifications are not based on the SG reporting the state
change of an ASP or AS. In the Insufficient ASP Resources case,the SG
is indicating to an "Inactive" ASP(s) in the AS that another ASP is
required in order to handle the load of the AS (Load-sharing mode).
For the Alternate ASP Active case, an ASP is informed when an alternate
ASP transitions to the ASP-Active state in Over-ride mode.
3.10.14 Congestion Level
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 = 0x000E | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Congestion Level field: 8-bits (unsigned integer)
The Congestion Level will have two different meanings, depending
upon the message it is received with.
For the SCON message, the Congestion Level field, contains one of
the following values,which are associated with a destination point
code:
0 No Congestion or Undefined
Jianxing Hou, et al [Page 49]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
1 Congestion Level 1
2 Congestion Level 2
3 Congestion Level 3
The congestion levels are as defined in the national congestion
method in the appropriate MTP recommendation [ITU-MTP], [ANSI-MTP].
For MTP congestion methods that do not employ congestion levels
(e.g., the ITU international method, the parameter is always
"Undefined"). When an SCON is received at the SG, a TFC message is
generated into the SS7 network.
3.10.15 SGP Status
This Parameter indict
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 = 0x000F | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spare | SGP Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SGP Status
values
0 Inactive
1 Stangby
2 Active
3-255 Reserved by IETF
3.11 TUA-Specific parameters
These TLV parameters are specific to the TUA protocol.
Parameter Name Parameter ID
============== ============
(For dialogue handling)
Quality of Service 0x0101
Destination Address 0x0102
Originating Address 0x0103
Application context name 0x0104
User information 0x0105
Components present 0x0106
Termination 0x0107
P_Abort 0x0108
Report cause 0x0109
(For component handling )
Invoke ID 0x0201
Jianxing Hou, et al [Page 50]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
Timeout 0x0202
Last component 0x0203
Operation 0x0204
Parameters 0x0205
Error 0x0206
Problem code 0x0207
Correlation ID 0x0208
(Only in ANSI)
Security Context 0x0301
Confidentiulity 0x0302
User Abort information 0x0303
(Only in ITU )
Abort reason 0x0401
Class 0x0402
(For Common)
Conversation Type 0x0503
Invoke Type 0x0504
Reject Type 0x0505
Query Type 0x0506
3.11.1 Quality of Service
The "Quality of Service" parameters for the connectionless SCCP
network service at present consists of the following:
"Return Option" - Specifies whether the SCCP "return message
on error" is requested.
"Sequence Control" - The presence of this parameter indicates the
SCCP Class 1 is requested and when used in a
request primitive, explicitly provides the
information needed to deliver a series of
messages in sequence.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Spare | Seq Control | Return Option |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Return Option
Bits 1 indicate if or not "return message on error"
Jianxing Hou, et al [Page 51]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
Values Description
0 It is not necessary to return message on error
1 It is necessary to return message on error
Bits 2-8 are spare and should be coded zero.
-Sequence Control
The first octet indicate whether the information needed to
deliver in sequence.
Values Description
0 It is not necessary to deliver message in sequence
1 It is necessary todeliver message in sequence
2-255 reserved
The second octet indicate sequence number of the message.
3.11.2 Destination Address
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 = 0x0102 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format for Destination Address is as SCCP address's format.
In ITU,see ITU Q713 chap3.4,In ANSI,see ANSI T1.112.3 chap 3.4.
3.11.3 Originating Address
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 = 0x0103 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of this parameter is identical to the Source Address
parameter.
Jianxing Hou, et al [Page 52]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
3.11.4 Application context name
The application context is the identifier of the application context
proposed by the dialogue initiator or by the dialogue responder. An
application context is an explicitly identified set of application-
service-elements, related options and any other necessary information
for the interworking of application-entities on a dialogue. see Q.771
chap 3.1.2.1.
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 = 0x0104 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Application context name /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.11.5 User information
User information which can be exchanged between TCAP users
independently from the remote operation service.see Q.771
chap 3.1.2.1.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ User information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.11.6 Components present
Components present indicates whether or not components are present.
If components are present, then only syntactically valid and opportune
components are delivered to the destination TC-user by TCAP in the same
order they were delivered to TCAP by the source TC-user.see Q.771
chap3.1.2.1
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 = 0x0106 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spare | present |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jianxing Hou, et al [Page 53]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
present
values
0 components are present
1 components are not present
2-255 Spare
3.11.7 Termination
Termination indicates which scenario is chosen by the TC-user for
the end of the dialogue(prearranged or basic).see Q.771 chap 3.1.2.1.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spare | Termination |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Termination
values
0 prearranged
1 basic
2-255 Spare
3.11.8 P_Abort
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 = 0x0108 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spare | P_Abort |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
P_Abort
(In ITU)
values
0 UNRECOGNIZ_MSG
1 UNRECOGNIZ_TID
2 BADLY_FORMAT
3 INCORRECT_TSCT
4 RESOURCE_LIMIT
5 L_RESOURCE_LIMIT
6 INVALID_DLG_REQ
7 PENDING_EXPIRED
8 BEGIN_EXPIRED
Jianxing Hou, et al [Page 54]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
9 INACTIVE_EXPIRED
10 DST_ADDR_UNKNOW
11 NETWORK_ERROR
12 UNRECOGNIZ_DID
13 ABNORMAL_DLGP
14 NO_COMMON_DLGP
15-255 spare
(In ANSI)
values
0 spare
1 UNRECOGNIZED_PACKAGE_TYPE
2 INCORRECT_TRANSACTION_PORTION
3 BAD_STRUCTURED_TRANSACTION_PORTIONÕõ
4 UNASSIGNED_RESPONDING_TID
5 PERMISSION_TO_RELEASE_PROBLEM
6 RESOURCE_UNAVAILABLE
7 UNRECOGNIZED_DIALOGUE_PORTION_ID
8 BAD_STRUCTURED_DIALOGUE_PORTION
9 MISSING_DIALOGUE_PORTION
10 INCONSISTENT_DIALOGUE_PORTION
11 P_ABORT_CAUSES_BUTT
12-255 spare
3.11.9 Report cause
It contains information indicating the reason for the exception
report, that the message was returned by the SCCP with the reason as
specified in Recommendation Q.711. This parameter is required for the
TC-NOTICE indication primitive.It is used only in ITU,if necessary,
it maybe used in ANSI.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spare | Report cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Report cause
values
0 no translation for an address of such nature;
1 no translation for this specific address;
2 subsystem congestion;
3 subsystem failure;
4 unequipped user;
Jianxing Hou, et al [Page 55]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
5 MTP failure;
6 network congestion;
7 SCCP unqualified;
8 error in message transport;
9 error in local processing;
10 destination cannot perform reassembly;
11 SCCP failure;
12 hop counter violation;
13 segmentation not supported;
14 segmentation failed.
15-255 spare
3.11.10 Invoke ID
It identifies an operation invocation and its result.
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 = 0x0201 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spare | ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.11.11 Timeout
It indicates the maximum lifetime of an operation invocation.The unit
of lifetime is second.
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 = 0x0202 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.11.12 Last component
This parameter is used in primitives of the "indication" type only,
to designate the last component of a message. Note that indication of
the last part of the result of an operation is via the name of the
primitive.
0 1 2 3
Jianxing Hou, et al [Page 56]
Internet Drift SS7 TCAP-User Adaptation Layer April1,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 = 0x0203 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spare | value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
value
values
0 It is the last component of a message
1 It is not the last component of a message
3.11.13 Operation
It identifies the action to be executed by a TC-user on request of
another TC-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 = 0x0204 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spare | type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Operation Code /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
type
(In ITU)
values
0 local
1 global operations
2-255 spare
(in ANSI)
values
0 National TCAP
1 Private TCAP
3.11.14 Parameters
It contains any parameters accompanying an operation,or provided
in reply to an operation.
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 = 0x0205 | Length |
Jianxing Hou, et al [Page 57]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.11.15 Error
It contains information provided by the TC-user when an operation
returns failure.
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 = 0x0206 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spare | type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Error /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
type
values
(In ITU)
0 local error
1 global error
2-255 spare
(In ANSI)
0 National TCAP
1 Private TCAP
2-255 spare
3.11.16 Problem code
It identifies the cause for rejecting a component.
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 = 0x0207 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spare | Problem | type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
type
(In ITU)
values
0 General Problem
1 Invoke
Jianxing Hou, et al [Page 58]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
2 Return Result
3 Return Error
4-255 spare
(In ANSI)
values
0 Not used
1 General
2 Invoke
3 Retrun Result
4 Return Error
5 Transaction Portion
6-255 spare
problem
For ITU,see Q773 chap4.2.2.6
For ANSI,seeT1.114.3 chap5.16.2
3.11.17 Correlation ID
The Correlation ID is assigned to Components sent in response to
another Component It is mandatory when the received Component had an
Invoke ID.It is one octet long, if present. In ITU,it is called Linked
ID.
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 = 0x0208 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spare | ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.11.18 Security Context
This identifier is coded context specific (in the context of the
dialogue portion sequence).
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 = 0x0301 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Security Context /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.11.19 Confidentiulity
Jianxing Hou, et al [Page 59]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
Confidentiality Identifier is coded context specific (in the
context of the dialogue portion sequence), constructor.
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 = 0x0302 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Confidentiulity /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.11.20 User Abort information
This indicates User Specified Information supplied by the TC_user
when it aborts a transaction
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 = 0x0303 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.11.21 Abort reason
This parameter indicates whether a dialogue is aborted because
the received application context name is not supported and no
alternative one can be proposed (abort reason =application context not
supported) or because of any other user problem (abort reason =user
specific).
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 = 0x0401 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spare | reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
reason
values
0 application context not supported
1 user specific
2-255 spare
3.11.22 class
Jianxing Hou, et al [Page 60]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
It indicates class of operationsíú
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 = 0x0402 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spare | class |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
class
values
0 spare
1 Both success and failure are reported
2 Only failure is reported
3 Only success is reported.
4 Neither success, nor failure is reported.
5-255 spare
3.11.23 Conversation Type
It indicates the type of Conversationíú
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 = 0x0503 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spare | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-Type
value
0 Conversation Without Permission
1 Conversation With Permission
2-255 spare
3.11.24 Invoke Type
It indicates the type of Invoke 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 = 0x0504 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spare | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-Type
value
Jianxing Hou, et al [Page 61]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
0 Invoke Not Last
1 Invoke Last
2-255 spare
3.11.25 Reject Type
It indicates the type of rejectíú
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 = 0x0505 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spare | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-Type
value
0 TC_U_REJECT
1 TC_L_REJECT
2 TC_R_REJECT
3-255 spare
3.11.26 Query Type
It indicates the type of query.
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 = 0x0506 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| spare | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-Type
value
0 Query Without Permission
1 Query With Permission
2-255 spare
4 Procedures
The TUA layer needs to respond to various local primitives it
receives rom other layers as well as the messages that it receives from
the peer TUA layers. This section describes the TUA procedures in
response to these events.
4.1 TCAP _ TUA Interworking at the SG
Jianxing Hou, et al [Page 62]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
On the SG, the TCAP routing or interworking function determines that
the message must be sent to an AS via the TUA stack, based on
information in the incoming message. The TUA outgoing mapping function
identifies the appropriate Application Server(AS)and selects an active
ASP from the list of ASPs servicing this AS. The appropriate ASP can be
determined based on the routing information in the incoming message,
local load sharing information, etc.The appropriate TUA message is then
constructed and sent to the appropriate endpoint, via the correct SCTP
association and stream.
4.2 Primitives received from the local TUA-User
These support the TUA transport of TCAP-User/TCAP boundary
primitives. The same services as supported by TCAP are to be provided
by TUA. The TCAP-Users at the SG should be able to use the same
primitive interface to TCAP/TUA without any changes. The TCAP-TUA
interworking function takes care of selecting the appropriate stack.
The TUA needs to setup and maintain the appropriate SCTP association
to the selected endpoint. TUA also manages the usage of SCTP streams.
The address information passed by the TUA-user at an ASP must contain:
- a valid SS7 address to reach a destination in the SS7 network via
the appropriate SCTP association to a SG
- a valid IP address/hostname to reach another ASP in the IP network
via the appropriate SCTP association.
4.3 Layer Management Procedures
On receiving primitives from the local Layer Management,the TUA
layer will take the requested action and provide a response to Layer
Management.
An M-SCTP-ESTABLISH request from Layer Management will initiate the
establishment of an SCTP association. An M-SCTP-ESTABLISH confirm will
be sent to Layer Management when the initiated association set-up is
complete. An M-SCTP-ESTABLISH indication is sent upon successful
completion of an incoming SCTP association set-up from a peer TUA node.
An M-SCTP-RELEASE request from Layer Management initiates the
tear-down of an SCTP association. An M-SCTP-RELEASE confirm is sent to
Layer Management when the association tear-down is complete. An M- SCCP
-RELEASE indication is sent to Layer Management upon successful
tear-down of an SCTP association initiated by a peer TUA.
An M-SCTP-STATUS request supports a Layer Management query of the
local status of a particular SCTP association. The TUA responds with
the association status in an M-SCTP-STATUS confirm. No peer TUA
Jianxing Hou, et al [Page 63]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
protocol is invoked.
An M-ASP-STATUS request supports a Layer Management query of the
status of a particular local or remote ASP. The TUA responds with an
M-ASP-STATUS confirm. No peer TUA protocol is invoked.
An M-AS-STATUS request supports a Layer Management query of the
status of a particular AS.The TUA responds with an M-AS-STATUS confirm.
No peer TUA protocol is invoked.
M-ASP-UP,-DOWN,-ACTIVE and _INACTIVE request primitives allow Layer
Management at an IPSP to force state changes. Upon successful
completion, a corresponding confirm primitive is issued by TUA to the
Layer Management.If the invocation is unsuccessful,an Error indication
is provided.
Layer Management is informed by TUA Management about AS/ASP state
changes with the corresponding indications. It is also informed of
received NTFY or ERR messages.
4.4 TUA Management Procedures
This functionality comprises the handling of AS/ASP state and
traffic management messages, TUA peer management messages, SCTP
notifications and the interface with local Layer Management.These
procedures support the TUA management of SCTP Associations and ASP
paths between SGs and ASPs.
4.4.1 AS and ASP State and Traffic Management
The TUA layer on SG needs to maintain the state of each connected
ASP,as a way to manage the traffic to these ASPs and the (logical) ASs
they service.In particular at a SG, the state of each connected ASP is
needed as input to the SG routing function.
4.4.1.1 ASP States
The state of each ASP is maintained in the TUA layer in the SG or
IPSP. The state of an ASP changes due to events. The events include:
- ASP Management messages(ASP-Up,ASP-Down,ASP-Active,ASP-Inactive)
- SCTP Communication Down Notification (SCTP CDI)
The state of the ASP within each AS is important in particular for
the routing function at the SG, in order to direct traffic for a
specific routing key (AS) to the appropriate ASP.
At an ASP, if it is connected to a set of redundant SGPs, this set
Jianxing Hou, et al [Page 64]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
can also be seen as an AS handling all traffic destined for the SS7
network.
The ASP state transition diagram is shown in Figure 4. The possible
states of an ASP are:
ASP-DOWN: The Application Server Process is unavailable. Initially
all ASPs will be in this state.
ASP-UP: The Application Server Process is available but application
traffic is not possible. The ASP can only handle management messages.
ASP-ACTIVE: The Application Server Process is available and
application traffic is possible. Whether traffic will be directed to
this ASP depends on the Traffic Mode Type (over-ride, loadshare with or
without Standby option).
ASP-STANDBY: The remote TUA peer at the ASP is available and ready to
receive application traffic at any time (for a particular Routing
Context or set of Routing Contexts). In this state the ASP can be sent
any non-Data TUA messages.
SCTP CDI: The local SCTP layer's SHUTDOWN COMPLETE notification or
COMMUNICATION LOST notification. The shutdown of an SCTP association
may have been requested by local Layer Management.
+-----------------+
| ASP-ACTIVE |
+----------------------| or |
| | ASP-STANDBY* |
| +-----------------+
| ^ |
| ASP | | ASP
| Active | | Inactive
| | v
| +-------------+
| | |
| | ASP-UP |
| +-------------+
| ^ |
ASP Down | ASP | | ASP Down /
SCTP CDI | Up | | SCTP CDI
| | v
| +-------------+
| | |
+--------------------->| ASP-DOWN |
| |
+-------------+
Jianxing Hou, et al [Page 65]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
Figure 4: ASP State Transition Diagram
*Note: ASP-ACTIVE and ASP-STANDBY differ only in whether the ASP is
currently receiving Data traffic within the AS.
4.4.1.2 AS States
The state of the AS is maintained in the TUA layer on the SG.
The state of an AS changes due to events. These events include:
- ASP state changes : when the first ASP within an AS goes UP
or ACTIVE, or when the last ASP within an AS goes DOWN or
INACTIVE
- Recovery Timer expiry
The possible states of an AS are:
AS-DOWN: The Application Server is unavailable. This state implies
that all related ASPs are in the ASP-DOWN state for this AS.Initially
the AS will be in this state.
AS-UP: The Application Server is available but no application traffic
is possible (i.e. one or more related ASPs are in the ASP-UP state, but
none in the ASP-ACTIVE state).
AS-ACTIVE: The Application Server is available and application
traffic is possible. This state implies that at least one ASP is in the
ASP-ACTIVE state.
AS-PENDING: An active ASP has transitioned from active to inactive
or down and it was the last remaining active ASP in the AS. A recovery
timer T(r) will be started and all incoming SCN messages will be queued
by the SG. If an ASP becomes active before T(r) expires, the AS will
move to AS-ACTIVE state and all the queued messages will be sent to the
active ASP.If T(r) expires before an ASP becomes active, the SG stops
queuing messages and discards all previously queued messages. The AS
will move to AS-UP if at least one ASP is in ASP-UP state, otherwise it
will move to AS-DOWN state.
+----------+ one ASP trans to ACTIVE +-------------+
| |---------------------------->| |
| AS-UP | | AS-ACTIVE |
| |<--- | |
+----------+ \ +-------------+
^ | \ Tr Expiry, ^ |
| | \ at least one | |
Jianxing Hou, et al [Page 66]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
| | \ ASP in UP | |
| | \ | |
| | \ | |
| | \ | |
one ASP | | all ASP \ one ASP | | Last ACT.
trans | | trans to \ trans to | | asp trans
to UP | | DOWN -------\ ACTIVE | | to UP or
| | \ | | DOWN
| | \ | |
| | \ | |
| | \ | |
| v \ | v
+----------+ \ +-------------+
| | --| |
| AS-DOWN | | AS-PENDING |
| | | (queueing) |
| |<----------------------------| |
+----------+ Tr Expiry no ASP +-------------+
in UP state
Tr = Recovery Timer
Figure 5: AS State Transition Diagram
4.4.2 AS/ASP Management procedures
Once an SCTP association is established between SG and ASP, ASP
must issue an ASP-UP message.All ASP Maintenance messages are sent on
a sequenced stream to ensure ordering. SCTP stream '0' is used.
4.4.2.1 ASP-Up
After an ASP has successfully established an SCTP association to an
SG,the SG waits for the ASP to send an ASP-Up message, indicating that
the ASP TUA peer is available. The ASP is always the initiator of the
ASP-Up exchange. This action MAY be initiated at the ASP by an M-ASP
UP request primitive from Layer Management or may be initiated
automatically by an TUA management function.
When an ASP-Up message is received at an SG and internally the remote
ASP is in the "Down" state and not considered locked-out for local
management reasons, the SG marks the remote ASP as "Inactive" and
informs Layer Management with an M-ASP-Up indication primitive.If the
SG knows, via current configuration data, which Application Servers the
Jianxing Hou, et al [Page 67]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
ASP is configured to operate in, it can update the ASP status to
"Inactive" in each AS that it is a member. Alternatively, the SG may
move the ASP into a pool of Inactive ASPs available for future
activation in Application Server(s) denoted in the subsequent ASP-
Active Routing Contexts.The SG responds with an ASP-Up Ack message in
acknowledgement. The SG sends an ASP-Up Ack message in response to a
received ASP-Up message even if the ASP is already marked as "Inactive"
at the SG.
If for any local reason (e.g., management lock-out) the SG cannot
respond with an ASP-Up Ack, the SG responds to an ASP-Up with an ASP-
Down Ack message with Reason "Management Blocking".
At the ASP, the ASP-Up Ack message received is not acknowledged.
Layer Management is informed with an M-ASP UP confirm primitive .
When the ASP sends an ASP-Up message it starts timer T(ack). If the
ASP does not receive a response to an ASP-Up within T(ack),the ASP MAY
restart T(ack) and resend ASP-Up messages until it receives an ASP-Up
Ack message. T(ack) is provisionable, with a default of 2 seconds.
Alternatively, retransmission of ASP-Up messages may be put under
control of Layer Management. In this method, expiry of T(ack) results
in a M-ASP-Up confirmation carrying a negative indication.
The ASP must wait for the ASP-Up Ack message before sending any
other TUA messages (e.g., ASPAC). If the SG receives any other TUA
messages before an ASP Up is received, the SG should discard them.
If an ASP-Up is received and internally the remote ASP is in the
"Active" or "Standby" state, an Error ("Unexpected Message) is returned
and the remote ASP state is not changed.
If an ASP-Up is received and internally the remote ASP is already in
the "Inactive" state,and ASP-Up Ack is returned and no action is taken.
4.4.2.2 ASP-Down
The ASP will send an ASP-Down to an SG when the ASP wishes to be
removed from service in all Application Servers that it is a member and
no longer receive any TUA traffic or management messages. This action
MAY be initiated at the ASP by an M-ASP DOWN request primitive from
Layer Management or may be initiated automatically by an TUA management
function.
Whether the ASP is permanently removed from any AS is a function of
configuration management.
Jianxing Hou, et al [Page 68]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
The SG marks the ASP as "Down", informs Layer Management with an
M-ASP Down indication primitive, and returns an ASP-Down Ack message
to the ASP if one of the following events occur:
- an ASP-Down message is received from the ASP,
- another ASPM message is received from the ASP and the SG has
locked out the ASP for management reasons.
The SG sends an ASP-Down Ack message in response to a received
ASP-Down message from the ASP even if the ASP is already marked as
"Down" at the SG.
At the ASP, the ASP-Down Ack message received is not acknowledged.
Layer Management is informed with an M-ASP Down confirm primitive.
When the ASP sends an ASP-Down it starts timer T(ack). If the ASP
does not receive a response to an ASP-Down within T(ack), the ASP MAY
restart T(ack) and resend ASP-Down messages until it receives an ASP-
Down Ack message.T(ack) is provisionable, with a default of 2 seconds.
Alternatively, retransmission of ASP-Down messages may be put under
control of Layer Management.In this method, expiry of T(ack)results in
a M-ASP-Down confirmation carrying a negative indication.
4.4.2.3 TUA Version Control
If an ASP-Up message with an unsupported version is received, the
receiving end responds with an Error message, indicating the version
the receiving node supports and notifies Layer Management.
This is useful when protocol version upgrades are being performed
in a network. A node upgraded to a newer version should support the
older versions used on other nodes it is communicating with. Because
ASPs initiate the ASP-Up procedure it is assumed that the Error message
would normally come from the SG.
4.4.2.4 ASP-Active
Anytime after the ASP has received an ASP-Up Ack from the SG or
IPSP,the ASP sends an ASP-Active (ASPAC) to the SG indicating that the
ASP is ready to start processing traffic.This action MAY be initiated
at the ASP by an M-ASP Active request primitive from Layer Management
or may be initiated automatically by an TUA management function.In the
case where an ASP wishes to process the traffic for more than one
Application Server across a common SCTP association, the ASPAC contains
a list of one or more Routing Contexts to indicate for which
Application Servers the ASPAC applies. It is not necessary for the ASP
to include all Routing Contexts of interest in the initial ASPAC
Jianxing Hou, et al [Page 69]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
message, thus becoming active in all Routing Contexts at the same time.
Multiple ASPAC messages MAY be used to activate within the Application
Servers independently. In the case where an ASP-Active message does
not contain a Routing Context parameter, the receiver must know, via
configuration data, which Application Server(s) the ASP is a member.
When an ASP Active (ASPAC) message is received, the SG or IPSP
responds with an ASPAC Ack message(with the same Type value contained
in the received APAC), acknowledging that the ASPAC was received and,
depending on the ASPAC Type value, moves the ASP to the "Active" or
"Standby" state within the associated Application Server(s). Layer
Management is informed with an ASP-Active indication primitive. If the
SG or IPSP receives any Data messages before an ASPAC is received, the
SG or IPSP should discard them. By sending an ASPAC Ack, the SG or
IPSP is now ready to receive and send traffic for the related Routing
Contexts. The ASP MUST not send Data messages before receiving an
ASPAC Ack.
Multiple ASPAC Ack messages MAY be used in response to an ASPAC
containing multiple Routing Contexts, allowing the SG or IPSP to
independently Ack for different (sets of) Routing Contexts. The SG or
IPSP sends an Error ("Invalid Routing Context") message for each
invalid or un-configured Routing Context value in a received ASPAC
message.
The SG MUST send an ASP-Active Ack message in response to a
received ASP-Active message from the ASP and the ASP is already marked
as "Active" at the SG.
At the ASP,the ASP-Active Ack message received is not acknowledged.
Layer Management is informed with an M-ASP Active confirm primitive.
When the ASP sends an ASP-Active it starts timer T(ack).If the ASP
does not receive a response to an ASP-Active within T(ack), the ASP MAY
restart T(ack) and resend ASP-Active messages until it receives an ASP-
Active Ack message. T(ack) is provisionable, with a default of 2
seconds. Alternatively, retransmission of ASP-Active messages may be
put under control of Layer Management. In this method, expiry of
T(ack) results in a M-ASP-Active confirmation carrying a negative
indication.
There are four modes of Application Server traffic handling in the
SG TUA Over-ride, Over-ride (Standby), Loadshare and Load-share
(Standby). The Traffic Mode Type parameter in the ASPAC message
indicates the traffic handling mode used in a particular Application
Server. If the SG determines that the mode indicated in an ASPAC is
unsupported or incompatible with the mode currently configured for the
Jianxing Hou, et al [Page 70]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
AS, the SG responds with an Error message indicating "Unsupported /
Invalid Traffic Handling Mode". If the Traffic Handling mode of the
Application Server is not already known via configuration data, then
the Traffic handling mode indicated in the first ASPAC message causing
the transition of the Application Server state to "Active" MAY be used
to set the mode.
In the case of an Over-ride mode AS,reception of an ASPAC message at
an SG causes the redirection of all traffic for the AS to the ASP that
sent the ASPAC. Any previously active ASP in the AS is now considered
Inactive and will no longer receive traffic from the SG within the AS.
The SG or IPSP sends a Notify (Alternate ASP-Active) to the previously
active ASP in the AS, after stopping all traffic to that ASP.
In the case of Over-ride (Standby) mode the traffic is not started to
the ASP until the previously active ASP transitions to "Inactive or
"Down" state. At this point the ASP that sent the Over-Ride (Standby)
ASPAC is moved to the Active state and the traffic is redirected. A
second ASP-Active Ack message with a new Traffic Mode Type ("Over-
ride", previously "Over-ride(Standby)") is sent to the ASP. A Notify
(Alternate ASP-Active) message is not sent in this case.
In the case of a Load-share mode AS,reception of an ASPAC message at
an SG or IPSP causes the direction of traffic to the ASP sending the
ASPAC, in addition to all the other ASPs that are currently active in
the AS. The algorithm at the SG for load-sharing traffic within an AS
to all the active ASPs is implementation dependent. The algorithm
could, for example be round-robin or based on information in the Data
message (e.g., such as the SLS, SCCP SSN, TCAP DID value).
An SG or IPSP, upon reception of an ASPAC for the first ASP in a
Loadshare AS, MAY choose not to direct traffic to a newly active ASP
until it determines that there are sufficient resources to handle the
expected load (e.g., until there are sufficient ASPs "Active" in the
AS).
In the case of Load-share (Standby) mode,the traffic is not started
to the ASP until the SG or IPSP determines that there are insufficient
resources available in the AS. This is likely when one of the active
load-sharing ASPs transitions to the "Inactive" or "Down" state. At
this point the ASP that sent the Load-share (Standby) ASPAC is moved to
the Active state and traffic is started. A second ASP-Active Ack
message with a new Traffic Mode Type ("Load-share" - previously
"Loadshare(Standby)") is sent to the ASP. A Notify ("Insufficient ASP
resources active in AS ") message is not sent in this case.
All ASPs within a load-sharing mode AS must be able to handle any
Jianxing Hou, et al [Page 71]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
traffic within the AS, in order to accommodate any potential fail-over
or rebalancing of the offered load.
4.4.2.5 ASP Inactive
When an ASP wishes to withdraw from receiving traffic within an AS,
the ASP sends an ASP Inactive (ASPIA) to the SG or IPSP.This action MAY
be initiated at the ASP by an M-ASP INACTIVE request primitive from
Layer Management or may be initiated automatically by an TUA
management function. In the case where an ASP is processing the
traffic for more than one Application Server across a common SCTP
association, the ASPIA contains one or more Routing Contexts to
indicate for which Application Servers the ASPIA applies. In the case
where an ASP-Inactive message does not contain a Routing Context
parameter, the receiver must know, via configuration data, which
Application Servers the ASP is a member and move the ASP to the
"Inactive" state in each AS.
In the case of an Over-ride mode AS, where another ASP has already
taken over the traffic within the AS with an Over-ride ASPAC, the ASP
that sends the ASPIA is already considered by the SG to be "Inactive".
An ASPIA Ack message is sent to the ASP, after ensuring that all
traffic is stopped to the ASP.
In the case of a Load-share mode AS, the SG moves the ASP to the
"Inactive" state and the AS traffic is re-allocated across the
remaining "active" ASPs per the load-sharing algorithm currently used
within the AS. A NTFY(Insufficient ASP resources active in AS) may be
sent to all inactive ASPs, if required. However, if a Loadshare
(Standby) ASP is available, it may be now immediately included in the
loadshare group and a Notify message is not sent. An ASPIA Ack message
is sent to the ASP after all traffic is halted and Layer Management is
informed with an ASP-INACTIVE indication primitive.
Multiple ASPIA Ack messages MAY be used in response to an ASPIA
containing multiple Routing Contexts, allowing the SG or IPSP to
independently Ack for different (sets of) Routing Contexts. The SG or
IPSP sends an Error ("Invalid Routing Context") message for each
invalid or un-configured Routing Context value in a received ASPIA
message.
The SG MUST send an ASP-Inactive Ack message in response to a
received ASP-Inactive message from the ASP and the ASP is already
marked as "Inactive" at the SG.
At the ASP, the ASP-INACTIVE Ack message received is not acknowledged.
Layer Management is informed with an M-ASP INACTIVE confirm primitive.
Jianxing Hou, et al [Page 72]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
When the ASP sends an ASP-Inactive it starts timer T(ack). If the ASP
does not receive a response to an ASP-Inactive within T(ack), the ASP
MAY restart T(ack) and resend ASP-Inactive messages until it receives
an ASP-Inactive Ack message. T(ack) is provisionable, with a default
of 2 seconds. Alternatively, retransmission of ASP-Inactive messages
may be put under control of Layer Management. In this method, expiry
of T(ack) results in a M-ASP-Inactive confirmation carrying a negative
indication.
If no other ASPs are "Active" or "Standby" in the Application Server,
the SG sends a NTFY(AS-Pending) to all inactive ASPs of the AS and
either discards all incoming messages for the AS or starts buffering
the incoming messages for T(r)seconds, after which messages will be
discarded. T(r) is configurable by the network operator. If the SG
receives an ASPAC from an ASP in the AS before expiry of T(r), the
buffered traffic is directed to the ASP and the timer is cancelled. If
T(r) expires, the AS is moved to the "Inactive" state.
4.4.3 SGP Mangement Procedures
4.4.3.1 SGP Status
There are three possible statuses as follow:
SGP-INACTIVE: The remote TUA peer at the SGP is available (and the
related SCTP association is up) but application traffic is stopped.
SGP-ACTIVE: The remote TUA peer at the SGP is available and
application traffic is active .
SGP-STANDBY: The remote TUA peer at the ASP is available and ready
to receive application traffic at any time .
4.4.3.2 SGP Mangement
When SGP receives an ASP Active message from ASP,it sends an Active
Ack message to ASP as response.In the message,it tell ASP it's status.
When Asp receives this message,it determines the SGP's Traffic Handling
Mode.
When the SGP's Traffic Handling Mode is Over-ride,if ASP detects the
active SGP is unavailable, it selects a standby SGP and set it's status
to active,it changes former active SGP's status to standby.When an ASP
receives a SGP Active message from a SGP,if the SGP's status at the ASP
is standby,the ASP sets the SGP's status to active and changs the
former active SGP's status to standby.
4.4.4 TUA peer management messages
4.4.4.1 Notify
Jianxing Hou, et al [Page 73]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
A NTFY message reflecting a change in the AS state is sent to all
ASPs in the AS, except those in the "Down" state, with appropriate
Status Type/ID.
In the case where a NTFY (AS-Pending) message is sent by an SG that
now has no active ASPs to service the traffic, or a NTFY
(Insufficient ASPs) is sent in the Loadshare mode, the NTFY does not
explicitly force the ASP(s) receiving the message to become active.
The ASPs remain in control of what (and when) action is taken.
4.4.4.2 Error
The ERR message is used to signal invalid protocol behaviour.
5 Examples of TUA Procedures
5.1 Establishment of Association and Traffic between SGPs and ASPs
5.1.1.1 Single ASP in an Application Server ("1+0" sparing)
This scenario shows the example TUA message flows for the
establishment of traffic between an SG and an ASP, where only one ASP
is configured within an AS (no backup). It is assumed that the SCTP
association is already set-up.
SG ASP
| |
|<-------------ASP Up------------|
|-----------ASP-Up Ack---------->|
| |
|<------- ASP Active-------------|
|-----ASP Active Ack------------>|
| |
5.1.1.2 Two ASPs in Application Server ("1+1" sparing)
This scenario shows the example TUA message flows for the
establishment of traffic between an SG and two ASPs in the same
Application Server, where ASP1 is configured to be "active" and ASP2 a
"standby" in the event of communication failure or the withdrawal from
service of ASP1. ASP2 may act as a hot, warm, or cold standby
depending on the extent to which ASP1 and ASP2 share call/transaction
state or can communicate call state under failure/withdrawal events.
The example message flow is the same whether the ASP-Active messages
are Over-ride or Load-share mode although typically this example would
use an Over-ride mode.
Jianxing Hou, et al [Page 74]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
SG ASP1 ASP2
| | |
|<--------ASP Up----------| |
|-------ASP-Up Ack------->| |
| | |
|<-----------------------------ASP Up----------------|
|-----------------------------ASP-Up Ack------------>|
| | |
| | |
|<-------ASP Active-------| |
|------ASP-Active Ack---->| |
| | |
5.1.1.3 Two ASPs in an Application Server ("1+1" sparing, load-sharing
case)
This scenario shows the example TUA message flows for the
establishment of traffic between an SG and two ASPs in the same
Application Server, where the two ASPs are brought to "active" and
load-share the traffic load.In this case, one ASP is sufficient to
handle the total traffic load.
SG ASP1 ASP2
| | |
|<---------ASP Up---------| |
|--------ASP-Up Ack------>| |
| | |
|<------------------------------ASP Up---------------|
|-----------------------------ASP Up Ack------------>|
| | |
| | |
|<--ASP Active -----------| |
|-----ASP-Active Ack----->| |
| | |
|<----------------------------ASP Active ------------|
|-------------------------------ASP-Active Ack------>|
| | |
5.1.1.4 Three ASPs in an Application Server ("n+k" sparing, load-sharing
case)
This scenario shows the example TUA message flows for the
establishment of traffic between an SG and three ASPs in the same
Application Server, where two of the ASPs are brought to "active" and
share the load. In this case, a minimum of two ASPs are required to
Jianxing Hou, et al [Page 75]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
handle the total traffic load (2+1 sparing).
SG ASP1 ASP2 ASP3
| | | |
|<------ASP Up-------| | |
|-----ASP-Up Ack---->| | |
| | | |
|<--------------------------ASP Up-------| |
|-------------------------ASP-Up Ack---->| |
| | | |
|<---------------------------------------------ASP Up--------|
|---------------------------------------------ASP-Up Ack---->|
| | | |
| | | |
|<--ASP Act ---------| | |
|----ASP-Act Ack---->| | |
| | | |
|<--------------------ASP Act ----------| |
|-----------------------ASP-Act Ack----->| |
| | | |
5.1.2 ASP Traffic Fail-over Examples
5.1.2.1 (1+1 Sparing, withdrawal of ASP, Back-up Over-ride)
ASP1 withdraws from service:
SG ASP1 ASP2
| | |
|<-----ASP Inactive-------| |
|----ASP Inactive Ack---->| |
|-----------------------NTFY(ASP-Inact.)(Optional)-->|
| | |
|<------------------------------ ASP Active----------|
|------------------------------ASP-Active Ack------->|
| |
Note: If the SG detects loss of the TUA peer (TUA heartbeat loss or
detection of SCTP failure), the initial SG-ASP1 ASP Inactive message
exchange would not occur.
5.1.2.2 (1+1 Sparing, Back-up Over-ride)
ASP2 wishes to over-ride ASP1 and take over the traffic:
Jianxing Hou, et al [Page 76]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
SG ASP1 ASP2
| | |
|<------------------------------ ASP Active----------|
|-------------------------------ASP-Active Ack------>|
|----NTFY(Alt ASP-Act)--->|
| | |
5.1.2.3 (n+k Sparing, Load-sharing case, withdrawal of ASP)
ASP1 withdraws from service:
SG ASP1 ASP2 ASP3
| | | |
|<----ASP Inact.-----| | |
|---ASP-Inact Ack--->| | |
| | | |
|---------------------------------NTFY(Ins. ASPs)(Optional)->|
| | | |
|<-----------------------------------------ASP Act ----------|
|-------------------------------------------ASP Act (Ack)--->|
| | | |
The Notify message to ASP3 is optional, as well as the ASP-Active from
ASP3. The optional Notify can only occur if the SG maintains knowledge
of the minimum ASP resources required - for example if the SG knows
that "n+k" = "2+1" for a load-share AS and "n" currently equals "1".
Note: If the SG detects loss of the ASP1 TUA peer (TUA heartbeat loss
or detection of SCTP failure), the first SG-ASP1 ASP Inactive message
exchange would not occur.
5.1.3 TCAP/TCAP-User Service Translation Examples
When the TUA layer on the ASP has a DH message to send to the SG, it
will do the following:
- Determine the correct SGP
- Find the SCTP association to the chosen SGP
- Determine the correct stream in the SCTP association based on
the DID
Jianxing Hou, et al [Page 77]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
- Build the DH message, fill TUA Message Header, fill Common Header
- Send the DH message to the remote TUA peer in the SG, over the
SCTP association
When the TUA layer on the SG has a DH message to send to the ASP, it
will do the following:
- Determine the AS
- Determine the Active ASP (SCTP association) within the AS
- Determine the correct stream in the SCTP association based on
the DID
- Build the DH message, fill in TUA Message Header, fill in
Common Header
- Send the DH message to the remote TUA peer in the ASP, over the
SCTP association
An example of the message flows for establishing a dialogue service
is shown below.An active association between ASP and SG is established
(Section 5.1) prior to the following message flows.
SG ASP
<----------- Invoke Request
<----------- Query(Begin) Request
Conversation(Continue)
Indication ---------->
Result Indication ---------->
<----------- Invoke Request
<----------- Conversation(Continue) Request
.
.
.
End(respone)Indication ----------->
Result Indication ----------->
An example of the message flows for a failed attempt to establish a
dialogue on the signaling channel is shown below. In this case, the
gateway has a problem with its physical connection ,
Jianxing Hou, et al [Page 78]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
so it cannot establish a dialogue on the signaling channel.
SG ASP
<----------- Invoke Request
<----------- Query(Begin) Request
Abort Indication ---------->
5.2 IP-IP Architecture
The sequences below outline logical steps for a variety of scenarios
within an IP-IP architecture. Please note that these scenarios
cover a Primary/Backup configuration. Where there is a load-sharing
configuration then the AS can declare availability when 1 ASP issues
ASPAC but can only declare unavailability when all ASPs have issued
ASPIA.
5.2.1 Establishment of TUA connectivity
The following shows an example establishment of TUA connectivity.
In this example, each IP SP consists of a Management Instance (MI)
and two ASPs. The Management Instance handles the address mapping
mechanisms and monitors the states of the remote peer. For
simplicity, the Management Instances and ASPs are considered as a
separate entity. This is not a requirement, as they can be co-
located with an ASP.
The following must be established before TUA traffic can flow. A
connectionless flow is shown for simplicity.
Each node is configured (via MIB, for example) with the connections
that need to be setup
IP SEP A IP SEP B
ASP-a1 ASP-a2 MI a MI b ASP-b2 ASP-b1
(Primary) (Backup) (Backup) (Primary)
Establish SCTP Connectivity
|-- Est. SCTP Ass.--|
|------ Establish SCTP Association -------|
|------------- Establish SCTP Association -------------|
|------------------ Establish SCTP Association ------------------|
Jianxing Hou, et al [Page 79]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
|--- Establish SCTP Assoc. ----|
|------- Establish SCTP Association --------|
|------------ Establish SCTP Association -------------|
|-- Establish SCTP Association -|
|------- Establish SCTP Association ------|
Establish TUA Connectivity
+---------------ASP Up------------------->
<---------------ASP Up Ack---------------+
+------------ASP Up----------->
<------------ASP Up Ack-------+
<--------------ASP Up-------------+
+--------------ASP Up Ack--------->
<----------------ASP Up---------------------+
+----------------ASP Up Ack----------------->
+---------------ASP Act------------------>
<---------------ASP Act Ack--------------+
<----------------ASP Act--------------------+
+----------------ASP Act Ack---------------->
Traffic can now flow directly between ASPs.
+-------------------------------TCAP_User Message------------------>
5.2.2 Failover scenarios
The following sequences address failover of ASP
5.2.2.1 Successful ASP Failover scenario
The following is an example of a successful failover scenario, where
there is a failover from ASP-a1 to ASP-a2, i.e. Primary to Backup.
Since data transfer passes directly between peer ASPs, ASP-b1 is
notified of the failover of ASP-a1 and must buffer outgoing data
messages until ASP-a2 becomes available.
IP SEP A IP SEP B
ASP-a1 ASP-a2 MI a MI b ASP-b2 ASP-b1
(Primary) (Backup) (Backup) (Primary)
Jianxing Hou, et al [Page 80]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
+--------------ASP Inact----------------->
<--------------ASP Inact Ack-------------+
<----NTFY (ASP-a1 Inactive)---+
+----------ASP Act------------>
<----------ASP Act Ack--------+
5.2.2.2 Unsuccessful ASP Failover scenario
The sequence is the same as 5.2.2.1 except that, since the backup
fails to come in then, the Notify messages declaring the
availability of the backup are not sent.
6 Security
6.1 Introduction
TUA is designed to carry signaling messages for telephony services.
As such, TUA must involve the security needs of several parties: the
end users of the services; the network providers and the
applications involved. Additional security requirements may come
from local regulation. While having some overlapping security
needs, any security solution should fulfill all of the different
parties' needs.
6.2 Threats
There is no quick fix, one-size-fits-all solution for security. As
a transport protocol, TUA has the following security objectives:
* Availability of reliable and timely user data transport.
* Integrity of user data transport.
* Confidentiality of user data.
TUA runs on top of SCTP. SCTP provides certain transport related
security features, such as:
* Blind Denial of Service Attacks
* Flooding
* Masquerade
* Improper Monopolization of Services
When TUA is running in professionally managed corporate or service
provider network, it is reasonable to expect that this network
includes an appropriate security policy framework. The "Site
Security Handbook" [RFC 2196] should be consulted for guidance.
Jianxing Hou, et al [Page 81]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
When the network in which TUA runs in involves more than one party,
it may not be reasonable to expect that all parties have implemented
security in a sufficient manner. End-to-end security should be the
goal, therefore, it is recommended that IPSEC is used to ensure
confidentiality of user payload. Consult [RFC 2409] for more
information on configuring IPSEC services.
6.3 Protecting Confidentiality
Particularly for mobile users, the requirement for confidentiality
may include the masking of IP addresses and ports. In this case
application level encryption is not sufficient; IPSEC ESP should be
used instead. Regardless of which level performs the encryption, the
IPSEC ISAKMP service should be used for key management.
7 IANA Considerations
7.1 SCTP Payload Protocol ID
A request will be made to IANA to assign SCTP Payload Protocol IDs.
A Payload ID for the TUA will be registered.
The Payload ID is included in each SCTP data chunk, to indicate
which protocol SCTP is carrying. This Payload ID is not directly
used by SCTP but may be used by certain network entities to identify
the type of information being carried in this DATA chunk.
It is assumed that the Payload ID for TUA will be 8.
7.2 Protocol Extensions
This protocol may also be extended through IANA in three ways:
-- through definition of additional message classes,
-- through definition of additional message types, and
-- through definition of additional message parameters.
The definition and use of new message classes, types and parameters
is an integral part of SIGTRAN adaptation layers. Thus, these
extensions are assigned by IANA through an IETF Consensus action as
defined in [RFC2434].
The proposed extension must in no way adversely affect the general
working of the protocol.
7.2.1 IETF Defined Message Classes
The documentation for a new message class MUST include the following
Jianxing Hou, et al [Page 82]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
information:
(a) A long and short name for the message class;
(b) A detailed description of the purpose of the message class.
7.2.2 IETF Defined Message Types
Documentation of the message type MUST contain the following
information:
(a) A long and short name for the new message type;
(b) A detailed description of the structure of the message.
(c) A detailed definition and description of intended use of each
field within the message.
(d) A detailed procedural description of the use of the new message
type within the operation of the protocol.
(e) A detailed description of error conditions when receiving this
message type.
When an implementation receives a message type which it does not
support, it MUST respond with an Error (ERR) message, with an Error
Code = Unsupported Message Type.
7.2.3 IETF-defined TLV Parameter Extension
Documentation of the message parameter MUST contain the following
information:
(a) Name of the parameter type.
(b) Detailed description of the structure of the parameter field.
This structure MUST conform to the general type-length-value
format described earlier in the document.
(c) Detailed definition of each component of the parameter value.
(d) Detailed description of the intended use of this parameter type,
and an indication of whether and under what circumstances
multiple instances of this parameter type may be found within
the same message type.
8 Timer Values
Tr 2 seconds
9 Acknowledgements
The authors would like to thank John Loughney , Greg Sidebottom ,
Zujian Li and Yi Zhang for their insightful comments and suggestions.
10 Authors' Addresses
Jianxing Hou
Jianxing Hou, et al [Page 83]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
Kefa Road, Science-Based Industrial Park,
Nanshan District,Shenzhen 518057 China
Email: hjxing@huawei.com
Ming Lin
Kefa Road, Science-Based Industrial Park,
Nanshan District,Shenzhen 518057 China
Email: mlin@huawei.com
11 References
[2719] RFC 2719, "Framework Architecture for Signaling
Transport"
[ITU SCCP] ITU-T Recommendations Q.711-714, 'Signaling System
No. 7 (SS7) - Signaling Connection Control Part
(SCCP)'
[ANSI SCCP] ANSI T1.112 'Signaling System Number 7 - Signaling
Connection Control Part'
[ITU TCAP] ITU-T Recommendation Q.771-775 'Signaling System No.
7 SS7) - Transaction Capabilities (TCAP)
[ANSI TCAP] ANSI T1.114 'Signaling System Number 7 - Transaction
Capabilities Application Part'
[SCTP] RFC 2960 "Stream Control Transport Protocol" R.
Stewart, et. Al. November 2000.
[M3UA] MTP3-User Adaptation Layer <draft-ietf-sigtran-m3ua-
05.txt>, Decemenber 2000, Work in Progress.
[SUA] SS7 SCCP-User Adaptation Layer<draft-ietf-sigtran-sua
-05.txt>,February 2001,Work in Progress.
[2401] RFC 2401, "Security Architecture for the Internet
Protocol", S. Kent, R. Atkinson, November 1998.
[2196] RFC 2196, "Site Security Handbook", B. Fraser Ed.,
September 1997.
[E.164-DNS] RFC 2916 "E.164 number and DNS", P. Faltstrom,
September 2000.
[RFC2434] RFC 2434 "Guidelines for Writing an IANA
Jianxing Hou, et al [Page 84]
Internet Drift SS7 TCAP-User Adaptation Layer April1,2001
Considerations Section in RFCs", T. Narten, H.
Alvestrand, October 1998.
[ITU-MTP] ITU-T Recommendations Q.701-Q.705, 'Signalling System
No. 7 (SS7) - Message Transfer Part (MTP)'
[ANSI-MTP] ANSI T1.111 'Signaling System Number 7 - Message
Transfer Part'
| ||||||||||||||||
| Last modified: Fri, 14 Nov 2014 17:14:50 GMT Copyright © 2014 OpenSS7 Corporation All Rights Reserved. | |||||||||||||||||