Figure 1. Model of the TCI
Permission to use, copy and distribute this documentation without modification, for any purpose and without fee or royalty is hereby granted, provided that both the above copyright notice and this permission notice appears in all copies and that the name of OpenSS7 Corporation not be used in advertising or publicity pertaining to distribution of this documentation or its contents without specific, written prior permission. OpenSS7 Corporation makes no representation about the suitability of this documentation for any purpose. It is provided “as is” without express or implied warranty.
OpenSS7 Corporation disclaims all warranties with regard to this documentation including all implied warranties of merchantability, fitness for a particular purpose, non-infringement, or title; that the contents of the document are suitable for any purpose, or that the implementation of such contents will not infringe on any third party patents, copyrights, trademarks or other rights.. In no event shall OpenSS7 Corporation be liable for any direct, indirect, special or consequential damages or any damages whatsoever resulting from loss of use, data or profits, whether in an action of contract, negligence or other tortious action, arising out of or in connection with any use of this document or the performance or implementation of the contents thereof.
This document is a Application Program Interface containing technical details concerning the implementation of the Transaction Component Interface (TCI) for OpenSS7. It contains recommendations on software architecture as well as platform and system applicability of the Transaction Component Interface (TCI).
The purpose of this document is to provide technical documentation of the Transaction Component Interface (TCI). This document is intended to be included with the OpenSS7 STREAMS software package released by OpenSS7 Corporation. It is intended to assist software developers, maintainers and users of the Transaction Component Interface (TCI) with understanding the software architecture and technical interfaces which are made available in the software package.
It is the intent of this document that it act as the primary source of information concerning the Transaction Component Interface (TCI).
The audience for this document is software developers, maintainers and users and integrators of the Transaction Component Interface (TCI).
Take care that you are working with a current version of this documentation: you will not be notified of updates. To ensure that you are working with a current version, check the OpenSS7 Project website for a current version.
A printed (or postscript) version of this document is an UNCONTROLLED version.
This document specifies a STREAMS-based kernel-level instantiation of the ITU-T Transaction Capabilities Application Part (TCAP) Component (TC) Sub-Layer. The Transaction Component Interface (TCI) enables the user of a component sub-layer service to access and use any of a variety of conforming transaction providers without specific knowledge of the provider's protocol. The service interface is designed to support any transaction protocol but is intended for the ITU-T Recommendation Q.771 Transaction Capabilities Application Part (TCAP) Component (TC) Sub-Layer. This interface only specifies access to transaction component sub-layer services providers, and does not address issues concerning transaction or component sub-layer management, protocol performance, and performance analysis tools.
The specification assumes that the reader is familiar with the ISO reference model terminology, ISO/ITU-T transaction service definitions (ROSE, ACSE, TCAP), and STREAMS.
This document specifies an interface that supports the Transaction Component (TC) Sub-Layer services provided by the Transaction Capabilities Application Part (TCAP) as specified in ITU-T Recommendation Q.771. It may also be capable of supporting the transaction component capabilities of the Remote Operations Service Execution (ROSE) for Open Systems Interconnect for CCITT Applications as specified in ITU-T Recommendation X.219 and ISO ????. These specifications are targeted for use by developers and testers of protocol modules that require transaction component sub-layer service.1
The Transaction Component Sub-Layer provides the means to manage the dialogue of TC-Users into transaction components and dialogues. It is responsible for the routing and management of transaction component exchange within dialogues between TC-user entities.
The TCI defines the services provided by the transaction component sub-layer to the transaction component-user at the boundary between the Transaction Capabilities Application Part (TCAP) user and the Transaction Component (TC) Sub-Layer in the model presented in ITU-T Recommendation Q.771. The interface consists of a set of primitives defined as STREAMS messages that provide access to the component sub-layer services, and are transferred between the TC user entity and the TC provider. These primitives are of two types: ones that originate from the TC user, and others that originate from the TC provider, or respond to an event of the TC provider. The primitives that originate from the TC provider are either confirmations of a request or are indications to the TC user that the event has occurred. Figure 1 shows the model of the TCI.
|
Figure 1. Model of the TCI
|
The TCI allows the TC provider to be configured with any component sub-layer user (such as the Mobile Application Part whose upper layer interface is described in About This Manual), that also conforms to the TCI. A transaction component sub-layer user can also be a user program that conforms to the TCI and accesses the TC provider via putmsg(2) and getmsg(2) system calls.
STREAMS messages that are used to communicate transaction component service primitives between the transaction component user and the transaction component provider may have one of the following formats:
The following sections describe the service primitives which define all operation classes of service.
For all operation classes of service, two types of primitives exist: primitives that originate from the service user and primitives that originate from the service provider. The primitives that originate from the service user make requests to the service provider or response to an event of the service provider. The primitive that originate from the service provider are either confirmations of a request or are indications to the service user that an event has occurred. The primitive types along with the mapping of those primitives to the STREAMS message types and the service primitives of the ISO/IEC xxxxx and service definitions are listed in TCI Primitives. The format of these primitives and the rules governing the use of them are described in Management Primitives, Operation Class 1 through 3 Primitives, and Operation Class 4 Primitives.
The features of the TCI are defined in terms of the services provided by the TC provider, and the individual primitives that may flow between the TC user and the TC provider.
The services supported by the TCI are based on four distinct classes of transaction, operation classes 1, 2, 3 and 4. In addition, the TCI supports services for local management.
The main features of operation class 1 transactions are:
There are three phases to each transaction: Transaction Initiation, Transaction Data Transfer, and Transaction Termination.2 Transaction components arrive at their destination in the same order as they departed their source and the data is protected against duplication or loss of data units within some specified quality of service.
The main features of operation class 2 transactions are:
There are three phases to each transaction: Transaction Initiation, Transaction Data Transfer, and Transaction Termination.3 Transaction components arrive at their destination in the same order as they departed their source and the data is protected against duplication or loss of data units within some specified quality of service.
The main features of operation class 3 transactions are:
There are three phases to each transaction: Transaction Initiation, Transaction Data Transfer, and Transaction Termination.4 Transaction components arrive at their destination in the same order as they departed their source and the data is protected against duplication or loss of data units within some specified quality of service.
The main features of operation class 4 transactions are:
Operation class 4 has no structure to the transaction and has no separate phases. Each transaction component is transmitted from source to destination independently, appropriate addressing information is included with each component sequence. As the components are transmitted independently from source to destination, there are, in general, no guarantees of proper sequence and completeness of the data transmission.
| TC-Invoke | 1 | 2 | 3 | 4
|
| TC-Result | 1 | – | 3 | –
|
| TC-Error | 1 | 2 | – | –
|
| TC-Cancel | 1 | 2 | 3 | –
|
| TC-Reject | 1 | 2 | – | 4
|
The TCI specifications also define a set of local management functions that apply to all operation classes. These services have local significance only.
Table 1 and Table 2 summarize the TCI service primitives by their state and service.
| STATE | SERVICE | PRIMITIVES
|
| Local Management | Information Reporting | TC_INFO_REQ, TC_INFO_ACK, TC_ERROR_ACK |
| Bind | TC_BIND_REQ, TC_BIND_ACK, TC_UNBIND_REQ, TC_OK_ACK, TC_ERROR_ACK | |
| Options Management | TC_OPTMGMT_REQ, TC_OK_ACK, TC_ERROR_ACK | |
| Transaction Initiation | Transaction Begin | TC_BEGIN_REQ, TC_BEGIN_IND, TC_BEGIN_RES, TC_BEGIN_CON, TC_TOKEN_REQ, TC_TOKEN_ACK, TC_OK_ACK, TC_ERROR_ACK |
| Transaction Data Transfer | Transaction Continue | TC_CONT_REQ, TC_CONT_IND
|
| Transaction Release | Transaction End | TC_END_REQ, TC_END_IND
|
| Transaction Abort | TC_ABORT_REQ, TC_ABORT_IND
|
| STATE | SERVICE | PRIMITIVES
|
| Local Management | Information Reporting | TC_INFO_REQ, TC_INFO_ACK, TC_ERROR_ACK |
| Bind | TC_BIND_REQ, TC_BIND_ACK, TC_UNBIND_REQ, TC_OK_ACK, TC_ERROR_ACK | |
| Options Management | TC_OPTMGMT_REQ, TC_OK_ACK, TC_ERROR_ACK | |
| Transaction Unitdata | Transaction Unidirectional | TC_UNI_REQ, TC_UNI_IND
|
This section describes the services of the TCI primitives. Time-sequence diagrams 5 that illustrate the sequence of primitives are used. The format of the primitives will be defined later in this document.
The services defined in this section are outside the scope of the international standards. These services apply to all operation classes. They are involved for the initialization/de-initialization of a stream connected to the TC provider. They are also used to manage options supported by the TC provider and to report information on the supported parameter values.
This service provides information on the options supported by the TC provider.
TC_INFO_REQ:
This primitive request that the TC provider returns the values of all the supported protocol parameters. This request may be invoked during any phase.
TC_INFO_ACK:
This primitive is in response to the TC_INFO_REQ primitive and returns the values of the supported protocol parameters to the TC user.
The sequence of primitives for transaction information management is shown in Figure 2.
|
Figure 2. Sequence of Primitives
Transaction Information Reporting Service
 |
