| draft-bidulock-sigtran-tua-02 Description: Request For Comments
You can download source copies of the file as follows:
Listed below is the contents of file draft-bidulock-sigtran-tua-02.txt.
Network Working Group Brian Bidulock
INTERNET-DRAFT OpenSS7 Corporation
July 26, 2003
Expires in January 2004
SS7 TCAP-User Adaptation Layer
(TUA)
<draft-bidulock-sigtran-tua-02.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 or RFC 2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as 'work in progress'.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
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).
Copyright
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document defines a protocol for the transport of any SS7 TCAP-
User signalling (e.g, INAP, MAP, etc.) over IP using the Stream
Control Transport Protocol [RFC 2960]. The protocol should be modular
and symmetric, to allow it to work in diverse architectures, such as a
Signalling Gateway and IP Signalling End-point architecture. Protocol
elements are added to allow seamless operation between peers in the
SS7 and IP domains.
B. Bidulock Version 0.2 Page 1
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
Contents
A complete table of contents, list of illustrations and tables, and
change history for this document appears the end of the document.
1. Introduction
There is on-going integration of SCN and IP networks. Network
service providers are designing IP-based signalling architectures that
need support for SS7 and SS7-like signalling 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 is a
need for interworking between the SS7 and IP domains [RFC 2719]. This
draft defines a protocol for the transport of SS7 TCAP User protocols
[Q.771, T1.114], such as MAP and INAP, over IP using the Stream
Control Transmission Protocol (SCTP) [RFC 2960].
1.1. Scope
This document details the delivery of TC-user messages (MAP, CAP,
INAP, etc.) over IP between two signalling end-points. Consideration
is given for the transport from an SS7 Signalling Gateway (SG) to an
IP signalling node (such as an IP-resident Database) as described in
the Framework Architecture for Signalling Transport [RFC 2719] This
protocol can also support transport of TC-user messages between two
end-points wholly contained within and IP network.
The delivery mechanism addresses the following criteria:
+ Support for transfer of TCAP messages
+ Support for TCAP operation class 1, 2, 3 and 4 operation.
+ Support for the operation of TC-User protocol peers.
+ Support for the management of SCTP transport associations between
signalling gateways and IP-based signalling nodes.
+ Support for distributed IP-based signalling nodes.
+ Support for the asynchronous reporting of status changes to
management functions.
1.2. Terminology and Abbreviations
1.2.1. Abbreviations
CAP -- CAMEL Application Protocol.
CTP -- Common Transport Protocol.
DNS -- Directory Name Service.
GTT -- Global Title Translation.
HLR -- Home Location Register.
ID -- Identifier.
IMSI -- International Mobile Station Identifier.
INAP -- Intelligent Network Application Part.
IPSP -- IP Signalling Point.
B. Bidulock Version 0.2 Page 2
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
MAP -- Mobile Application Protocol.
MIB -- Management Information Base.
MSC -- Mobile Switching Center.
PC -- SS7 Point Code.
SCCP -- Signalling Connection Control Part.
SCN -- Switched Circuit Network.
SCTP -- Stream Control Transmission Protocol.
SCP -- Signalling Control Point.
SLP -- Service Logic Program.
SS7 -- Signalling System No. 7.
SSP -- Service Switching Point.
SUA -- SS7 SCCP-User Adpatation Layer.
TCAP -- Transaction Capabilities Application Part.
TC -- TCAP Component Sub-Layer.
TMF -- Transaction Mapping Function.
TR -- TCAP Transaction Sub-layer.
TUA -- SS7 TCAP-User Adaptation Layer.
VLR -- Visitor Location Register.
1.2.2. Terminology
Application Server (AS) - a logical entity serving a specific Routing
Key. An example of an Application Server is a virtual database
element handling all HLR or SCP transactions for a particular SS7
Signalling Point. The AS contains a set of one or more unique
Application Server Processes, of which one or more is normally
actively processing traffic. There is a one-to-one relationship
between an Application Server and a Routing Key.
Application Server Process (ASP) - a process instance of an
Application Server. An Application Server Process serves as an
active, backup, load-share or broadcast process of an Application
Server (e.g, part of a distributed signalling node or database
element). Examples of ASPs are MGCs, IP SCPs, or IP HLRs. An ASP
contains an SCTP end-point and may be configured to process
traffic within more that one Application Server.
Association - refers to an SCTP association [RFC 2960]. The
association provides the transport for the delivery of TCAP
protocol data units and TUA layer peer messages.
Component Sub-layer (TC)
The Component Sub-layer of TCAP [Q.771].
Fail-over - the capability to reroute signalling traffic as required
to an alternate Application Server Process, or group of ASPs,
within an Application Server in the event of failure or
unavailability of a currently used Application Server Process.
Fail-over may apply upon the return to service of a previously
unavailable Application Server Process.
B. Bidulock Version 0.2 Page 3
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
Host - the computing platform that the process (SGP, ASP or IPSP) is
running on.
IP Server Process (IPSP) - a process instance of an IP-based
application. An IPSP is essentially the same as an ASP, except
that it uses TUA in a point-to-point fashion.
Layer Management (LM) - a nodal function that handles the inputs and
outputs between the TUA layer and a local management entity.
Message Transfer Part (MTP)
The Message Transfer Part [Q.701, T1.111] of the SS7 protocol.
Nodal Interworking Function (NIF) - an implementation dependent
interworking function present at a Signalling Gateway that
interworks primitives and procedures between the TCAP and TUA
layers in the SG.
Network Appearance (NA) - a value that identifies the SS7 network
context of a Routing Key. The Network Appearance value is of
significance only within an administrative domain; it is
coordinated between the SG and ASP.
Network Byte Order - the ordering of bytes most-significant-byte
first, also referred to as Big Endian.
Routing Context (RC) - a value that uniquely identifies a Routing Key
and an Application Server. Routing Context values are either
configured using a configuration management interface, or by using
the Routing Key Management (RKM) messages and procedures defined
for TUA.
Routing Key (RK) - describes a set of SS7 parameters and parameter
values that uniquely define the range of signalling traffic to be
handled by a particular Application Server.
Signalling Connection Control Part (SCCP) - The Signalling Connection
Control Part [Q.711] of the SS7 protocol.
Signalling Gateway (SG) - a signalling agent that exchanges SCN native
signalling at the edge of the IP network [RFC 2719]. An SG
appears to the SS7 network as an SS7 Signalling Point. An SG
contains a set of one or more Signalling Gateway Processes, of
which one or more is normally actively processing traffic. When
an SG contains more than one SGP, the SG is a logical entity and
the contained SGPs are assumed to be coordinated into a single
management view both toward the SS7 network and toward the
supported Application Servers.
Signalling Gateway Process (SGP) - a process instance of a Signalling
Gateway. It serves as an active, backup, load-sharing or
broadcast process of a Signalling Gateway.
B. Bidulock Version 0.2 Page 4
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
Stream - an SCTP stream; a unidirectional 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 unordered delivery service.
Transaction Capabilities Application Part (TCAP) - The Transaction
Capabilities Application Part [Q.771, T1.114] of the SS7 protocol.
Transaction Mapping Function (TMF) - an implementation dependent
function that is responsible for resolving the address and
application context presented in the incoming TUA message to the
correct SCTP association and Routing Context for the desired
application. The TMF MAY use routing context or routing key
information as selection criteria for the appropriate SCTP
association.
Transaction Sublayer (TR) - The Transaction Sublayer of TCAP [Q.771].
Transport Address - an address that 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 IP
address and an SCTP port number [1].
1.3. TUA Overview
1.3.1. Signalling Transport Architecture
The framework architecture that has been defined for SCN signalling
transport over IP [RFC 2719] uses multiple components, including an IP
transport protocol, a signalling common transport protocol and an
adaptation module to support the services expected by a particular SCN
signalling protocol from its underlying protocol layer.
In general terms, the TUA architecture can be modeled as a peer-to-
peer architecture. The first section considers the SS7-to-IP
interworking architectures for TCAP class 1, 2, 3, and 4 operations.
For this case, it is assumed that the ASP initiates the establishment
of the SCTP association with the SG.
1.3.2. Protocol Architecture for Classes 1, 2, 3 and 4
In this architecture (illustrated in Figure 1), the TCAP and TUA
layers interface in the SG. A Nodal Interworking Function (NIF)
provides for interworking between the TCAP and TUA layers and provides
for the transfer of the user messages as well as management messages.
B. Bidulock Version 0.2 Page 5
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
......... ............... .........
: : : : : :
: SEP : SS7 : : IP : :
: or :.........: SG :........: ASP :
: STP : : : : :
:.......: :.............: :.......:
_______ _____________ _______
| | | | | |
| TC-U | | NIF | | TC_U |
|-------| |------ ------| |-------|
| 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
NIF - Nodal Interworking Function
Figure 1. Protocol Architecture
1.3.3. All IP Architecture
This architecture, illustrated in Figure 2, can be used to carry a
protocol which uses the transport services of TCAP, but is contained
within an IP network. This allows extra flexibility in developing
networks, especially when interaction between legacy signalling is not
needed. The architecture removes the need for a signalling gateway
function.
B. Bidulock Version 0.2 Page 6
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
........ ........
: : IP : :
: AS :........: AS :
: : : :
:......: :......:
______ ______
| | | |
| AP | | AP |
|------| |------|
| TUA | | TUA |
|------| |------|
| SCTP | | SCTP |
|------| |------|
| IP | | IP |
|______| |______|
| |
|________________|
AP - Application Protocol (e.g. - MAP/INAP)
Figure 2. All IP Architecture
1.3.4. ASP Fail-over Model and Terminology
The TUA protocol supports ASP fail-over functions to support a high
availability of transaction processing capability.
An Application Server can be considered as a list of all ASPs
configured or registered to handled TC-user messages within a certain
range of routing information, or within a certain set of transaction
dialogues, 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
ASPs.
For operational considerations, see Appendix A.
1.3.5. Services Provided by the TUA Layer
1.3.5.1. Support for the transport of TCAP-User Messages
The TUA supports the transfer of TC-user messages. The TUA layer
at the SG and the ASP support the seamless transport of user messages
between the SG and the ASP.
1.3.5.1.1. TCAP Operation Class Support
Depending on the TC-users supported, the TUA supports the 4 possible
TCAP operation classes transparently. The TCAP operation classes are
defined as follows:
Operation Class 1 - provides for transactions reporting both
success and failure.
Operation Class 2 - provides for transactions reporting failure.
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
Operation Class 3 - provides for transactions reporting success.
Operation Class 4 - provides for transactions reporting neither
success nor failure.
1.3.5.2. Native Management Functions
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 necessary.
1.3.5.3. Interworking with TCAP Management Functions
The TUA layer provides interworking with TCAP management functions
at the SG for seamless inter-operation between the SCN network and the
IP network. TUA provides the following management functions:
(1) Provides an indication to the TC-user at an ASP that an SS7
subsystem, SCCP User Part or MTP Destination is unavailable.
(2) Provides an indication to the TC-user at an ASP that an SS7
subsystem, SCCP User Part or MTP Destination is available.
(3) Provides an indication to the TC-user at an ASP that an SS7
subsystem or MTP Destination is congested (flow controlled).
(4) Provides the initiation of an audit of SS7 subsystems or MTP
Destinations status at the SG.
Table 1. Mapping of Management Primitives
+------------------------+---------------------------+------------+
| Name | Reference | TUA |
+-----------+------------+-------------+-------------+ Management |
| Generic | Specific | ITU-T Q.711 | ANSI T1.112 | Message |
+-----------+------------+-------------+-------------+------------+
| N-STATE | Request | 6.3.2.3.2 | 2.3.2.3.2 | DUNA |
| | Indication | | | DAVA |
| | | | | SCON |
+-----------+------------+-------------+-------------+------------+
| N-PCSTATE | Indication | 6.3.2.3.3 | 2.3.2.3.4 | DUNA |
| | | | | DAVA |
| | | | | SCON |
| | | | | DUPU |
+-----------+------------+-------------+-------------+------------+
| N-COORD | Request | 6.3.2.3.1 | 2.3.2.3.3 | DRST |
| | Indication | | | |
| | Response | | | |
| | Confirm | | | |
+-----------+------------+-------------+-------------+------------+
B. Bidulock Version 0.2 Page 8
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
The interworking with TCAP management messages consists of DUNA,
DAVA, DAUD, DRST, DUPU or SCON messages (defined in Section 3) on
receipt of management events (defined by TCAP) to the appropriate
ASPs. The primitives in Table 1 are sent between the TCAP and TUA
management functions in the SG to trigger events in the IP and SS7
domain.
The TUA layer provides transparent passing of SCCP availability,
unavailability and congestion status indication primitives (N-STATE,
N-PCSTATE and N-COORD) as provided for in ITU-T Q.771 2.2.3 [Q.771].
1.3.5.4. Support for the Management of SCTP Associations
The TUA layer at the SGP maintains the availability state of all
configured remote ASPs, to manage the SCTP Associations and the
traffic between TUA peers. As well, the active/inactive and
congestion state of remote ASPs is maintained.
The TUA layer MAY be instructed by local management to establish an
SCTP association to a peer TUA node. This can be achieved using the
M-SCTP_ESTABLISH primitives to request, indicate and confirm the
establishment of an SCTP association with a peer TUA node. To avoid
redundant SCTP associations between two TUA peers, one side (client)
SHOULD be designated to establish the SCTP association, or TUA
configuration information maintained to detect redundant associations
(e.g, via knowledge of the expected local and remote SCTP endpoint
addresses).
Local management MAY request from the TUA layer the status of the
underlying SCTP associations using the M-SCTP_STATUS request and
confirm primitives. Also, the TUA MAY autonomously inform local
management of the reason for the release of an SCTP association,
determined either locally within the TUA layer or by a primitive from
the SCTP.
Also, the TUA layer MAY inform the local management of the change
in status of an ASP or AS. This MAY be achieved using the M-
ASP_STATUS request or M-AS_STATUS request primitives.
1.4. Functional Areas
1.4.1. Dialogue Identifiers, Routing Contexts and Routing Keys
The mapping of TCAP messages into dialogues between the SGP and the
Application Servers is determined by Dialogue Identifiers, Routing
Keys and their associated Routing Contexts.
A Routing Key is essentially a set of TCAP parameters used to
direct TCAP messages; whereas, the Routing Context parameter is a
4-byte value (unsigned integer) that is associated to that Routing Key
in a one-to-one relationship. The Routing Context therefore can be
viewed as an index into a sending node's Transaction Mapping Function
tables containing the Routing Key entries.
B. Bidulock Version 0.2 Page 9
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
Possible TCAP address/routing information that comprise a Routing
Key entry includes, for example, a local and remote Point Code,
Subsystem Number, Global Title Address, Application Context, local and
remote Transaction Id pairs, or TC-User specific information such as
User Information, IMSI, SLP. The particular information used to
define a TUA Routing Key is application and network dependent, and
none of the above examples are requirements for TUA.
An Application Server Process (ASP) may be configured to process
signalling traffic related to more than one Application Server (AS),
over a single SCTP Association. ASP Active (ASPAC) and ASP Inactive
(ASPIA) management messages (see Section 3) use the Routing Context to
discriminate signalling traffic to be started or stopped. At an ASP,
the Routing Context parameter uniquely identifies the range of
signalling traffic associated with each Application Server that the
ASP is configured to receive.
1.4.2. Routing Key Limitations
Routing Keys SHOULD be unique in the sense that each received TCAP
message SHOULD have a full or partial match to a single routing
result. It is not necessary for the parameter range values within a
particular Routing Key to be continuous. For example, an AS could be
configured to support transaction processing for multiple ranges of
subscribers that are not represented by contiguous Global Title
Addresses.
1.4.3. Managing Routing Context and Routing Keys
There are two ways to provision a Routing Key at an SGP. A Routing
Key may be configured statically using an implementation dependent
management interface, or dynamically managed using the the TUA Routing
Key registration procedures.
When using a management interface to configure Routing Keys, the
Transaction Mapping Function within the SGP is not limited to the set
of parameters defined in this document. Other implementation
dependent distribution algorithms may be used.
1.4.4. Transaction Mapping Function
To perform its addressing and relaying capabilities, the TUA makes
use of an Transaction Mapping Function (TMF). This function is
considered part of TUA, but the way it is realized is left
implementation or deployment dependent (local tables, SCCP GTT
database, DNS [RFC 2916], LDAP, etc.)
The TMF is invoked when a message is received at the incoming
interface. The TMF is responsible for resolving the application
context, address and transaction ids presented in the incoming TCAP
message to SCTP associations and destinations within the IP network.
The TMF will select the key information available. The Routing Keys
reference an Application Server, which will normally have one or more
ASPs processing transactions for the AS. The availability and status
B. Bidulock Version 0.2 Page 10
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
of the ASPs is handled by TUA ASP management messages.
Possible SS7 application context, address or routing information
that comprise a Routing Key entry includes, for example, SCCP
subsystem number and SCCP addresses and Global Title addresses,
Transaction ID, and Application Context.
It is expected that the routing keys will be provisioned via a MIB,
dynamic registration or an external process, such as a database.
1.4.4.1. Transaction Mapping at the SG
To direct messages received from the SS7 network to the appropriate
IP destination, the SGP must perform a transaction mapping function
using information from the received TCAP message.
To support this transaction mapping, the SGP might, for example,
maintain the equivalent of a network address translation table,
mapping incoming TCAP message information to an Application Server for
a particular application and set of transactions. This could be
accomplished by comparing the addressing, dialog or component portions
of the incoming TCAP message to currently defined Routing Keys in the
SGP. These Routing Keys could in turn map directly to an Application
Server that is enabled by one or more ASPs. These ASPs proxy dynamic
status information regarding their availability, transaction handling
capabilities and congestion to the SGP using various management
messages defined in the TUA protocol.
The list of ASPs in the AS is assumed to be dynamic, taking into
account the availability, transaction handling capability and
congestion status of the individual ASPs in the list, as well as
configuration changes and possible fail-over mechanisms.
Normally, one or more ASPs are active in the AS (i.e, currently
processing transactions) but in certain failure and transition cases
it is possible that there may not be an active ASP available. The SGP
will buffer the message destined for this AS for a time T(r) or until
an ASP becomes available. When no ASP becomes available before expiry
of T(r), the SGP will flush the buffered messages and initiate the
appropriate TCAP abort procedures.
If there is no transaction mapping function match for an incoming
message, a default treatment MAY be specified. Possible solutions are
to provide a default Application Server to direct all unallocated
transactions to a (set of) default ASP(s), or to drop the messages and
provide a notification to management. The treatment of unallocated
transactions is implementation dependent.
1.4.4.2. Transaction Mapping at the ASP
To direct messages to the SS7 network, the ASP MAY perform a
transaction mapping to choose the proper SGP for the given message.
This is accomplished by observing the Application Context, Destination
Address, Destination Transaction Id, and other elements of the
B. Bidulock Version 0.2 Page 11
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
outgoing message, SS7 network status, SGP availability, and Routing
Context configuration tables.
A Signalling Gateway may be composed of one or more SGPs [2].
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.
In general, an ASP routes all responses to the SGP that it received
messages from; within the routing context which it is currently active
and receiving transactions. The ASP uses the routing context to
select the SGP.
1.4.5. Signalling Gateway SS7 Layers
The SG is responsible for terminating up to the TC-user of the SS7
protocol, and offering an IP-based extension to its users.
From an SS7 perspective, it is expected that the Signalling Gateway
transmits and receives TCAP messages to and from the SS7 Network over
standard SS7 network interfaces, using the services of the SCCP
[Q.711] and MTP [Q.704] to provide transport of the messages.
Note that it is also possible for the SCCP services to be provided
using the services of the SCCP-User Adaptation Layer (SUA) [SUA] and
the MTP3-User Adaptation Layer (M3UA) [M3UA].
The TC-SAP through which TUA at the SG obtains its services could
reside at a Signalling Transfer Point (STP) or Signalling End Point
(SEP) [Q.705].
1.4.6. SS7 and TUA Interworking at the SG
The SGP provides a functional interworking of transport functions
between the SS7 network and the IP network by also supporting the TUA
adaptation layer. It allows the TCAP application to exchange
components in dialogues with an IP-based Application Server Process
where the peer TC-User protocol layer exists.
To perform TCAP management, it is required that the TC-User
protocols at ASPs receive indications of subsystem availability and
congestion, as well as user part availability and signalling point
availability and congestion as they would be expected by an SS7 TCAP
application. To accomplish this, the N-PCSTATE, N-STATE and N-COORD
primitives received at the TCAP upper layer interface at the SG need
to be propagated to the remote TC-user lower layer interface at the
ASP.
SCCP management messages (such as SSP, SSA) and MTP management
messages (such as TFP, TFA) received from the SS7 network MUST NOT be
encapsulated. The SG MUST terminate these messages and generate TUA
message as appropriate.
B. Bidulock Version 0.2 Page 12
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
1.4.7. Application Server
A cluster of Application Servers is responsible for providing the
overall support for one ore more SS7 upper layers. From an TCAP
standpoint, an Application Part provides complete support for the
upper layer service within a given Application Context. As an
example, an Application Part providing HLR capabilities could provide
complete support for GSM MAP HLR (and any other, MSC or VLR
application parts located at the signalling point) for a given point
code.
Where an ASP is connected to more than one SG, the TUA layer must
maintain the status of configured SS7 destinations and route messages
according to the availability/congestion status of potentially
replicated subsystem.
1.4.8. SCTP Stream Mapping
The TUA supports SCTP streams. The SG and AS need to maintain a
list of SCTP and TC-Users for mapping purposes. TC-Users requiring
sequenced message transfer need to be sent over a stream using
sequenced delivery.
TUA SHOULD NOT use stream 0 for TUA management messages. It is
OPTIONAL that sequence delivery be used to preserve the order of
management message delivery.
All TUA Dialogue Handling (DH) messages not using the optional
component handling interface (i.e, DH messages with components
included) MAY select unordered delivery, depending on the requirements
of the TC-User [3]. All TUA Component Handling (CH) messages and
Dialogue Handling (DH) messages with external components SHOULD select
ordered delivery.
The stream selected is based upon the Sequence Control field in the
Quality of Service parameter, the Dialogue Id given by the TC-User
over the primitive interface and other traffic information available
to the SGP or ASP.
1.4.9. Application Server Redundancy
All TQRY and SSNM messages (e.g, TC-BEGIN, N-STATE) which match a
provisioned Routing Key at an SGP are mapped to an Application Server.
The Application Server is the set of all ASPs associated with a
specific Routing Key. Each ASP in this set may be active, inactive or
unavailable. Active ASPs handle traffic; inactive ASPs might be used
when active ASPs become unavailable.
The fail-over model supports an "n+k" redundancy model, where "n"
ASPs is the minimum number of redundant ASPs required to handle
traffic and "k" ASPs are available to take over for a failed or
available ASP. A "1+1" active/backup redundancy is a subset of this
model. A simplex "1+0" model is also supported as a subset, with no
B. Bidulock Version 0.2 Page 13
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
ASP redundancy.
1.4.10. Flow Control
Local Management at an ASP may wish to stop traffic across an SCTP
association to temporarily remove the association from service or to
perform testing and maintenance activity. The function could
optionally be used to control the start of traffic onto a newly
available SCTP association.
1.4.11. Congestion Management
The TUA layer is informed of local and IP network congestion by
means of an implementation-dependent function (e.g, an implementation-
dependent indication from the SCTP of IP network congestion).
At an ASP or IPSP, the TUA layer indicates congestion to local TC-
users by means of an appropriate TCAP primitive (N-PCSTATE, N-STATE,
TC-NOTICE), as per current TCAP procedures, to invoke appropriate
upper layer responses. When an SG determines that the transport of
SS7 messages is encountering congestion, the SG might trigger SS7
Congestion messages to originating SS7 nodes, per the congestion
procedures of the relevant SCCP [Q.711, T1.112] or MTP [T1.111, Q.704]
standard. (The triggering of SS7 Management messages from an SG is an
implementation-dependent function.)
1.5. Definition of TUA Boundaries
TUA has three protocol boundaries: an upper boundary between TUA
and the TC-User; a lower boundary between TUA and SCTP; and a layer
management boundary between TUA and the Layer Management Function.
Figure 3 illustrates the TUA protocol boundaries.
...........
: TC-User :
:.........: Layer
Upper Boundary : Management
____:____ Boundary ............
| TUA |.............: LM :
|_________| :..........:
Lower Boundary :
.....:.....
: SCTP :
:.........:
Figure 3. TUA Protocol Boundaries
1.5.1. Definition of Upper Boundary
The primitives and messages listed in Table 2 are provided between
the TUA and TC-User in support of Dialogue Handling [Q.771, T1.114].
B. Bidulock Version 0.2 Page 14
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
Table 2. Mapping of Dialogue Handling Primitives
+--------------+------------+-------------+----------------+------+
|Generic | Specific | ITU-T Q.771 | ANSI T1.114 | TUA |
|Name | Name | Reference | Message | Msg |
+--------------+------------+-------------+----------------+------+
|TC-UNI | Request | 3.1.2.2.1 | Unidirectional | TUNI |
| | Indication | | | |
+--------------+------------+-------------+----------------+------+
|TC-BEGIN | Request | 3.1.2.2.2.1 | Query w/ Perm | |
| | Indication | | | TQRY |
+--------------+------------+-------------+----------------+ |
|------------- | ---------- | ----------- | Query w/o Perm | |
+--------------+------------+-------------+----------------+------+
|TC-CONTINUE | Request | 3.1.2.2.2.2 | | |
|(Initial) | Indication | | | |
+--------------+------------+-------------+ Conv w/ Perm | |
|TC-CONTINUE | Request | 3.1.2.2.2.3 | | TCNV |
|(Non-initial) | Indication | | | |
+--------------+------------+-------------+----------------+ |
|------------- | ---------- | ----------- | Conv w/o Perm | |
+--------------+------------+-------------+----------------+------+
|TC-END | Request | | Response | TRSP |
| | Indication | | | |
+--------------+------------+ 3.1.2.2.2.4 +----------------+------+
|TC-U-ABORT | Request | | U-Abort | TUAB |
| | Indication | | | |
+--------------+------------+-------------+----------------+------+
|TC-P-ABORT | Indication | 3.1.4.2 | P-Abort | TPAB |
+--------------+------------+-------------+----------------+------+
|TC-NOTICE | Indication | 3.1.2.2.3 | -------------- | TNOT |
+--------------+------------+-------------+----------------+------+
The primitives and messages listed in Table 3 are provided between
the TUA and TC-User in OPTIONAL support of Component Handling [Q.771,
T1.114].
B. Bidulock Version 0.2 Page 15
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
Table 3. Mapping of Component Handling Primitives
+-------------+------------+-------------+---------------+------+
|Generic | Specific | ITU-T Q.771 | ANSI T1.114 | TUA |
|Name | Name | Reference | Message | Msg |
+-------------+------------+-------------+---------------+------+
|TC-INVOKE | Request | 3.1.3.2 | Invoke L | |
| | Indication | | | CINV |
+-------------+------------+-------------+---------------+ |
|------------ | ---------- | ----------- | Invoke NL | |
+-------------+------------+-------------+---------------+------+
|TC-RESULT-L | Request | 3.1.3.3 | Ret Result L | CRES |
|TC-RESULT-NL | Indication | | Ret Result NL | |
+-------------+------------+-------------+---------------+------+
|TC-U-ERROR | Request | 3.1.3.4 | Ret Error | CERR |
| | Indication | | | |
+-------------+------------+-------------+---------------+------+
|TC-U-REJECT | Request | 3.1.3.5 | | |
| | Indication | | | |
+-------------+------------+-------------+ | |
|TC-L-REJECT | Request | | Reject | CREJ |
| | Indication | | | |
+-------------+------------+ 3.1.4.1 | | |
|TC-R-REJECT | Request | | | |
| | Indication | | | |
+-------------+------------+-------------+---------------+------+
|TC-U-CANCEL | Request | 3.1.3.6 | | CCAN |
|TC-L-CANCEL | Indication | | ------------- | |
+-------------+------------+-------------+---------------+------+
1.5.2. Definition of Boundary between TUA and Layer Management
M-SCTP_ESTABLISH request
Direction: LM->TUA
Purpose: LM request ASP to establish an SCTP association with its
peer.
M-SCTP_ESTABLISH confirm
Direction: TUA -> LM
Purpose: ASP confirms to LM that it has established an SCTP
association with its peer.
M-SCTP_ESTABLISH indication
Direction: TUA -> LM
Purpose: TUA informs LM that a remote ASP has established an SCTP
association.
M-SCTP_RELEASE request
Direction: LM -> TUA
B. Bidulock Version 0.2 Page 16
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
Purpose: LM requests ASP to release an SCTP association with its
peer.
M-SCTP_RELEASE confirm
Direction: TUA -> LM
Purpose: ASP confirms to LM that it has released SCTP association
with its peer.
M-SCTP_RELEASE indication
Direction: TUA -> LM
Purpose: TUA informs LM that a remote ASP has released an SCTP
Association or the SCTP association has failed.
M-SCTP RESTART indication
Direction: TUA -> LM
Purpose: TUA informs LM that an SCTP restart indication has been
received.
M-SCTP_STATUS request
Direction: LM -> TUA
Purpose: LM requests TUA to report the status of an SCTP
association.
M-SCTP_STATUS confirm
Direction: TUA -> LM
Purpose: TUA responds with the status of an SCTP association.
M-SCTP_STATUS indication
Direction: TUA -> LM
Purpose: TUA reports the status of an SCTP association.
M-ASP_STATUS request
Direction: LM -> TUA
Purpose: LM requests TUA to report the status of a local or remote
ASP.
M-ASP_STATUS confirm
Direction: TUA -> LM
Purpose: TUA reports status of local or remote ASP.
M-AS_STATUS request
Direction: LM -> TUA
Purpose: LM requests TUA to report the status of an AS.
M-AS_STATUS confirm
Direction: TUA -> LM
Purpose: TUA reports the status of an AS.
M-NOTIFY indication
Direction: TUA -> LM
Purpose: TUA reports that it has received a Notify (NTFY) message
from its peer.
B. Bidulock Version 0.2 Page 17
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
M-ERROR indication
Direction: TUA -> LM
Purpose: TUA reports that it has received an Error (ERR) message
from its peer or that a local operation has been
unsuccessful.
M-ASP_UP request
Direction: LM -> TUA
Purpose: LM requests ASP to start its operation and send an ASP Up
(ASPUP) message to its peer.
M-ASP_UP confirm
Direction: TUA -> LM
Purpose: ASP reports that is has received an ASP UP Ack (ASPUP
ACK) message from its peer.
M-ASP_UP indication
Direction: TUA -> LM
Purpose: TUA reports it has successfully processed an incoming ASP
Up (ASPUP) message from its peer.
M-ASP_DOWN request
Direction: LM -> TUA
Purpose: LM requests ASP to stop its operation and send an ASP
Down (ASPDN) message to its peer.
M-ASP_DOWN confirm
Direction: TUA -> LM
Purpose: ASP reports that is has received an ASP Down Ack (ASPDN
ACK) message from its peer.
M-ASP_DOWN indication
Direction: TUA -> LM
Purpose: TUA reports it has successfully processed an incoming ASP
Down (ASPDN) message from its peer, or the SCTP
association has been lost or reset.
M-ASP_ACTIVE request
Direction: LM -> TUA
Purpose: LM requests ASP to send an ASP Active (ASPAC) message to
its peer.
M-ASP_ACTIVE confirm
Direction: TUA -> LM
Purpose: ASP reports that is has received an ASP Active Ack (ASPAC
ACK) message from its peer.
M-ASP_ACTIVE indication
Direction: TUA -> LM
Purpose: TUA reports it has successfully processed an incoming ASP
Active (ASPAC) message from its peer.
M-ASP_INACTIVE request
B. Bidulock Version 0.2 Page 18
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
Direction: LM -> TUA
Purpose: LM requests ASP to send an ASP Inactive (ASPIA) message
to its peer.
M-ASP_INACTIVE confirm
Direction: LM -> TUA
Purpose: ASP reports that is has received an ASP Inactive Ack
(ASPIA ACK) message from its peer.
M-ASP_INACTIVE indication
Direction: TUA -> LM
Purpose: TUA reports it has successfully processed an incoming ASP
Inactive (ASPIA) message from its peer.
M-AS_ACTIVE indication
Direction: TUA -> LM
Purpose: TUA reports that an AS has moved to the AS-ACTIVE state.
M-AS_INACTIVE indication
Direction: TUA -> LM
Purpose: UA reports that an AS has moved to the AS-INACTIVE state.
M-AS_DOWN indication
Direction: TUA -> LM
Purpose: UA reports that an AS has moved to the AS-DOWN state.
If the TUA layer supports dynamic registration of Routing Key, the
layer MAY support the following additional primitives:
M-RK_REG request
Direction: LM -> TUA
Purpose: LM requests ASP to register RK(s) with its peer by
sending Registration Request (REG REQ) message
M-RK_REG confirm
Direction: TUA -> LM
Purpose: ASP reports that it has received Registration Response
(REG RSP) message with registration status as successful
from its peer.
M-RK_REG indication
Direction: TUA -> LM
Purpose: TUA informs LM that it has successfully processed an
incoming Registration Request (REG REQ) message.
M-RK_DEREG request
Direction: LM -> TUA
Purpose: LM requests ASP to deregister RK(s) with its peer by
sending Deregistration Request (DEREG REQ) message.
B. Bidulock Version 0.2 Page 19
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
M-RK_DEREG confirm
Direction: TUA -> LM
Purpose: ASP reports that it has received Deregistration Request
(DEREG REQ) message with deregistration status as
successful from its peer.
M-RK_DEREG indication
Direction: TUA -> LM
Purpose: TUA informs LM that it has successfully processed an
incoming DEREG REQ from its peer.
1.5.3. Definition of the Lower Boundary
The upper layer primitives provided by the SCTP are provided in the
SCTP specification "Stream Control Transmission Protocol (SCTP)" [RFC
2960].
Notes for Section 1
[1] IMPLEMENTATION NOTE:- Only one SCTP port may be defined for
each endpoint, but each SCTP endpoint may have multiple IP
addresses [RFC 2960].
[2] IMPLEMENTATION NOTE:- Where more than one route (or SG) is
possible for routing to the SS7 network, the ASP could, for
example, maintain a dynamic table of available SG routes for
the SS7 destinations and subsystems, taking into account the
destination and subsystem availability and congestion status
received from the SG(s), the availability status of individual
SGs and configuration changes or fail-over mechanisms.
[3] IMPLEMENTATION NOTE:- When the TC-User selects sequenced
delivery using the "Sequence Control" fields in the Quality of
Service parameter, the DH message SHOULD be sent on an SCTP
stream using ordered delivery. When the TC-User does not
select sequenced delivery and does not utilize the optional
component handling interface (i.e. the DH message has
components included), the DH message MAY be sent on an SCTP
stream using unordered delivery.
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 [RFC
2119].
In this document, the following conventions are used to describe how a
parameter is used in the message:
B. Bidulock Version 0.2 Page 20
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
Mandatory The parameter MUST be present in the message. A
message listing a parameter as Mandatory without
containing such a parameter is is incorrectly
formatted.
Conditional The parameter SHOULD be present in the message
under the conditions specified. A message listing
a parameter as Conditional without containing such
a parameter under the conditions specified is
incorrectly formatted.
Optional The parameter MAY be present in the message as
specified. A message listing a parameter as
Optional without containing such a parameter is
correctly formatted.
3. Protocol Elements
The general message format includes a Common Message Header
together with a list of zero or more parameters as defined by the
Message Type.
For forward compatibility, all Message Types MAY have attached
parameters even if none are specified in this version.
3.1. Common Message Header
The protocol messages for the TCAP-User Adaptation Protocol (TUA)
require a message structure that contains a version, message type,
message length and message contents:
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 |
+---------------------------------------------------------------+
| Message Data |
Notes:
+ This message header is common among all signalling protocol
adaptation layers.
+ The 'data' portion of TUA messages SHALL contain zero or more TUA
parameters, and SHALL NOT contain an encapsulated TCAP message.
+ Optional parameters can only occur at most once in a TUA message.
+ All fields in the TUA message MUST be transmitted in the network
byte order, unless otherwise stated.
+ The Reserved field is set to 0 in messages sent and is not examined
in messages received.
B. Bidulock Version 0.2 Page 21
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
3.1.1. TUA Protocol Version
Version: 8-bits (unsigned integer)
The Version field of the Common Message Header contains the version
of the TUA adaptation layer. The supported versions are:
1 - TUA Version 1.0
3.1.2. Message Classes
Message Class: 8-bits (unsigned integer)
The Message Class field of the Common Message Header contains the
class of the message. The supported classes are as follows:
0 Management (MGMT) Message
7 Reserved for Other Signalling Adaptation Layers
2 SS7 Signalling Network Management (SSNM) Messages
3 ASP State Maintenance (ASPSM) Messages
4 ASP Traffic Maintenance (ASPTM) Messages
5 TUA Dialogue Handling (DH) Messages
6 TUA Component Handling (CH) Messages
7 Reserved for Other Signalling Adaptation Layers
8 Reserved for Other Signalling Adaptation Layers
9 Routing key Management (RKM) Messages
10 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
3.1.3. Message Types
Message Type: 8-bits (unsigned integer)
The Message Type field of the Common Message Header contains the
type of message within a message class. The supported types of
messages within the supported classes are as follows:
Management (MGMT) Messages
0 Error (ERR)
1 Notify (NTFY)
2 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
SS7 Signalling Network Management (SSNM) Messages
0 Reserved
1 Destination Unavailable (DUNA)
2 Destination Available (DAVA)
3 Destination State Audit (DAUD)
4 Destination Congestion (SCON)
B. Bidulock Version 0.2 Page 22
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
5 Destination User Part Unavailable (DUPU)
6 Destination Restricted (DRST)
7 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
Application Server Process State Maintenance (ASPSM) Messages
0 Reserved
1 ASP Up (UP)
2 ASP Down (DOWN)
3 Heartbeat (BEAT)
4 ASP Up Ack (UP ACK)
5 ASP Down Ack (DOWN ACK)
6 Heartbeat Ack (BEAT ACK)
7 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
Application Server Process Traffic Maintenance (ASPTM) Messages
0 Reserved
1 ASP Active (ASPAC)
2 ASP Inactive (ASPIA)
3 ASP Active Ack (ASPAC ACK)
4 ASP Inactive Ack (ASPIA ACK)
5 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
Routing Key Management (RKM) Messages
0 Reserved
1 Registration Request (REG REQ)
2 Registration Response (REG RSP)
3 Deregistration Request (DEREG REQ)
4 Deregistration Response (DEREG RSP)
5 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
TUA Dialogue Handling (DH) Messages
0 Unidirectional(TUNI)
1 Query (TQRY)
2 Conversation (TCNV)
3 Response (TRSP)
4 U-Abort (TUAB)
5 P-Abort (TPAB)
6 Notice (TNOT)
7 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
TUA Component Handling (CH) Messages
1 Invoke (CINV)
2 Result (CRES)
3 Error (CERR)
4 Reject (CREJ)
5 Cancel (CCAN)
6 - 127 Reserved by the IETF
128 - 255 Reserved for IETF-Defined Message Class Extensions
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
3.1.4. Message Length
Message Length: 32-bits (unsigned integer)
The Message Length field of the Common Message Header defines the
length of the message in octets, including the header.
3.1.5. Tag-Length-Value Format
TUA messages consist of a Common Message 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 [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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Tag | Parameter Length |
+-------------------------------+-------------------------------+
\ \
/ Parameter Value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Tag: 16-bits (unsigned integer)
The Parameter Tag field is a 16-bit identifier of the type of
parameter. It takes a value of 0 to 65534.
Parameter Length: 16-bits (unsigned integer)
The Parameter Length field contains the size of the parameter in
bytes, including the Parameter Tag, Parameter Length, and Parameter
Value fields. The Parameter Length does not include any padding
bytes. However, composite parameters will contain all padding
bytes, since all parameters contained within this composite
parameter will considered multiples of 4 bytes.
Parameter Value: variable-length
The Parameter Value field contains the actual information to be
transferred in the parameter. The total length of a parameter
(including Tag, Parameter Length and Value fields) MUST be a
multiple of 4 bytes. If the length of the parameter is not a
multiple of 4 bytes, the sender MUST pad the Parameter at the end
(i.e., after the Parameter Value field) with all zero bytes. The
length of the padding MUST NOT be included in the parameter length
field. A sender SHOULD NOT pad with more than 3 bytes. The
receiver MUST ignore the padding bytes.
3.2. TUA Message Header
In addition to the Common Message Header, a specific message header
is included for TUA messages. The TUA message header will immediately
follow the Common Message Header in TUA Dialogue Handling (DH) and
Component Handling (CH) messages.
B. Bidulock Version 0.2 Page 24
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
The TUA Message Header is formatted 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 = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Routing Context |
+-------------------------------+-------------------------------+
| Tag = 0x0013 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Correlation Id |
+-------------------------------+-------------------------------+
| Tag = 0x0401 | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Dialogue Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The TUA Message header can contain the following parameters:
Parameters
---------------------------------------------
Routing Context Conditional *1
Correlation Id Conditional *2
Dialogue Id Conditional *3
Note 1: When an ASP is registered or configured for multiple AS with
an SG, the Routing Context MUST be present in the TUA Message
Header. The Routing Context SHOULD always be placed in the
TUA Message Header. When the Routing Context is present in
the TUA Message Header it SHOULD be placed first in the header
because the context of the Dialogue Id depends on the Routing
Context.
Note 2: Under some circumstances, the Correlation Id parameter MUST be
included in the TUA Message Header. See sections "Correlation
Id" and "ASP Active Procedures".
Note 3: When an AS is handling multiple Dialogues, the Dialogue Id
parameter MUST be placed in the TUA Message Header. The
Dialogue Id parameter SHOULD always be placed in the TUA
Message Header. The Dialogue Id parameter MAY be excluded
from the TUA header for TUNI and TPAB DH messages, or may be
included but then MUST contain a value of zero.
3.3. TUA Dialogue Handling (DH) Messages
The following section describes the TUA Dialogue Handling (DH)
messages and parameter contents. The general message format includes
a Common Message Header, the TUA Message Header and the DH Message
Header, together with a list of zero or more parameters as defined by
B. Bidulock Version 0.2 Page 25
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
the Message Type. For forward compatibility, all Message Types MAY
have optional attached parameters in addition to the message headers.
3.3.1. DH Message Header
In addition to the Common Message Header and TUA Message Header, a
specific message header is included for TUA Dialogue Handling (DH)
messages. The DH Message Header will immediately follow the TUA
Message header in these messages.
The DH Message Header is formatted 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 = 0x0402 | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Dialogue Flags |
+-------------------------------+-------------------------------+
| Tag = 0x0403 | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Quality of Service |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The DH Message header contains the following parameters:
Parameters
------------------------------------------
Dialogue Flags Mandatory
Quality of Service Mandatory
3.3.2. Unidirectional (TUNI)
The Unidirectional (TUNI) Request message is sent from an ASP to an
SG or IPSP to invoke a TCAP class 4 operation. The TUNI Indication
message is sent from an SGP to an ASP to indicate the TCAP class 4
operation.
The TUNI message corresponds to the ITU-T `TC-UNI' primitive
[Q.771], and the ITU-T and ANSI `Unidirectional' message [T1.114,
Q.773].
The TUNI message is formatted as follows:
B. Bidulock Version 0.2 Page 26
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
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 = 0x0404 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Destination Address /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x0405 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Originating Address /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x0406 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Application Context Name /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x0407 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ User Information /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x0408 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Security Context /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x0409 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Confidentiality /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x040E | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Components /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The TUNI message can contain the following parameters:
Parameters
---------------------------------------------
B. Bidulock Version 0.2 Page 27
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
Destination Address Conditional *1
Originating Address Conditional *1
Application Context Name Optional
User Information Optional
Security Context Optional
Confidentiality Optional
Components Optional *2
Note 1: The Destination Address or Originating Address parameter MUST
be present in the TUNI message when either parameter is not
implied by the Routing Context in the TUA Message Header.
Note 2: Any components SHOULD be included in the TUNI messages but MAY
be formatted in separate TUA Component Handling (CH) messages.
3.3.3. Query (TQRY)
The Query (TQRY) message is sent to a TUA peer to begin a new
dialogue between TC-Users.
The TQRY message corresponds to the ITU-T `TC-BEGIN' primitive
[Q.771], the ITU-T `Begin' message [Q.773] and the ANSI `Query'
message [T1.114].
The TQRY message is formatted as follows:
B. Bidulock Version 0.2 Page 28
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
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 = 0x0410 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Transaction Id |
+-------------------------------+-------------------------------+
| Tag = 0x0404 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Destination Address /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x0405 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Originating Address /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x0406 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Application Context Name /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x0407 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ User Information /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x0408 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Security Context /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x0409 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Confidentiality /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x040E | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Components /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The TQRY message can contain the following parameters:
B. Bidulock Version 0.2 Page 29
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
Parameters
---------------------------------------------
Transaction Id Mandatory
Destination Address Conditional *1
Originating Address Conditional *1
Application Context Name Optional
User Information Optional
Security Context Optional
Confidentiality Optional
Components Optional *2
Note 1: The Destination Address or Originating Address parameter MUST
be present in the TQRY message when the parameter is not
implied by the Routing Context in the TUA Message Header.
Note 2: Any components SHOULD be included in the TQRY messages but MAY
be formatted in separate Component Handling (CH) messages.
3.3.4. Conversation (TCNV)
The Conversation (TCNV) message is used in response to a TQRY
message or another TCNV message.
When sent in response to a TQRY message, the TCNV message confirms
and continues a dialogue; when in response to a received TCNV message,
it only continues a dialogue. The Dialogue Flags in the DH Message
Header indicate whether the initiator of the TCNV message give
permission to the peer to terminate the dialogue.
The TCNV message corresponds to the ITU-T `TC-CONTINUE' primitive
[Q.771], ITU-T `Continue' message [Q.773] and the ANSI `Conversation'
message [T1.114].
The TCNV message is formatted as follows:
B. Bidulock Version 0.2 Page 30
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
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 = 0x0410 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Transaction Id |
+-------------------------------+-------------------------------+
| Tag = 0x0405 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Originating Address /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x0406 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Application Context Name /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x0407 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ User Information /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x0408 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Security Context /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x0409 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Confidentiality /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x040E | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Components /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The TCNV message can contain the following parameters:
Parameters
---------------------------------------------
Transaction Id Conditional *1
Originating Address Conditional *2
B. Bidulock Version 0.2 Page 31
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
Application Context Name Conditional *3
User Information Conditional *3
Security Context Conditional *3
Confidentiality Conditional *3
Components Optional *4
Note 1: The Transaction Id parameter MUST be present in the TCNV
message when the message is sent in response to a TQUR
message. The Transaction Id parameter contains the
Transaction Identifier assigned by the remote TC-User.
Note 2: The Originating Address parameter MUST be present in the TCNV
message when the message is used in response to a TQRY message
and the parameter is not implied by the Routing Context in the
TUA Message Header.
Note 3: These dialogue portion parameters SHOULD only be optionally
included in the TCNV message when the message is used in
response to a TQRY message. When the TCNV message is sent in
response to a received TCNV message, these parameters SHOULD
NOT be included in the responding TCNV message.
Note 4: Any components SHOULD be included in the TCNV messages but MAY
be formatted in separate Component Handling (CH) messages.
3.3.5. Response (TRSP)
The Response (TRSP) message is used in response to a TQRY message
or TCNV message to complete and existing dialogue.
When sent in response to a TQRY message, the TRSP message confirms
and completes a dialogue; when in response to a received TCNV message,
it only terminates a dialogue.
The TRSP message corresponds to the ITU-T `TC-END' primitive
[Q.771], ITU-T `End' message [Q.773] and the ANSI `Response' message
[T1.114].
The TRSP message is formatted as follows:
B. Bidulock Version 0.2 Page 32
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
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 = 0x040A | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Termination |
+-------------------------------+-------------------------------+
| Tag = 0x0406 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Application Context Name /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x0407 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ User Information /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x0408 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Security Context /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x0409 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Confidentiality /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x040E | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Components /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The TRSP message can contain the following parameters:
Parameters
-------------------------------------------
Termination Mandatory
Application Context Name Optional *1
User Information Optional *1
Security Context Optional *1
Confidentiality Optional *1
Components Optional *2
Note 1: These dialogue portion parameters SHOULD only be optionally
included in the TRSP message when it is issued in response to
B. Bidulock Version 0.2 Page 33
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
an TQRY message. When the TRSP message is in response to a
TCNV message, the dialogue portion parameters SHOULD NOT be
included in the TRSP message.
Note 2: Any components SHOULD be included in the TRSP messages but MAY
be formatted in separate TUA Component Handling (CH) messages.
3.3.6. U-Abort (TUAB)
The TUA peer sends an U-Abort (TUAB) message when it wishes to
abort a dialogue, either under TUA-user control (TC-U-ABORT).
When sent in response to a TQRY message, the TUAB message
negatively confirms and aborts a dialogue; when in response to a
received TCNV message, it only aborts a dialogue.
The TUAB message corresponds to the ITU-T `TC-U-ABORT' primitive
[Q.771], the ITU-T `Abort' message [Q.773] and the ANSI `Abort'
message [T1.114].
The TUAB message is formatted 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 = 0x040D | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Abort Reason |
+-------------------------------+-------------------------------+
| Tag = 0x0405 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Originating Address /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x0406 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Application Context Name /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x0407 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ User Information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The TUAB message can contain the following parameters:
B. Bidulock Version 0.2 Page 34
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
Parameters
---------------------------------------------
Abort Reason Mandatory
Application Context Name Conditional *1
User Information Optional *2
Note 1: These dialogue portion parameters SHOULD only be optionally
included in the TUAB message when it is issued in response to
an TQRY message. When the TUAB message is in response to a
TCNV message, the dialogue portion parameters SHOULD NOT be
included in the TUAB message.
Note 2: The User Information parameter carries any User Abort
Information.
3.3.7. P-Abort (TPAB)
The TUA peer sends an P-Abort (TPAB) message when it wishes to
abort a dialogue, either under TUA control (TC-P-ABORT).
The TPAB message corresponds to the ITU-T `TC-P-ABORT' primitive
[Q.771], the ITU-T `Abort' message [Q.773] and the ANSI `Abort'
message [T1.114].
The TPAB message is formatted 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 = 0x040B | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Abort Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The TPAB message can contain the following parameters:
Parameters
------------------------------------------
Abort Cause Mandatory
3.3.8. Notice (TNOT)
An SG sends a Notice (TNOT) message when it wishes to inform the
ASP of a network condition that concerns the transmission of TCAP or
TUA messages to the remote TC-User in a dialogue [Q.775]. It is used
at the SG when an SCCP message containing TC-User information from an
AS has been returned in a UDTS when the "Return Option" flag was set
in the Quality of Service parameters when the message was sent.
B. Bidulock Version 0.2 Page 35
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
The TNOT message corresponds to the ITU-T [Q.771] TC-NOTICE
primitive.
The TNOT message is formatted 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 = 0x040C | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Report Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The TNOT message can contain the following parameters:
Parameters
------------------------------------------
Report cause Mandatory
3.4. TUA Component Handling (CH) Messages
The following section describes the TUA Component Handling messages
and parameter contents. The general message format includes a Common
Message Header, a TUA Message Header, a CH Message Header, followed by
a list of zero or more parameters as defined by the Message Type. For
forward compatibility, all Message Types MAY have attached optional
parameters in addition to the message headers.
Component Handling (CH) messages are used to convey components
associated with operations within a dialogue. They are issued prior
to the Dialogue Handling (DH) message with which they are associated,
but are received after receiving a Dialogue Handling (DH) message that
has the "Components Present" bit set in the Dialogue Flags parameter
within the DH message.
3.4.1. CH Message Header
In addition to the Common Message Header and TUA Message Header, a
specific message header is included for TUA Component Handling (CH)
messages. The CH Message Header will immediately follow the TUA
Message Header in these messages.
The CH Message Header if formatted as follows:
B. Bidulock Version 0.2 Page 36
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
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 = 0x0411 | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Invoke Id |
+-------------------------------+-------------------------------+
| Tag = 0x0412 | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Linked Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CH Message Header can contain the following parameters:
Parameters
------------------------------------------
Invoke Id Mandatory
Linked Id Optional
3.4.2. Invoke (CINV)
The Invoke (CINV) message is used to invoke an operation within a
dialogue.
The CINV message corresponds to the ITU-T `TC-INVOKE' primitive
[Q.771], the ITU-T `Invoke' component [Q.773], and the ANSI `Invoke
(Last)' and `Invoke (Not Last)' components [T1.114].
The CINV message is formatted as follows:
B. Bidulock Version 0.2 Page 37
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
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 = 0x0413 | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Component Flags |
+-------------------------------+-------------------------------+
| Tag = 0x0418 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Timeout |
+-------------------------------+-------------------------------+
| Tag = 0x0414 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Operation /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x0415 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CINV message can contain the following parameters:
Parameters
-------------------------------------------
Component Flags Mandatory *1
Timeout Mandatory
Operation Mandatory
Parameters Optional
Note 1: The Component Flags parameter MAY be ignored by the receiver
of the CINV message for ITU-T protocol variants of TC-Users
that do not support the concept of a "Not Last" TC-INVOKE
primitive.
3.4.3. Result (CRES)
The Result (CRES) message is used to report the successful
completion of an operation within a dialogue.
The CRES message corresponds to the ITU-T `TC-RESULT-L' and `TC-
RESULT-NL' primitives [Q.771], the ITU-T `Return Result (Last)' and
`Return Result (Not Last)' components [Q.773] and the ANSI `Return
Result (Last)' and `Return Result (Not Last)' components.
The CRES message is formatted as follows:
B. Bidulock Version 0.2 Page 38
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
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 = 0x0413 | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Component Flags |
+-------------------------------+-------------------------------+
| Tag = 0x0414 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Operation /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x0415 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CRES message can contain the following parameters:
Parameters
---------------------------------------------
Component Flags Mandatory
Operation Conditional *1
Parameters Optional
Note 1: The Operation parameter MUST be present in the CRES message
when the Parameters parameter is also present.
3.4.4. Error (CERR)
The Error (CERR) message is used to report the failure of an
operation within a dialogue.
The CERR message corresponds to the ITU-T `TC-U-ERROR' primitive
[Q.771], the ITU-T `Return Error' component [Q.773] and the ANSI
`Return Error' component [T1.114].
The CERR message is formatted as follows:
B. Bidulock Version 0.2 Page 39
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
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 = 0x0416 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Error /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x0415 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CERR message can contain the following parameters:
Parameters
---------------------------------------------
Error Mandatory
Parameters Conditional *1
Note 1: The Parameters parameter is only included in the message for
specific error codes.
3.4.5. Reject (CREJ)
The Reject (CREJ) message is used to reject an operation within a
dialogue.
The CREJ message corresponds to the ITU-T `TC-L-REJECT', `TC-R-
REJECT' and `TC-U-REJECT' primitives [Q.771], the ITU-T `Reject'
component [Q.773] and the ANSI `Reject' component [T1.114].
The CREJ message is formatted 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 = 0x0417 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Problem Code /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CREJ message can contain the following parameters:
Parameters
------------------------------------------
Problem Code Mandatory
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
3.4.6. Cancel (CCAN)
The Cancel (CCAN) message is used to cancel an operation within a
dialogue.i
The CCAN message corresponds to the ITU-T `TC-L-CANCEL' and `TC-U-
CANCEL' primitives [Q.771].
The CCAN message presently contains no Message-Type-specific
parameters.
3.5. SS7 Signalling Network Management (SSNM) Messages
SS7 Signalling Network Management (SSNM) Messages are used to
convey network management information to the TC-User. Theses messages
correspond to specific N-STATE, N-PCSTATE and N-COORD primitives.
3.5.1. Destination Unavailable (DUNA)
The Destination Unavailable (DUNA) message is sent from an SGP to
all concerned ASPs to indicate the unavailability of an SS7 SCCP
subsystem or signalling point. The TC-User at the ASP is expected to
stop traffic to TC-User peers at the affected subsystems or signalling
points via the SG initiating the DUNA message.
When the DUNA message contains the Subsystem Number parameter, the
message corresponds to the ITU-T [Q.711] and ANSI [T1.112] `N-STATE'
primitive. When the DUNA message does not contain the Subsystem
Number parameter, message, the message corresponds to the ITU-T
[Q.711] and ANSI [T1.112] `N-PCSTATE' primitive.
The DUNA message is formatted as follows:
B. Bidulock Version 0.2 Page 41
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
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 = 0x0012 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Affected Point Code /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x0419 | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Subsystem Number |
+-------------------------------+-------------------------------+
| Tag = 0x041A | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Subsystem Multiplicity Indicator |
+-------------------------------+-------------------------------+
| Tag = 0x0004 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The DUNA message can contain the following parameters:
Parameters
----------------------------------------------------
Routing Context Mandatory
Affected Point Code Mandatory
Subsystem Number Conditional *1
Subsystem Multiplicity Indicator Optional *2
Info String Optional
Note 1: The Subsystem Number parameter SHALL be present in the DUNA
message when indicating the unavailability of a subsystem, and
SHALL NOT be present when indicating the unavailability of a
signalling point.
Note 2: The Subsystem Multiplicity Indicator parameter SHOULD NOT be
present in the DUNA message when the Subsystem Number
parameter is not also present.
B. Bidulock Version 0.2 Page 42
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
3.5.2. Destination Available (DAVA)
The Destination Available (DAVA) message is sent from an SGP to all
concerned ASPs to indicate the availability of an SS7 SCCP Subsystem
or signalling point. The TC-User at the ASP is expected to resume
traffic to TC-Users peers at the affected subsystems or signalling
points via the SG initiating the DAVA message.
When the DAVA message contains the Subsystem Number parameter, the
message corresponds to the ITU-T [Q.711] and ANSI [T1.112] `N-STATE'
primitive. When the DAVA message does not contain the Subsystem
Number parameter, message, the message corresponds to the ITU-T
[Q.711] and ANSI [T1.112] `N-PCSTATE' primitive.
The DAVA message is formatted 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 = 0x0012 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Affected Point Code /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x0419 | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Subsystem Number |
+-------------------------------+-------------------------------+
| Tag = 0x041A | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Subsystem Multiplicity Indicator |
+-------------------------------+-------------------------------+
| Tag = 0x0004 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The DAVA message can contain the following parameters:
Parameters
----------------------------------------------------
B. Bidulock Version 0.2 Page 43
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
Routing Context Mandatory
Affected Point Code Mandatory
Subsystem Number Conditional *1
Subsystem Multiplicity Indicator Optional *2
Info String Optional
Note 1: The Subsystem Number parameter SHALL be present in the DAVA
message when indicating the availability of a subsystem, and
SHALL NOT be present when indicating the availability of a
signalling point.
Note 2: The Subsystem Multiplicity Indicator parameter SHOULD NOT be
present in the DAVA message when the Subsystem Number
parameter is not also present.
3.5.3. Destination State Audit (DAUD)
The Destination State Audit (DAUD) message is sent from an ASP to
an SG to query the availability state of routes to SS7 SCCP subsystems
or signalling points. A DAUD message MAY be sent periodically after
the ASP has received a DUNA message, and until a DAVA is received for
the affected subsystem or signalling point. The DAUD message can also
be sent when an ASP recovers from isolation from the SG.
When the DAVA message contains the Subsystem Number parameter, the
message is soliciting responses that correspond to the ITU-T [Q.711]
and ANSI [T1.112] `N-STATE' primitive. When the DAVA message does not
contain the Subsystem Number parameter, message, the message
soliciting responses that correspond to the ITU-T [Q.711] and ANSI
[T1.112] `N-PCSTATE' primitive.
The DAUD message is formatted as follows:
B. Bidulock Version 0.2 Page 44
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
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 = 0x0012 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Affected Point Code /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x0419 | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Subsystem Number |
+-------------------------------+-------------------------------+
| Tag = 0x0004 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The DAUD message can contain the following parameters:
Parameters
---------------------------------------------
Routing Context Mandatory
Affected Point Code Mandatory
Subsystem Number Conditional *1
Info String Optional
Note 1: The Subsystem Number parameter SHALL be present in the DAVA
message when auditing the status of a subsystem, and SHALL NOT
be present when auditing the status of a signalling point.
3.5.4. Network Congestion (SCON)
The Network Congestion (SCON) message is sent from an SG to all
concerned ASPs to indicate that the congestion level in the SS7
network to a specified subsystem or signalling point has changed. The
TC-User at the ASP is expected to stop traffic at the indicated
importance level to TC-User peers at the affected subsystems or
signalling points via the SG initiating the SCON message.
When the SCON message contains the Subsystem Number parameter, the
message corresponds to the ITU-T [Q.711] and ANSI [T1.112] `N-STATE'
primitive. When the SCON message does not contain the Subsystem
B. Bidulock Version 0.2 Page 45
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
Number parameter, message, the message corresponds to the ITU-T
[Q.711] and ANSI [T1.112] `N-PCSTATE' primitive.
The SCON message is formatted 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 = 0x0012 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Affected Point Code /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x041B | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Congestion Level |
+-------------------------------+-------------------------------+
| Tag = 0x0419 | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Subsystem Number |
+-------------------------------+-------------------------------+
| Tag = 0x041A | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| Subsystem Multiplicity Indicator |
+-------------------------------+-------------------------------+
| Tag = 0x0004 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The SCON message can contain the following parameters:
Parameters
--------------------------------------------------
Routing Context Mandatory
Affected Point Code Mandatory
Congestion Level Mandatory
Subsystem Number Optional *1
Subsystem Multiplicity Indicator Optional *2
Info String Optional
B. Bidulock Version 0.2 Page 46
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
Note 1: The Subsystem Number parameter SHALL be present in the SCON
message when indicating the congestion of a subsystem, and
SHALL NOT be present when indicating the congestion of a
signalling point.
Note 2: The Subsystem Multiplicity Indicator parameter SHOULD NOT be
present in the SCON message when the Subsystem Number
parameter is not also present.
3.5.5. Destination User Part Unavailable (DUPU)
The Destination User Part Unavailable (DUPU) message is sent from
an SG to all concerned ASPs to indicate the unavailability of an SS7
SCCP.
The DUPU message corresponds to the ITU [Q.711] and ANSI [T1.112]
`N-PCSTATE' primitive.
The DUPU message is formatted 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 = 0x0012 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Affected Point Code /
\ \
+-------------------------------+-------------------------------+
| Tag = 0x041C | Length = 8 |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
| User/Cause |
+-------------------------------+-------------------------------+
| Tag = 0x0004 | Length |
+- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
\ \
/ Info String /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The DUPU message can contain the following parameters:
Parameters
-------------------------------------------
B. Bidulock Version 0.2 Page 47
Internet Draft SS7 TCAP-User Adaptation Layer July 26, 2003
Routing Context Mandatory
Affected Point Code Mandatory
User/Cause Mandatory *1
Info String Optional
Note 1: The User field of the )User/Cause parameter must indicate an
SCCP MTP-User part and can be ignored by the receiver of the
DUPU message.
3.5.6. Destination Restricted (DRST)
The Destination Restricted (DRST) message is sent from an SG to all
concerned ASPs to indicate one of the following:
(1) A replicated subsystem is requesting that the TUA layer at the
ASP accept transac |
Documentation