| 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: Tue, 27 Aug 2024 17:50:06 GMT Copyright © 2014 OpenSS7 Corporation All Rights Reserved. |