This service allows an originating address to be associated with a stream. It allows the TC user to negotiate the number of transaction begin indications that can remain unacknowledged for that TC user (a transaction begin indication is considered unacknowledged while it is awaiting a corresponding transaction response or abort request from the TC user). This service also defines a mechanism that allows a stream (bound to the address of the TC user) to be reserved to handle incoming transactions only. This stream is referred to as the listener stream.
TC_BIND_REQ:
This primitive request that the TC user be bound to a particular originating address, and negotiate the number of allowable outstanding transaction indications for that address.
TC_BIND_ACK:
This primitive is in response to the TC_BIND_REQ primitive and indicates to the user that the specified TC user has been bound to an originating address.
The sequence of primitives for the TC user bind service is shown in Figure 3.
|
Figure 3. Sequence of Primitives
TC User Bind Service
 |
This service allows the TC user to be unbound from a network address.
TC_UNBIND_REQ:
This primitive requests that the TC user be unbound from the network address it had previously been bound to.
The sequence of primitives for the TC user unbind service is shown in Figure 4.
|
Figure 4. Sequence of Primitives
TC User Unbind & Receipt Acknowledgement Services
 |
TC_OK_ACK:
This primitive indicates to the TC user that the previous TC user originated primitive was received successfully by the TC provider.
An example showing the sequence of primitives for successful receive acknowledgement is depicted in Figure 4.
This service allows the TC user to manage the QOS parameter values associated with the TC provider.
TC_OPTMGMT_REQ:
This primitive allows the TC user to select default values for QOS parameters within the range supported by the TC provider, and to indicate the default selection of return option.
TC_OPTMGMT_ACK:
Figure 5 shows the sequence of primitives for transaction options management.
|
Figure 5. Sequence of Primitives
Options Management Service
 |
TC_ERROR_ACK:
This primitive indicates to the TC user that a non-fatal error has occurred in the last TC user originated request or response primitive (listed in Figure 6) on the stream.
Figure 6 shows the sequence of primitives for the error management primitive.
|
Figure 6. Sequence of Primitives
Error Acknowledgement Service
 |
This section describes the required transaction service primitives that define the operation class 1, 2 and 3, structured transaction interface.
The queue model for operation classes 1, 2 and 3 are discussed in more detail in ITU-T X.219 and ITU-T Q.771.
The queue model represents the operation of a transaction dialogue in the abstract by a pair of queues linking two transaction users. There is one queue for each direction of component flow. Each queue represents a flow control function in one direction of transfer. The ability of a user to add objects to a queue will be determined by the behaviour of the user removing objects from that queue, and the state of the queue. The pair of queues is considered to be available for each potential transaction dialogue. Objects that are entered or removed from the queue are either as a result of interactions at the two transaction addresses, or as the result of TC provider initiatives.
Table 3 shows the ordering relationships among the queue model objects.
| Object X | BEGIN | CONT | END | ABORT
|
| Object Y
| ||||
| BEGIN | N/A | - | - | DES
|
| CONT | N/A | - | - | DES
|
| END | N/A | N/A | - | -
|
| AA | Indicates that Object X is defined to be able to advance ahead of preceding Object Y
|
| DES | Indicates that Object X is defined to be destructive with respect to the preceding Object Y.
|
| - | Indicates that Object X is neither destructive with respect to Object Y, nor able to advance ahead of Object Y
|
| N/A | Indicates that Object X will not occur in a position succeeding Object Y in a valid state of a queue.
|
A pair of queues is associated with a transaction dialogue between two
transaction users when the TC provider receives a TC_BEGIN_REQ
primitive at one of the TC users resulting in a begin object being entered into
the queue. The queues will remain associated with the transaction until a
TC_END_REQ
or TC_ABORT_REQ
primitive (resulting in an end or abort object) is either entered or removed
from a queue. Similarly, in the queue from the destination TC user, objects can
be entered into the queue only after the begin object associated with the
TC_BEGIN_RES
has been entered into the queue. Alternatively, the destination TC user can
enter an end or abort object into the queue instead of the begin object to
terminate the transaction.
The transaction establishment procedure will fail if the TC provider is unable
to establish a transaction dialogue, or if the destination TC user is unable
to accept the TC_BEGIN_IND
(see Transaction Termination primitive definition in TC_END_IND).
The following user primitves support Operation Class 1, 2, or 3 Phase I (Transaction Establishment) services:
TC_BEGIN_REQ:
This primitive requests that the TC provider form a transaction dialogue with the specified destination TC user.
TC_BEGIN_RES:
This primitive requests that the TC provider accept a previous transaction indication.
The following provider primitives support Operation Class 1, 2, or 3 Phase I (Transaction Establishment) services:
TC_BEGIN_IND:
This primitive indicates to the TC user that a transaction dialogue request has been made by a user at the specified source address.
TC_BEGIN_CON:
This primitive indicates to the TC user that a transaction initiation request has been confirmed on the specified responding address.
The sequence of primitives in a successful transaction initiation is defined by the time sequence diagrams as shown in Figure 7.
|
Figure 7. Sequence of Primitives:
Successful Transaction Initiation
 |
The sequence of primitives for the transaction initiation response token value determination is shown in Figure 8 (procedures for transaction initiation response token value determination are discussed in TC_BIND_REQ, and TC_BIND_ACK).
|
Figure 8. Sequence of Primitives:
Transaction Response Token Value Determination
 |
Flow control on the transaction dialogue is done by management of the queue capacity, and by allowing objects of certain types to be inserted to the queues, as shown in Table 4.
The following primitives support Operation Class 1, 2, or 3 Phase II (Transaction Component Transfer) services:
TC_CONT_REQ:
This primitive requests that the TC provider transfer the specified components.
TC_CONT_IND:
This primitive indicates to the TC user that this message contains components.
Figure 9 shows the sequence of primitives for successful component transfer. The sequence of primitives may remain incomplete if a `TC_END_REQ', `TC_ABORT_REQ', or `TC_ABORT_IND' primitive occurs.
|
Figure 9. Sequence of Primitives:
Component Transfer
 |
The transaction dialogue procedure is initialized by insertion of an end or
abort object (associated with a TC_END_REQ
or TC_ABORT_REQ)
into the queue. As shown in Table?, the termination procedure is destructive
with respect to other objects in the queue, and eventually results in the
emptying of queues and termination of the transaction dialogue.
The sequence of primitives depends on the origin of the termination action. The sequence may be:
The following primitives support Operation Class 1, 2, or 3 Phase III (Transaction Termination) services:
TC_END_REQ:
This primitive requests that the TC provider deny an outstanding request for a transaction dialogue or normal termination of an existing transaction.
TC_ABORT_REQ:
This primitive requests that the TC provider deny an outstanding request for a transaction dialogue or abnormal termination of an existing transaction.
TC_END_IND:
This primitive indicates to the TC user that either a request for transaction initiation has been denied or an existing transaction has been terminated normally.
TC_ABORT_IND:
This primitive indicates to the TC user that either a request for transaction initiation has been denied or an existing transaction has been terminated abnormally.
The sequence of primitives are shown in the time sequence diagrams in the figures that follow:
|
Figure 10. Sequence of Primitives:
TC User Invoked Termination
 |
|
Figure 11. Sequence of Primitives:
Simultaneous TC User Invoked Termination
 |
|
Figure 12. Sequence of Primitives:
TC Provider Invoked Termination
 |
|
Figure 13. Sequence of Primitives:
Simultaneous TC User and TC Provider Invoked Termination
 |
A TC user may reject a transaction initiation attempt by issuing a `TC_ABORT_REQ'. The originator parameter in the `TC_ABORT_REQ' will indicate TC user invoked termination. The sequence of primitives is shown in Figure 14.
|
Figure 14. Sequence of Primitives:
TC User Rejection of a Transaction Initiation Attempt
 |
If the TC provider is unable to establish a transaction, it indicates this to the requester by an `TC_ABORT_IND'. The originator of the primitive indicates a TC provider invoked release. This is shown in Figure 15.
|
Figure 15. Sequence of Primitives:
TC Provider Rejection of a Transaction Initiation Attempt
 |
The operation class 4 service allows for the transfer of transaction components in one and both directions simultaneously without establishing a transaction dialogue. A set of primitives are defined that carry transaction components and control information between the TC user and the TC provider entities. The primitives are modelled as requests initiated by the TC user and indications initiated by the TC provider. Indications may be initiated by the TC provider independently from requests by the TC user. The operation class 4 transaction service consists of one phase.
TC_UNI_REQ:
This primitive requests that the TC provider send the transaction components to the specified destination.
TC_UNI_IND:
This primitive indicates to the TC user that a component sequence has been received from the specified originating address.
Figure 16 shows the sequence of primitives for the operation class 4 mode of transfer.
|
Figure 16. Sequence of Primitives:
Operation Class 4 Component Transfer
 |
TC_NOTICE_IND:
This primitive indicates to the TC user that the components with the specified destination address and QOS parameters produced an error. This primitive is specific to operation class 4.
Figure 17 shows the sequence of primitives for the operation class 4 error management primitive.
|
Figure 17. Sequence of Primitives:
Operation Class 4 Error Indication Service
 |
TC_INVOKE_REQ:
TC_INVOKE_IND:
TC_RESULT_REQ:
TC_RESULT_IND:
TC_ERROR_REQ:
TC_ERROR_IND:
TC_CANCEL_REQ:
TC_CANCEL_IND:
TC_REJECT_REQ:
TC_REJECT_IND:
This section describes the format and parameters of the TCI primitives (Appendix A shows the mapping of TCI primitives to the primitives defined in ITU-T Q.771). In addition, it discusses the states in which the primitive is valid, the resulting state, and the acknowledgement that the primitive expects. (The state/event tables for these primitives are shown in Appendix B. The precedence tables for the TCI primitives are shown in Appendix C.) Rules for SS7 conformance are described in Addendum 1 to this document. The following tables provide a summary of the TC primitives and their parameters.
| SERVICE | PRIMITIVE | PARAMETERS
|
| TC Initiation | TC_BEGIN_REQ | ()
|
TC_BEGIN_IND | ()
| |
TC_BEGIN_RES | ()
| |
TC_BEGIN_CON | ()
|
| SERVICE | PRIMITIVE | PARAMETERS
|
| TC Initiation | TC_CONT_REQ | ()
|
TC_CONT_IND | ()
|
| SERVICE | PRIMITIVE | PARAMETERS
|
| TC Initiation | TC_END_REQ | ()
|
TC_END_IND | ()
| |
TC_ABORT_REQ | ()
| |
TC_ABORT_IND | ()
|
These primitives apply to all operation classes.
This primitive request the TC provider to return the values of all supported protocol parameters (see TC_INFO_ACK), and also the current state of the TC provider (as defined in State/Event Tables). This primitive does not affect the state of the TC provider and does not appear in the state tables.
The format of the message is one `M_PCPROTO' message block and its structure is as follows:
typedef struct TC_info_req {
ulong PRIM_type; /* Always TC_INFO_REQ */
} TC_info_req_t;
The primitive has the following arguments:
This primitive is valid in any state where a local acknowledgement is not pending.
The new state remains unchanged.
For the rules governing the requests made by this primitive, see the `TC_INFO_ACK' primitive described in TC_INFO_ACK.
This primitive requires the TC provider to generate one of the following acknowledgements upon receipt of the primitive:
Acknowledgement of the primitive is indicatd with the TC_INFO_ACK
primitive described in TC_INFO_ACK.
These errors will be indicated with the TC_ERROR_ACK primitive described
in TC_ERROR_ACK. The allowable errors are as follows:
There are no errors associated with the issuance of this primitive.
This primitive indicates to the TC user any relevant protocol-dependent
parameters.6 It should be initiated in response to the
TC_INFO_REQ primitive described above under TC_INFO_REQ.
The format of the message is one `M_PCPROTO' message block and its structure is as follows:
typedef struct TC_info_ack {
long PRIM_type; /* always TC_INFO_ACK */
long TSDU_size; /* maximum TSDU size */
long ETSDU_size; /* maximum ETSDU size */
long CDATA_size; /* connect data size */
long DDATA_size; /* disconnect data size */
long ADDR_size; /* maximum address size */
long OPT_size; /* maximum options size */
long TIDU_size; /* transaction interface data size */
long SERV_type; /* service type */
long CURRENT_state; /* current state */
long PROVIDER_flag; /* provider flags */
long TCI_version; /* TCI version */
} TC_info_ack_t;
The primitive has the following arguments:
TC_INFO_REQ was issued (a network address is bound
to a stream via a TC_BIND_REQ).
typedef struct TC_bind_req {
ulong PRIM_type;
ulong ADDR_length; /* address length */
ulong ADDR_offset; /* address offset */
ulong XACT_number; /* maximum outstanding transaction reqs. */
ulong BIND_flags; /* bind flags */
} TC_bind_req_t;
typedef struct TC_subs_bind_req {
ulong PRIM_type;
} TC_subs_bind_req_t;
The primitive has the following arguments:
typedef struct TC_bind_ack {
ulong PRIM_type;
ulong ADDR_length;
ulong ADDR_offset;
ulong XACT_number;
ulong TOKEN_value;
} TC_bind_ack_t;
typedef struct TC_subs_bind_ack {
ulong PRIM_type;
} TC_subs_bind_ack_t;
The primitive has the following arguments:
typedef struct TC_unbind_req {
ulong PRIM_type; /* Always TC_UNBIND_REQ */
} TC_unbind_req_t;
The primitive has the following arguments:
The primitive has the following arguments:
The format of the message is one `M_PCPROTO' message block structured as follows:
The primitive has the following arguments:
typedef struct TC_optmgmt_req {
ulong PRIM_type;
ulong OPT_length;
ulong OPT_offset;
ulong MGMT_flags;
} TC_optmgmt_req_t;
The primitive has the following arguments:
The format of the message is one `M_PCPROTO' message block structured as follows:
typedef struct TC_optmgmt_ack {
ulong PRIM_type;
ulong OPT_length;
ulong OPT_offset;
ulong MGMT_flags;
} TC_optmgmt_ack_t;
The primitive has the following arguments:
The format of the message is one `M_PCPROTO' message block structured as follows:
typedef struct TC_ok_ack {
ulong PRIM_type;
ulong CORRECT_prim;
} TC_ok_ack_t;
The primitive has the following arguments:
The format of the message is one `M_PCPROTO' message block structured as follows:
typedef struct TC_error_ack {
ulong PRIM_type;
ulong ERROR_prim;
ulong TRPI_error;
ulong UNIX_error;
ulong DIALOG_id;
ulong INVOKE_id;
} TC_error_ack_t;
The primitive has the following arguments:
This section describes the operation class 1, 2, and 3 dialogue handling primitives. Primitives are grouped into phases:
The transaction begin service provides means to start a transaction dialogue between two TC-users. This may be accompanied by the transfer of components previously accumulated using the component handling primitives described in Component Handling Primitives.
This primitive requests that the transaction component provider form a transaction dialogue to the specified destination protocol address, from the specified source protocol address, using the specified options. Any components that have been accumulated using the component handling primitives (see Component Handling Primitives), will accompany the primitive.
The format of the message is one `M_PROTO' message block followed by zero or more `M_DATA' message blocks containing raw transaction user information. The `M_PROTO' message block is structured as follows:
typedef struct TC_begin_req {
ulong PRIM_type; /* Always TC_BEGIN_REQ */
ulong SRC_length; /* Source address length */
ulong SRC_offset; /* Source address offset */
ulong DEST_length; /* Destination address length */
ulong DEST_offset; /* Destination address offset */
ulong OPT_length; /* Options associated with the primitive */
ulong OPT_offset; /* Options associated with the primitive */
ulong DIALOG_id; /* Dialog Identifier */
ulong COMP_flags; /* For use with ANSI QWP/QWOP */
} TC_begin_req_t;
The primitive has the following arguments:
The COMP_flags field can contain any of the following flags:
This primitive is valid in transaction state TC_IDLE.
The new state for the transaction is TC_WACK_CREQ.
The following rules apply to the specification of parameters to this primitive:
This primitive requires the transaction provider to generate one of the following acknowledgements upon receipt of the primitive:
The transaction indication service primitive indicates that a peer TC user has initiated a transaction dialogue, the source protocol address associated with the peer TC user, the destination address to which the transaction dialogue is initiated, the options for the dialogue.
The format of the message is one `M_PROTO' message block structured as follows:
typedef struct TC_begin_ind {
ulong PRIM_type; /* Always TC_BEGIN_IND */
ulong SRC_length; /* Source address length */
ulong SRC_offset; /* Source address offset */
ulong DEST_length; /* Destination address length */
ulong DEST_offset; /* Destination address offset */
ulong OPT_length; /* Options associated with the primitive */
ulong OPT_offset; /* Options associated with the primitive */
ulong DIALOG_id; /* Dialog Identifier */
ulong COMP_flags; /* For use with ANSI QWP/QWOP */
} TC_begin_ind_t;
The primitive has the following arguments:
The COMP_flags field can contain any of the following flags:
This primitive is valid in transaction state TC_IDLE.
The new state of the transaction is TC_WRES_CIND.
The following rules apply to the issuance of this primitive by the transaction provider:
This primitive allows the destination TC user to request that the TC provider accept a previous transaction dialogue begin indication, either on the current stream or on a specified acceptor stream.
The format of the message is one `M_PROTO' message block structured as follows:
typedef struct TC_begin_res {
ulong PRIM_type; /* Always TC_CONT_REQ */
ulong SRC_length; /* Source address length */
ulong SRC_offset; /* Source address offset */
ulong OPT_length; /* Options associated with the primitive */
ulong OPT_offset; /* Options associated with the primitive */
ulong DIALOG_id; /* Dialog Identifier */
ulong COMP_flags; /* For use with ANSI CWP/CWOP */
} TC_begin_res_t;
The primitive has the following arguments:
The COMP_flags field can contain any of the following flags:
This primitive is valid in transaction state TC_WRES_CIND.
The new state of the transaction is TC_DATA_XFER.
This primitive requires the TC provider to generate one of the following acknowledgements upon receipt of the primitive:
TC_OK_ACK
primitive described in TC_OK_ACK.
TC_ERROR_ACK primitive described
in TC_ERROR_ACK. The allowable errors are as follows:
TCBADFTCBADOPTTCACCESTCOUTSTATETCBADDATATCBADFLAGTCBADSEQTCSYSERRTCRESADDRTCBADADDRThe format of the message is one `M_PROTO' message block structured as follows:
typedef struct TC_begin_con {
ulong PRIM_type; /* Always TC_CONT_IND */
ulong OPT_length; /* Options associated with the primitive */
ulong OPT_offset; /* Options associated with the primitive */
ulong DIALOG_id; /* Dialog Identifier */
ulong COMP_flags; /* For use with ANSI CWP/CWOP */
} TC_begin_con_t;
The primitive has the following arguments:
The component transfer service primtiives provide for an exchange of component user data known as TSDUs, in either direction or in both directions simultaneously on a transaction dialogue. The transaction service preserves both the sequence and the boundaries of the TSDUs.
The format of the message is one `M_PROTO' message block structured as follows:
typedef struct TC_cont_req {
ulong PRIM_type; /* Always TC_CONT_REQ */
ulong OPT_length; /* Options associated with the primitive */
ulong OPT_offset; /* Options associated with the primitive */
ulong DIALOG_id; /* Dialog Identifier */
ulong COMP_flags; /* For use with ANSI CWP/CWOP */
} TC_cont_req_t;
The primitive has the following arguments:
The format of the message is one `M_PROTO' message block structured as follows:
typedef struct TC_cont_ind {
ulong PRIM_type; /* Always TC_CONT_IND */
ulong OPT_length; /* Options associated with the primitive */
ulong OPT_offset; /* Options associated with the primitive */
ulong DIALOG_id; /* Dialog Identifier */
ulong COMP_flags; /* For use with ANSI CWP/CWOP */
} TC_cont_ind_t;
The primitive has the following arguments:
The format of the message is one `M_PROTO' message block structured as follows:
typedef struct TC_end_req {
ulong PRIM_type; /* Always TC_END_REQ */
ulong OPT_length; /* Options associated with the primitive */
ulong OPT_offset; /* Options associated with the primitive */
ulong DIALOG_id; /* Dialog Identifier */
ulong TERM_scenario; /* Reason for termination */
} TC_end_req_t;
The primitive has the following arguments:
The format of the message is one `M_PROTO' message block structured as follows:
typedef struct TC_end_ind {
ulong PRIM_type; /* Always TC_END_IND */
ulong OPT_length; /* Options associated with the primitive */
ulong OPT_offset; /* Options associated with the primitive */
ulong DIALOG_id; /* Dialog Identifier */
ulong COMP_flags; /* Components present flag */
} TC_end_ind_t;
The primitive has the following arguments:
The format of the message is one `M_PROTO' message block structured as follows:
typedef struct TC_abort_req {
ulong PRIM_type; /* Always TC_ABORT_REQ */
ulong OPT_length; /* Options associated with the primitive */
ulong OPT_offset; /* Options associated with the primitive */
ulong DIALOG_id; /* Dialog Identifier */
ulong ABORT_reason; /* Abort reason */
} TC_abort_req_t;
The primitive has the following arguments:
The format of the message is one `M_PROTO' message block structured as follows:
typedef struct TC_abort_ind {
ulong PRIM_type; /* Always TC_ABORT_IND */
ulong OPT_length; /* Options associated with the primitive */
ulong OPT_offset; /* Options associated with the primitive */
ulong DIALOG_id; /* Dialog Identifier */
ulong ABORT_reason; /* Abort reason */
ulong ORIGINATOR; /* Either User or Provider originated */
} TC_abort_ind_t;
The primitive has the following arguments:
The format of the message is one `M_PROTO' message block, followed by zero or more `M_DATA' message blocks if any components are specified by the TC user. The format of the `M_PROTO' message block is as follows:
typedef struct TC_uni_req {
ulong PRIM_type; /* Always TC_UNI_REQ */
ulong SRC_length; /* Source address length */
ulong SRC_offset; /* Source address offset */
ulong DEST_length; /* Destination address length */
ulong DEST_offset; /* Destination address offset */
ulong OPT_length; /* Options associated with the primitive */
ulong OPT_offset; /* Options associated with the primitive */
ulong DIALOG_id; /* Dialog Identifier */
} TC_uni_req_t;
The primitive has the following arguments:
The format of the message is one `M_PROTO' message block, followed by zero or more `M_DATA' message blocks if any components are specified by the TC user. The format of the `M_PROTO' message block is as follows:
typedef struct TC_uni_ind {
ulong PRIM_type; /* Always TC_UNI_IND */
ulong SRC_length; /* Source address length */
ulong SRC_offset; /* Source address offset */
ulong DEST_length; /* Destination address length */
ulong DEST_offset; /* Destination address offset */
ulong OPT_length; /* Options associated with the primitive */
ulong OPT_offset; /* Options associated with the primitive */
ulong DIALOG_id; /* Dialog Identifier */
ulong COMP_flags; /* Components preset flag */
} TC_uni_ind_t;
The primitive has the following arguments:
The format of the message is one `M_PROTO' message block, followed by zero or more `M_DATA' message blocks if any components are specified by the TC user. The format of the `M_PROTO' message block is as follows:
typedef struct TC_notice_ind {
ulong PRIM_type; /* Always TC_NOTICE_IND */
ulong DIALOG_id; /* Dialog Identifier */
ulong REPORT_cause; /* Report cause */
} TC_notice_ind_t;
The primitive has the following arguments:
The format of the message is one `M_PROTO' message block, followed by zero or more `M_DATA' message blocks if any components are specified by the TC user. The format of the `M_PROTO' message block is as follows:
typedef struct TC_invoke_req {
ulong PRIM_type; /* Always TC_INVOKE_REQ */
ulong DIALOG_id; /* Dialog identifier */
ulong PROTOCOL_class; /* Application protocol class */
ulong INVOKE_id; /* Invoke Identifier */
ulong LINKED_id; /* Linked Invoke Identifier */
ulong OPERATION; /* Requested operation to invoke */
ulong MORE_flag; /* Not last */
ulong TIMEOUT; /* Timeout */
} TC_invoke_req_t;
The primitive has the following arguments:
The format of the message is one `M_PROTO' message block, followed by zero or more `M_DATA' message blocks if any components are specified by the TC user. The format of the `M_PROTO' message block is as follows:
typedef struct TC_invoke_ind {
ulong PRIM_type; /* Always TC_INVOKE_IND */
ulong DIALOG_id; /* Dialog identifier */
ulong OP_class; /* Application operation class */
ulong INVOKE_id; /* Invoke Identifier */
ulong LINKED_id; /* Linked Invoke Identifier */
ulong OPERATION; /* Requested operation to invoke */
ulong MORE_flag; /* Not last */
} TC_invoke_ind_t;
The primitive has the following arguments:
The format of the message is one `M_PROTO' message block, followed by zero or more `M_DATA' message blocks if any components are specified by the TC user. The format of the `M_PROTO' message block is as follows:
typedef struct TC_result_req {
ulong PRIM_type; /* Always TC_RESULT_REQ */
ulong DIALOG_id; /* Dialog Identifier */
ulong INVOKE_id; /* Invoke Identifier */
ulong OPERATION; /* Requested operation result */
ulong MORE_flag; /* Not last */
} TC_result_req_t;
The primitive has the following arguments:
The format of the message is one `M_PROTO' message block, followed by zero or more `M_DATA' message blocks if any components are specified by the TC user. The format of the `M_PROTO' message block is as follows:
typedef struct TC_result_ind {
ulong PRIM_type; /* Always TC_RESULT_IND */
ulong DIALOG_id; /* Dialog Identifier */
ulong INVOKE_id; /* Invoke Identifier */
ulong OPERATION; /* Requested operation result */
ulong MORE_flag; /* Not last */
} TC_result_ind_t;
The primitive has the following arguments:
The format of the message is one `M_PROTO' message block, followed by zero or more `M_DATA' message blocks if any components are specified by the TC user. The format of the `M_PROTO' message block is as follows:
typedef struct TC_error_req {
ulong PRIM_type; /* Always TC_ERROR_REQ */
ulong DIALOG_id; /* Dialog Identifier */
ulong INVOKE_id; /* Invoke Identifier */
ulong ERROR_code; /* Error code */
ulong MORE_flag; /* Not last */
} TC_error_req_t;
The primitive has the following arguments:
The format of the message is one `M_PROTO' message block, followed by zero or more `M_DATA' message blocks if any components are specified by the TC user. The format of the `M_PROTO' message block is as follows:
typedef struct TC_error_ind {
ulong PRIM_type; /* Always TC_ERROR_IND */
ulong DIALOG_id; /* Dialog Identifier */
ulong INVOKE_id; /* Invoke Identifier */
ulong ERROR_code; /* Error code */
} TC_error_ind_t;
The primitive has the following arguments:
The format of the message is one `M_PROTO' message block, followed by zero or more `M_DATA' message blocks if any components are specified by the TC user. The format of the `M_PROTO' message block is as follows:
typedef struct TC_cancel_req {
ulong PRIM_type; /* Always TC_CANCEL_REQ */
ulong DIALOG_id; /* Dialog Identifier */
ulong INVOKE_id; /* Invoke identifier */
} TC_cancel_req_t;
The primitive has the following arguments:
The format of the message is one `M_PROTO' message block, followed by zero or more `M_DATA' message blocks if any components are specified by the TC user. The format of the `M_PROTO' message block is as follows:
typedef struct TC_cancel_ind {
ulong PRIM_type; /* Always TC_CANCEL_IND */
ulong DIALOG_id; /* Dialog Identifier */
ulong INVOKE_id; /* Invoke identifier */
} TC_cancel_ind_t;
The primitive has the following arguments:
The format of the message is one `M_PROTO' message block, followed by zero or more `M_DATA' message blocks if any components are specified by the TC user. The format of the `M_PROTO' message block is as follows:
typedef struct TC_reject_req {
ulong PRIM_type; /* Always TC_REJECT_REQ */
ulong DIALOG_id; /* Dialog Identifier */
ulong INVOKE_id; /* Invoke identifier */
ulong PROBLEM_code; /* Problem code */
} TC_reject_req_t;
The primitive has the following arguments:
The format of the message is one `M_PROTO' message block, followed by zero or more `M_DATA' message blocks if any components are specified by the TC user. The format of the `M_PROTO' message block is as follows:
typedef struct TC_reject_ind {
ulong PRIM_type; /* Always TC_REJECT_IND */
ulong DIALOG_id; /* Dialog Identifier */
ulong INVOKE_id; /* Invoke identifier */
ulong ORIGINATOR; /* Either User, Local or Remote */
ulong PROBLEM_code; /* Problem code */
} TC_reject_ind_t;
The primitive has the following arguments:
| SDLI | Signalling Data Link Interface
|
| SDL | Signalling Data Link
|
| SDL SDU | Signalling Data Link Service Data Unit
|
| ITU-T | International Telecommunications Union - Telecom Sector
|
| PPA | Physical Point of Attachment
|
| [1] | ITU-T Recommendation Q.700
|
| [2] | ITU-T Recommendation Q.701
|
| [3] | ITU-T Recommendation Q.702
|
| [4] | ITU-T Recommendation Q.703
|
| [5] | ITU-T Recommendation Q.704
|
| [6] | Geoffrey Gerrien, “CDI - Application Program Interface Guide,” Gcom, Inc., March 1999.
|
| [7] | ITU-T Recommendation Q.771
|
TC_abort_ind_t: TC_ABORT_INDTC_abort_req_t: TC_ABORT_REQTC_addr_ack_t: TC_ADDR_ACKTC_addr_req_t: TC_ADDR_REQTC_begin_con_t: TC_BEGIN_CONTC_begin_ind_t: TC_BEGIN_INDTC_begin_req_t: TC_BEGIN_REQTC_begin_res_t: TC_BEGIN_RESTC_bind_ack_t: TC_BIND_ACKTC_bind_req_t: TC_BIND_REQTC_cancel_ind_t: TC_CANCEL_INDTC_cancel_req_t: TC_CANCEL_REQTC_cont_ind_t: TC_CONT_INDTC_cont_req_t: TC_CONT_REQTC_end_ind_t: TC_END_INDTC_end_req_t: TC_END_REQTC_error_ack_t: TC_ERROR_ACKTC_error_ind_t: TC_ERROR_INDTC_error_req_t: TC_ERROR_REQTC_info_ack_t: TC_INFO_ACKTC_info_req_t: TC_INFO_REQTC_invoke_ind_t: TC_INVOKE_INDTC_invoke_req_t: TC_INVOKE_REQTC_notice_ind_t: TC_NOTICE_INDTC_ok_ack_t: TC_OK_ACKTC_optmgmt_ack_t: TC_OPTMGMT_ACKTC_optmgmt_req_t: TC_OPTMGMT_REQTC_reject_ind_t: TC_REJECT_INDTC_reject_req_t: TC_REJECT_REQTC_result_ind_t: TC_RESULT_INDTC_result_req_t: TC_RESULT_REQTC_subs_bind_ack_t: TC_BIND_ACKTC_subs_bind_req_t: TC_BIND_REQTC_unbind_req_t: TC_UNBIND_REQTC_uni_ind_t: TC_UNI_INDTC_uni_req_t: TC_UNI_REQABORT_reason: TC_ABORT_INDABORT_reason: TC_ABORT_REQADDR_length: TC_BIND_ACKADDR_length: TC_BIND_REQADDR_offset: TC_BIND_ACKADDR_offset: TC_BIND_REQBIND_flags: TC_BIND_REQCOMP_flags: TC_UNI_INDCOMP_flags: TC_END_INDCOMP_flags: TC_CONT_INDCOMP_flags: TC_CONT_REQCOMP_flags: TC_BEGIN_CONCOMP_flags: TC_BEGIN_RESCOMP_flags: TC_BEGIN_INDCOMP_flags: TC_BEGIN_REQCOMPONENTS_PRESENT: TC_BEGIN_REQCORRECT_prim: TC_OK_ACKDEST_length: TC_UNI_INDDEST_length: TC_UNI_REQDEST_length: TC_BEGIN_INDDEST_length: TC_BEGIN_REQDEST_offset: TC_UNI_INDDEST_offset: TC_UNI_REQDEST_offset: TC_BEGIN_INDDEST_offset: TC_BEGIN_REQDIALOG_id: TC_REJECT_INDDIALOG_id: TC_REJECT_REQDIALOG_id: TC_CANCEL_INDDIALOG_id: TC_CANCEL_REQDIALOG_id: TC_ERROR_INDDIALOG_id: TC_ERROR_REQDIALOG_id: TC_RESULT_INDDIALOG_id: TC_RESULT_REQDIALOG_id: TC_INVOKE_INDDIALOG_id: TC_INVOKE_REQDIALOG_id: TC_NOTICE_INDDIALOG_id: TC_UNI_INDDIALOG_id: TC_UNI_REQDIALOG_id: TC_ABORT_INDDIALOG_id: TC_ABORT_REQDIALOG_id: TC_END_INDDIALOG_id: TC_END_REQDIALOG_id: TC_CONT_INDDIALOG_id: TC_CONT_REQDIALOG_id: TC_BEGIN_CONDIALOG_id: TC_BEGIN_RESDIALOG_id: TC_BEGIN_INDDIALOG_id: TC_BEGIN_REQDIALOG_id: TC_ERROR_ACKERROR_code: TC_ERROR_INDERROR_code: TC_ERROR_REQERROR_prim: TC_ERROR_ACKINVOKE_id: TC_REJECT_INDINVOKE_id: TC_REJECT_REQINVOKE_id: TC_CANCEL_INDINVOKE_id: TC_CANCEL_REQINVOKE_id: TC_ERROR_INDINVOKE_id: TC_ERROR_REQINVOKE_id: TC_RESULT_INDINVOKE_id: TC_RESULT_REQINVOKE_id: TC_INVOKE_INDINVOKE_id: TC_INVOKE_REQINVOKE_id: TC_ERROR_ACKLINKED_id: TC_INVOKE_INDLINKED_id: TC_INVOKE_REQMGMT_flags: TC_OPTMGMT_ACKMGMT_flags: TC_OPTMGMT_REQMORE_flag: TC_ERROR_REQMORE_flag: TC_RESULT_INDMORE_flag: TC_RESULT_REQMORE_flag: TC_INVOKE_INDMORE_flag: TC_INVOKE_REQNO_PERMISSION: TC_BEGIN_REQOP_class: TC_INVOKE_INDOPERATION: TC_RESULT_INDOPERATION: TC_RESULT_REQOPERATION: TC_INVOKE_INDOPERATION: TC_INVOKE_REQOPT_length: TC_UNI_INDOPT_length: TC_UNI_REQOPT_length: TC_ABORT_INDOPT_length: TC_ABORT_REQOPT_length: TC_END_INDOPT_length: TC_END_REQOPT_length: TC_CONT_INDOPT_length: TC_CONT_REQOPT_length: TC_BEGIN_CONOPT_length: TC_BEGIN_RESOPT_length: TC_BEGIN_INDOPT_length: TC_BEGIN_REQOPT_length: TC_OPTMGMT_ACKOPT_length: TC_OPTMGMT_REQOPT_offset: TC_UNI_INDOPT_offset: TC_UNI_REQOPT_offset: TC_ABORT_INDOPT_offset: TC_ABORT_REQOPT_offset: TC_END_INDOPT_offset: TC_END_REQOPT_offset: TC_CONT_INDOPT_offset: TC_CONT_REQOPT_offset: TC_BEGIN_CONOPT_offset: TC_BEGIN_RESOPT_offset: TC_BEGIN_INDOPT_offset: TC_BEGIN_REQOPT_offset: TC_OPTMGMT_ACKOPT_offset: TC_OPTMGMT_REQORIGINATOR: TC_REJECT_INDORIGINATOR: TC_ABORT_INDPRIM_type: TC_REJECT_INDPRIM_type: TC_REJECT_REQPRIM_type: TC_CANCEL_INDPRIM_type: TC_CANCEL_REQPRIM_type: TC_ERROR_INDPRIM_type: TC_ERROR_REQPRIM_type: TC_RESULT_INDPRIM_type: TC_RESULT_REQPRIM_type: TC_INVOKE_INDPRIM_type: TC_INVOKE_REQPRIM_type: TC_NOTICE_INDPRIM_type: TC_UNI_INDPRIM_type: TC_UNI_REQPRIM_type: TC_ABORT_INDPRIM_type: TC_ABORT_REQPRIM_type: TC_END_INDPRIM_type: TC_END_REQPRIM_type: TC_CONT_INDPRIM_type: TC_CONT_REQPRIM_type: TC_BEGIN_CONPRIM_type: TC_BEGIN_RESPRIM_type: TC_BEGIN_INDPRIM_type: TC_BEGIN_REQPRIM_type: TC_ERROR_ACKPRIM_type: TC_OK_ACKPRIM_type: TC_OPTMGMT_ACKPRIM_type: TC_OPTMGMT_REQPRIM_type: TC_UNBIND_REQPRIM_type: TC_BIND_ACKPRIM_type: TC_BIND_REQPRIM_type: TC_INFO_REQPROBLEM_code: TC_REJECT_INDPROBLEM_code: TC_REJECT_REQPROTOCOL_class: TC_INVOKE_REQREPORT_cause: TC_NOTICE_INDSRC_length: TC_UNI_INDSRC_length: TC_UNI_REQSRC_length: TC_BEGIN_RESSRC_length: TC_BEGIN_INDSRC_length: TC_BEGIN_REQSRC_offset: TC_UNI_INDSRC_offset: TC_UNI_REQSRC_offset: TC_BEGIN_RESSRC_offset: TC_BEGIN_INDSRC_offset: TC_BEGIN_REQTC_COMPONENTS_PRESENT: TC_BEGIN_RESTC_COMPONENTS_PRESENT: TC_BEGIN_INDTC_NO_PERMISSION: TC_BEGIN_RESTC_NO_PERMISSION: TC_BEGIN_INDTCACCES: TC_BEGIN_RESTCACCES: TC_BEGIN_REQTCBADADDR: TC_BEGIN_RESTCBADADDR: TC_BEGIN_REQTCBADDATA: TC_BEGIN_RESTCBADDATA: TC_BEGIN_REQTCBADF: TC_BEGIN_RESTCBADFLAG: TC_BEGIN_RESTCBADFLAG: TC_BEGIN_REQTCBADOPT: TC_BEGIN_RESTCBADOPT: TC_BEGIN_REQTCBADSEQ: TC_BEGIN_RESTCBADSEQ: TC_BEGIN_REQTCOUTSTATE: TC_BEGIN_RESTCOUTSTATE: TC_BEGIN_REQTCRESADDR: TC_BEGIN_RESTCSYSERR: TC_BEGIN_RESTCSYSERR: TC_BEGIN_REQTERM_scenario: TC_END_REQTIMEOUT: TC_INVOKE_REQTOKEN_value: TC_BIND_ACKTRPI_error: TC_ERROR_ACKUNIX_error: TC_ERROR_ACKXACT_number: TC_BIND_ACKXACT_number: TC_BIND_REQ[1] An example of a protocol module that requires transaction component sub-layer services is the 3GPP TS 29.002 Mobile Application Part (MAP).
[2] All three phases in operation class 1 can be combined into a single exchange of primitives.
[3] All three phases in operation class 2 can be combined into a single exchange of primitives.
[4] All three phases in operation class 3 can be combined into a single exchange of primitives.
[5] Conventions for the time-sequence diagrams are defined in ITU-T X.210, ISO/IEC 10731:1994.
[6]