(Page 1 of 1 in this chapter)

Chapter 2

SS7 TCAP API Description

2.1 TCAP API Concepts and Terminology
2.2 Asynchronous Communication Model
2.3 TCAP API Procedures
2.4 TCAP Management API
2.5 Unsolicited Alarms

This section introduces the concepts and terminology used in describing the application interface to the TCAP layer services and presents an overview of how the TCAP APIs can be used to develop SS7 transaction based applications.

2.1 TCAP API Concepts and Terminology

The following subsections describe the specific terminology and concepts associated with the TCAP API.

2.1.1 TCAP Service Users and Service Access Points

The TCAP user interface supports one or more user applications by way of Service Access Points, or SAPs (Figure 2). A TCAP SAP is associated with a SCCP subsystem number and protocol variant (ANSI or ITU-T). A TCAP SAP, in turn, has a one-to-one correspondence with a SCCP SAP

.

Figure 2. TCAP Service Access Points (SAPs)



A user applications binds to a particular SAP at initialization time, specifying the TCAP SAP ID that it wishes to bind to.  An application may implement multiple subsystems by binding to multiple TCAP SAPs. If an application supports multiple TX Series boards, it must bind with each board separately.


Note:  The number of SAPs and the characteristics of each SAP are specified at TCAP configuration time. See the Signaling System 7 (SS7) Installation and Configuration Manual for details.





2.1.2	 Entity and Instance IDs





Each user application must also have entity and instance numbers, which are used to route messages among the various processes in the system.  Entity IDs are single byte values in the range 0x00..0x3F, which must be unique among all processes on  a processor.  Entity IDs are assigned as desired by the application developer.  The range 0x20 - 0x3F is recommended for applications. The following entity IDs are reserved. 





 ------



 0x00-0x13



 Reserved




 ISUP



 0x14



 ISDN User Part Protocol Handler




 MTP3



 0x15



 Message Transfer Part Layer 3




 MTP2



 0x16



 Message Transfer Part Layer 2




 TCAP



 0x17



 TCAP Protocol Handler




 ------



 0x18 - 0x1B



 Reserved




 MTP1



 0x1C



 Message Transfer Part Layer 1




 TUP



 0x1D



 Telephone User Part




 SCCP



 0x1E



 SCCP Protocol Handler




 ------



 0x1F



 Reserved




 ------



 0x20 - 0x3F



 Available for applications
















Instance IDs identify the processor that the entity executes on.  The host is always processor 0 (zero), so for all host-resident TCAP user applications this value should be coded to zero. All tasks on TX Series board number 1 receive and instance ID of 1, all tasks on TX Series board number 2 receive and instance ID of 2, and so on.






2.1.3	 Dialog IDs





A TCAP application uses two dialog IDs to reference a particular transaction: a service user dialog ID (suDlgId) and a service provider dialog ID (spDlgId).  Both are 32-bit unsigned integers.  



The service user dialog ID is assigned by the application on the first outgoing request for a particular transaction. This ID must be unique among all concurrently active transactions associated with a particular TCAP SAP (i.e., subsystem number).  The content of this dialog ID is not checked by the TCAP protocol layer, but it is passed back and forth between the application and the TCAP layer on all subsequent requests/indications belonging to that transaction.  The application may choose any value it wishes for the suDlgId - an address or index to a data structure, for example - to help it associate a message with its transaction. A suDlgId value may be re-used by the application any time after the previous transaction using that value has completed.



The service provider dialog ID is assigned by the TCAP layer in the first incoming message associated with a particular transaction (either a new transaction indication or a response from a far SP). The application is expected to store this value and pass it back to the TCAP layer on all subsequent requests belonging to that transaction. On the first outgoing request for a transaction, and on any subsequent request prior to receiving an incoming message belonging to that transaction, the application must pass an spDlgId value of zero.


 






2.1.4	 SCCP Addresses





With each transaction request, the application must specify the destination and originating addresses for the SCCP layer.



The destination (or called party) address is used by the SCCP layer to route the transaction request to the proper destination. It contains the point code + subsystem number and/or global title of the destination application.  



If the destination address contains just a point code and subsystem number, they are used to directly route the message. 



If the destination address contains just a global title (no point code or subsystem number), the SCCP layer must have been configured with a translation for that global title in order to determine the actual destination point code + subsystem number to which the message is routed.



If the destination address contains both a global title and point code + subsystem number, the application specifies via the routing indicator whether the message should be routed using the global title (in which case the SCCP layer must have been configured with a translation for that global title) or via the PC/SSN, in which case the global title is carried along for informational purposes or for further translation by a downstream node.



Global titles for ITU-T applications may be any of the four global title formats specified in the ITU-T SCCP layer standards.  ANSI global titles can be one of two formats.



The originating (or calling party) address is passed in the SCCP message to the far SP to allow it to return a response.  It is the same format as the destination address.  If the point code and/or subsystem number are absent from the originating address passed by the application, the SCCP layer will insert its configured point code and/or the subsystem number assigned to that application SAP during the bind operation to form the calling party address.



The format of the SCCP address structure is specified in Chapter 3. Details for configuring SCCP global title translations are found in the SS7 Installation and Configuration Manual.






2.1.5	 SCCP Quality of Service (QOS)





The TCAP layer utilizes the SCCP connectionless transport service to deliver transaction messages to their destinations. With this service, three additional quality of service options are available to the application.



Message Priority   The application can assign a priority of from 0 (lowest priority) to 3 (highest priority).



Return Option   This option allows the calling application to request that messages (transaction requests) that cannot be delivered are returned to the application (via a TCAP Status Indication Message); by default, undeliverable messages are discarded by the SCCP layer without notifying the sending application.



Sequential Delivery   The application can request that consecutive transaction requests are delivered in order.  This might be required if an application sends multiple transaction messages without waiting for a response to the first transaction request.  When this option is selected, TCAP uses the SCCP class 1 connectionless service; by default TCAP uses the SCCP class 0 service, which has no guarantee of delivery order.


 






2.1.6	 ANSI Transaction Types





The TCAP layer supports the following ANSI transaction types (also called package types): 





 Transaction Type



 Description




 Unidirectional



 Sends information in one direction only, with no reply expected.  No TCAP transaction is established.




 Query With Permission



 Initiates a TCAP transaction and gives the destination node permission to end the transaction.




 Query Without Permission



 Initiates a TCAP transaction and notifies the destination node that it may not end the transaction.




 Conversation With Permission



 Continues a TCAP transaction and gives the destination node permission to end the transaction.




 Conversation Without Permission



 Continues a TCAP transaction and notifies the destination node that it may not end the transaction.




 Response



 Ends a TCAP transaction.




 Abort



 Terminates a TCAP without sending pending components.



















2.1.7	 ITU-T Transaction Types





The TCAP layer supports the following ITU-T transaction types: 





 Transaction Type



 Description




 Unidirectional



 Sends information in one direction only, with no reply expected.  No TCAP transaction is established.




 Begin Transaction



 Initiates a TCAP transaction.




 Continue Transaction



 Continues a TCAP transaction and can be used to transfer data in either direction.




 End Transaction



 Ends a TCAP transaction.




 Abort



 Terminates a TCAP without sending pending components.



















2.1.8	 TCAP Components





TCAP transactions are composed of components, which are remote operation invocations, or invokes, and responses to invokes. Each TCAP message (Begin, Continue, End, Query w/Permission, Response, etc.) is composed of zero or more components.  Each component may optionally have application-specific parameters associated with it. Component parameters are not interpreted by the TCAP layer but are passed on to the destination application.



The ANSI and ITU-T standards define a fairly compatible set of component types: 





 Component Type



 Description




 Invoke [Last | Not Last]



 Invokes a remote operation.




 Return Result [Last | Not Last]



 Reply for a successful operation invocation




 Return Error



 Reply for an unsuccessful operation invocation




 Reject



 Reports the receipt and rejection of an incorrect transaction package or component; this may be generated by either the TCAP layer itself or the application.




 Cancel



 Local operation only; cancels an outstanding invoke between the application and the TCAP layer, but does not notify the far end.















Note:   The [Last | Not Last] designation for invokes applies only to ANSI standards; the [Last | Not Last] designation for Return Result components applies to both ANSI and ITU-T


Each invoke component is identified by a unique Invoke ID, assigned by the application that originates the invoke. The Invoke ID is returned in the response, and allows the originator to correlate the reply with the invoke operation to which  it belongs.


 



A receiver of an invoke component can also generate a linked invoke in response to the original invoke received - for example, to collect more information from the sending node before generating the response to the original invoke. The linked invoke carries its own unique Invoke ID plus the Invoke ID of the original invoke, called the correlation ID in ANSI or the linked ID in ITU-T, to allow the originating application to associate the linked invoke with its original invoke.



Finally, in ITU-T only, an invoke operation is assigned by the application to one of four classes, numbered 1 - 4. The class designation specifies under what conditions a response is expected, and thus determines what a timeout implies about the success or failure of the operation. 





 Class Type



 Description




 Class 1



 Both successes and failures are reported; a timeout is an "abnormal" failure.




 Class 2



 Only failure is reported; a timeout implies successful completion.




 Class 3



 Only success is reported; a timeout implies a failed operation.




 Class 4



 Neither success or failure is reported; no interpretation of timeout.



















2.1.9	 Message Lengths and Segmentation





The maximum size of a TCAP transaction, including transaction part, component parts, and application parameters is approximately 254 bytes, possibly less if global titles are used in SCCP addresses. The TCAP layer, and the underlying SCCP connectionless service that it uses, provide no mechanism for segmenting and reassembling application transactions.



If an application has transactions (invokes or responses) that exceed the maximum size, it must provide its own segmentation and reassembly, using either the Last/Not Last designation for invokes (ANSI only) or responses, or some other application-specific means.






2.2	 Asynchronous Communication Model





Once an application is bound to a TCAP SAP, it may initiate outgoing transaction requests and/or receive incoming transaction requests from far signaling points (SPs).  






2.2.1	 Transaction Requests





Outgoing transaction requests are generated by calling TCAP API primitives.  Successful completion of the API primitive implies that a request message has been queued to the TCAP layer on the TX Series processor. The TCAP layer processes the request at some future point, typically resulting in either an outgoing TCAP message to another SP or possibly a status indication back to the requesting application.



When a TCAP transaction request fails after reaching the TCAP layer in the TX Series board, the application is notified of the failure via an asynchronous status indication message.






2.2.2	 Receiving Incoming Transactions and Status Indications





Applications receive incoming transactions (invokes and responses) and status indications via the TCAPRetrieveMessage primitive.  This primitive checks for an incoming message and returns an indication of whether or not a message is available.  When an incoming message is received, TCAPRetrieveMessage decodes the TCAP message, copies the data portion to the buffer provided by the caller, and reports other information regarding the event (such as the originating point code and subsystem number) back to the calling application.  The application must periodically call this primitive to receive messages from the TCAP layer.



To allow applications more flexibility in handling multiple devices, mechanisms are provided to allow the calling application to be notified when a TCAP message is available for it without having to "poll" the TX board by periodically calling TCAPRetrieveMessage. These mechanisms vary from operating system to operating system and are described in the following subsections.






2.2.3	 UnixWare and Solaris Systems





The TCAP API makes the device file descriptor (or handle) used to access the TX Series board device driver available to the application via the TCAPSyncObj primitive. On UnixWare and Solaris systems, this is a file descriptor for an open streams device. 



The application may use this file descriptor with the poll or select system calls to determine when a message from the SCCP layer is available.  Once poll or select has indicated that a pending I/O operation has completed on the TCAP API file descriptor, the application should then call TCAPRetrieveMessage to read and decode the message.






2.2.4	 Windows NT





On Windows NT systems, an application can obtain a handle (via the TCAPSyncObj primitive) which can be used with the WIN32 WaitForSingleObject or WaitForMultipleObjects system calls to efficiently perform asynchronous, or non-blocking, I/O.  This allows an application to determine when a message from a single TX Series board or from any TX Series board in a multiple board installation is available without having to periodically call TCAPRetrieveMessage to "poll" each TX Series device. 



To access this "synchronization handle" the application performs the following.


    


  1. After calling TCAPInitAPI, the application calls TCAPSyncObj to obtain the synchronization handle.
    

    

  2. The application uses the synchronization handle WaitForSingleObject or WaitForMultipleObjects to check or wait for a message.  
    

    

  3. When WaitForSingleObject or WaitForMultipleObjects indicates an event completion on the corresponding TX Series board synchronization handle, the application then calls TCAPRetrieveMessage (passing the original handle from TCAPInitAPI, not the synchronization handle) to retrieve and decode the packet.
    

    
 
    








2.2.5	 Multi-threading Considerations





In a multi-threaded application, any thread can generate a transaction request (either initiating a new transaction, or responding to a transaction initiated by a far SP).  However, there should be a single receiver thread which receives all asynchronous events from the TCAP layer (new transaction invocations, transaction responses, and status indications) and routes them to the proper "transaction thread" based on the user dialog ID or other transaction information. 



Consider, for example, an application which consisted of a main thread, which spawned a "child transaction thread" whenever it wanted to initiate a new transaction. The transaction thread would be responsible for initiating the transaction request, collecting the response, and taking the appropriate action.  The application could have many simultaneous transactions, and hence transaction threads, active at any given time. 



Multiple transaction threads could generate the transaction requests in any order; the requests would be processed by the TCAP layer in the order that they were received. If each transaction thread then called TCAPRetrieveMessage to retrieve the response to its transaction request, there would be no guarantee that the TCAP message returned by TCAPRetrieveMessage would be associated with the calling thread's transaction. The first thread to call TCAPRetrieveMessage when a message is pending would receive the first pending message, regardless of which transaction it was associated with (in fact, the incoming message could be a new transaction request from a far SP or a network status indication message).



Instead, the main thread itself or a separate child "receiver thread" should be the only caller of TCAPRetrieveMessage.  It can then analyze each incoming event and either route it to the proper child transaction thread or, in the case of a new incoming transaction, create a new child transaction thread to handle the incoming transaction request. 


Note:  In a multi-threaded application like the one described here, the TCAPInitAPI primitive should be called from the parent thread before any of the other API primitives are called by any of the other threads.





2.3	 TCAP API Procedures





The following subsections describe how the TCAP API is used to implement application transactions, illustrated by some simple transaction examples.






2.3.1	 Initialization/Binding





Before calling any other API primitives, the application must first call the TCAPInitAPI primitive to initialize the API. This primitive "opens" the TX Series device driver and allocates any other resources needed by the API. It must be called independently for each TX Series board in a system.  When the TCAP API is no longer needed (for example, during a graceful system shutdown) the TCAPTermAPI primitive is called to free up any resources allocated by the API (again, called once for each TX Series board that was initialized).



The binding phase establishes the application as a user of the TCAP interface, identifying a particular SAP. Binding consists of a single BIND request from the application to TCAP, for which there is no response (it always succeeds). Errors in the binding process are noted by alarms generated by the TCAP task. If an application attempts to bind to a SAP for which an application was previously bound, the older binding is removed and the new binding is established. 


Note:  If the application requires that concerned point codes be notified of the application subsystem becoming available, the application should call the TCAPStateReq primitive to generate SCCP Subsystem-Allowed (SSA) messages to all concerned point codes after binding but before attempting any data transfer.


An application may subsequently disassociate itself from a SAP by generating an UNBIND request.


Note:  If the SCCP configuration specified one or more concerned point codes for the associated subsystem number, this results in those nodes being notified that the subsystem is now unavailable.

 



Figure 3.	 TCAP Application Initialization and Binding



 






2.3.2	 Transaction Requests





Generating a TCAP transaction requires the following steps (all data structures associated with a transaction are specified in Chapter 3).


    


  1. Allocating a memory buffer large enough for the transaction request.  A TCAP transaction buffer must be at least TCAP_MSG_SIZE bytes.
    

    

  2. Assign a unique user dialog ID (suDlgId) for the transaction (if its the first request belonging to this transaction) and populate the transaction information data structure with the message type, dialog ID(s), the originating address, destination address, and quality of service parameters.
    

    

  3. Initialize the transaction request with the TCAPInitTrans primitive.
    

    

  4. Add 1 or more components to the request with the TCAPAddComp primitive. Each invoke component must also have a unique (within the current dialog ID) invoke ID assigned.
    

    

  5. Send the transaction to the destination SP by calling the TCAPTransRqst primitive.
    




The following subsections illustrate the use of the TCAP API primitives to implement a simple request/response transaction and a more complex conversational linked transaction. The ITU-T and ANSI variants are shown separately to help clarify their conceptual differences.






2.3.3	 Simple Request/Response Transaction





The simple transaction illustrated below consists of a transaction BEGIN (ITU-T) / Query With Permission (ANSI) request with a single INVOKE component, followed by a single END (ITU-T) / RESPONSE (ANSI)  message with a single RETURN RESULT component.  An example of such a transaction might be a request from a service switching point (SSP) to a service control point (SCP) to translate an 800 number into a subscriber directory number.



Figure 4 below illustrates the ANSI version of the simple transaction; Figure 5 shows the ITU-T version.


 



Figure 4.	 Simple Transaction - ANSI



 




Figure 5.	 Simple Transaction - ITU-T






2.3.4	 Conversational/Linked Transaction





An example of a slightly more complicated conversational/linked transaction is shown in Figure 6 (ANSI) and Figure 7 (ITU-T). An example of this type of transaction might be as follows.


    


  1. A switching application issues an INVOKE on behalf of a subscriber to initiate a feature in a remote switch.
    

    

  2. The remote switch decides it does not have enough information to carry out the feature invocation; so, it responds with a new INVOKE (linked to the original invoke) to play and announcement to the subscriber and collect digits.
    

    

  3. The original switch collects the digits and returns them as the result to INVOKE #2.
    

    

  4. The remote switch now completes the feature invocation and returns the result to INVOKE #1.
    

    
 
    

    

    Figure 6.	 Conversational/Linked Transaction - ANSI
    

    
 
    

    

    Figure 7.	 Conversational/Linked Transaction - ITU-T
    







2.3.5	 Handling Abnormal Conditions





A TCAP message consists of two parts, a transaction portion, and a component portion. If a TCAP message has an invalid transaction portion, it generally causes a P-Abort (which terminates the transaction) or it is ignored (which doesn't terminate the transaction). If a TCAP message has an invalid component, a Reject component is generated, but the transaction generally isn't closed. The various possibilities are addressed in this section. 






2.3.6	 Invalid Transaction Portions





A TCAP transaction may be received that has an invalid Transaction portion. The Transaction portion contains the transaction type (i.e. BEGIN (ITU-T) / Query (ANSI) ), and any required transaction ID's (TID's). Generally, if an error is detected and a valid transaction ID can be found, a P-Abort is returned to the sender, a P-Abort indication is delivered to the receiver, and the transaction is closed. However, if the TCAP stack can't find a valid transaction ID, it ignores the message. No response is returned to the sender, and no indication is sent to the receiver. As the message is ignored, any transaction that was open is still open.



The transaction shown below illustrates a transaction where an ITU-T TCAP message is received that doesn't have a valid message type (Begin, Continue, End). The message does have a valid Originating Transaction ID, however. The TCAP stack recognizes the invalid message, and sends a P-Abort to the sender. Also, a P-Abort indication is delivered to the receiving application.



Figure 8 below illustrates the ITU-T version of the invalid transaction.


 



Figure 8.	 Invalid Transaction - ITU-T






2.3.7	 Stranded Transactions





Once opened by a Begin (ITU-T) or Query (ANSI), transactions do not time-out. Unless Aborted or completed using End (ITU-T) or Response (ANSI), the transaction will remain open. If transactions are not closed, then over time, the TCAP stack will run out of transaction contexts (MAX_TCAP_DIALOGS in configuration file) and fail.



Applications that receive Begin (ITU-T) or Query w/Permission (ANSI) messages should insure that these transactions are eventually closed, through a time-out or some other means. A transaction is closed if one of the following occur:




If none of these occur, the user application must insure that the transaction is closed eventually.


Note:  In the ITU-T protocol, there are Invoke component time-outs (see below), but these are not the same as transaction time-outs.





2.3.8	 Invalid Component in a Begin/Query Message





If the TCAP stack receives a Begin (ITU_T) or Query (ANSI) message with an invalid component, it will pass a Reject component up to the receiving application, but will not automatically send the Reject component back to the Sender. This occurs because the stack is unsure whether to End the transaction, as another component in the message may be valid. In this case, the application must send a Continue or an End with no components. The TCAP stack will attach the Reject component and send it to the original sender.



An example of an invalid component would be if a Return Result or Return Error component is received with an Invoke ID that doesn't correspond to an outstanding Invoke component. In this case, a Reject component is returned to the sender with whatever Invoke ID it was sent with. If the TCAP stack receives a component with an invalid or missing Invoke ID, a Reject component is returned to the sender with an Invoke ID tag of ASN.1 Universal NULL (0x05). The Invoke ID length is set to zero.



In Figure 9 below, an invalid Invoke component is received. The TCAP stack recognizes the error, and passes up a Reject component to the receiving application. Since the Reject component is contained in a Begin message, the receiving application sends an End message with NO components. The TCAP stack attaches the Reject component(it has saved the component), and sends it to the original sender. The transaction is now closed.


 



Figure 9.	 Begin Message with Invalid Component - ITU-T



 






2.3.9	 Invalid Component in a Continue/Conversation Message





If the TCAP stack receives a Continue (ITU-T) or Conversation (ANSI) message with a bad component, it automatically sends a Continue or Conversation with the Reject component back to the sender, and sends the Reject component to the receiving application. In this case, the application doesn't have to send any response.



In Figure 10, after sending an Invoke component, a Continue message with an invalid linked Invoke component is received. The TCAP stack automatically sends a Continue message  with a Reject component back to the sender.



In addition, a Continue message with a Reject component is passed to the receiving application. The transaction is still open and can continue or be closed.


 



Figure 10.	 Continue Message with Invalid Component - ITU-T






2.3.10	 Invalid Component in an End/Response Message





If the TCAP stack receives an End (ITU-T) or Response (ANSI) message with a bad component, it sends the Reject up to the receiving application, but nothing back to the sender, as the Sender has already closed the transaction. In this case, the application doesn't have to send any response.


 



Figure 11.	 End Message with Invalid Component - ITU-T



 






2.3.11	 Invoke Time-outs (ITU_T only)





Only the ITU-T protocol implements invoke time-outs. If an application sends an Invoke component, and doesn't receive a Return Result Last, Return Error, or a Reject with the same Invoke ID within a configured time, the Invoke will time-out. A message type of TCAP_LOC_IND is returned with a TCAP_CANCEL component. The application at this point should close the transaction by an End (ITU-T) or a User Abort. 


 



Figure 12.	 Invoke Timeout - ITU-T



 






2.3.12	 Invalid Component in a Multiple Component Message





A TCAP message may contain multiple components. As soon as an invalid component is detected by the TCAP stack, any valid components are indicated to the receiving application along with the rejected component. Any components after the rejected component are ignored. 



For example if a TCAP message is received with three components, and the second component is invalid, the first valid component and the second rejected component are indicated to the receiving application. The third valid component is ignored and not indicated to the receiving application.






2.3.13	 Status and Notify Indications





The application may be notified of errors encountered in processing transaction requests by the TCAP layer at any time with unsolicited TCAP Status Indication messages (event type TCAP_EVENT_STA_IND).  The status field returned in the status indication message indicates the reason for the error.



Transaction requests that could not be delivered by the SCCP layer due to routing errors, global title translation failures, or temporary network outages, for example, are returned to the originating application (if requested via the SCCP quality of service parameters) via unsolicited TCAP Notify Indication messages (event type TCAP_EVENT_NOT_IND).  The notify indication includes a "return cause" field which identifies the reason the message could not be delivered.






2.3.14	 Signaling Point and Subsystem Status Procedures





The TCAP API also contains several primitives which provide TCAP applications with access to the SCCP layer facilities for maintaining signaling point and subsystem status between the calling application's system and backup signaling points or concerned signaling points.


 






2.3.15	 Coordinated State Change





An application may request that its subsystem be taken out of service (and have all traffic routed to its backup point code) by invoking the TCAPStateReq primitive with a request type of TCAP_COORDREQ.  This generates a SCCP Subsystem-Out-Of-Service-Request (SOR) to the backup signaling point (as specified in the SCCP SAP configuration).  The application receives an incoming TCAP event with an event type of TCAP_COORDCFM when the backup signaling point returns a Subsystem-Out-Of-Service-Grant (SOG), as shown in Figure 13.


 



Figure 13.	 Subsystem Out-of-Service Request




If the backup signaling point fails to return a SOG message and the grant request times out, the TCAP_COORDCFM event indication will contain a special value of UOR_DENIED in the subsystem multiplicity indicator (smi) field, implying that the application should not go out of service.


 



Alternatively, the backup point code may request to go out of service by sending the SOR message.  This results in the application receiving an TCAP_COORDIND event (Figure 14). The application invokes the TCAPStateResp primitive with an event type of TCAP_COORDRESP to accept the request and return the SOG message. 


 



Figure 14.	 Backup Subsystem Out-of-Service Indication






2.3.16	 Subsystem State Changes





The application may notify all concerned point codes of a change in its state by invoking the TCAPStateReq primitive with a status of SS_IS (in service) or SS_OOS (out of service).  This request generates a Subsystem Available (SSA) or Subsystem Prohibited (SSP) message to all concerned signaling points as specified by the SCCP configuration of the application 's SAP (an example of this is shown in Section 2.3.1, Initialization/Binding).



Likewise, when the SCCP task receives messages from concerned signaling points indicating that their status has changed, the application receives an unsolicited TCAP event with an event type of  TCAP_SSNSTIND (subsystem status) or TCAP_PCSTIND  (point code status) .






2.3.17	 Remote Signaling Point Failures





An application may monitor the status of remote signaling points by specifying a list of concerned point codes in the SCCP user SAP configuration corresponding to that application.



If all routes to a concerned point code (CPC) become unavailable, the application receives an unsolicited TCAP event with an event type of  TCAP_PCSTIND with the status field set to SP_INACC (signaling point inaccessible).  In addition, the application receives a receives an unsolicited TCAP event with an event type of  TCAP_SSNSTIND with the status field set to SS_OOS (subsystem out-of-service) for each known subsystem at that signaling point.  



Similarly, if the MTP layer receives an indication from the remote SP that the SCCP user part is unavailable, the application will receive the TCAP_SSNSTIND (SS_OOS) event for each known subsystem at that signaling point (but not the TCAP_PCSTIND event indication, since in this case just the SCCP user part and not the entire signaling point has failed).



When communication with the affected signaling point is restored, the application receives an unsolicited TCAP event with an event type of  TCAP_PCSTIND and the status field set to SP_ACC (SP accessible).  At this point the SCCP layer initiates subsystem status testing of all known subsystems at the affected SP.  When a subsystem available message is returned by the affected SP, the application receives a TCAP event with an event type of  TCAP_SSNSTIND and the status field set to SS_IS (subsystem in-service).  At this point the application may re-establish communication with the affected SP/subsystem.



Figure 15 shows and example of remote signaling point failure and recovery procedures.


 



Figure 15.	 Remote Signaling Point Failure and Recovery






2.4	 TCAP Management API





A separate API is provided for configuration and management of the TCAP layer.  This API contains primitives for:




Unlike the normal transaction primitives, which operate asynchronously, the management API operates in request/response mode.  That is, calling an API primitive sends a request to the board and waits for a response, blocking the calling application until the response is received.  Results are returned immediately to the calling application when the API primitive returns. It is expected that the management API primitives will typically be used by a separate application from the normal transaction primitives, although this is not required.






2.4.1	 TCAP Configuration Primitives





The TCAP layer supports the following configuration entities.



General   The general configuration defines the resource allocation for the TCAP layer: maximum number of user SAPs, maximum number of simultaneous dialogs, and maximum number of outstanding invokes.  The general configuration is loaded only once at system boot time and must be loaded before any other configuration entities.



User SAPs   One user SAP is defined for each application using the TCAP layer services.  A user SAP is associated with a single subsystem number and protocol switch type (ANSI-88, ANSI-92, ITU-88, or ITU-92). The user SAP defines the default timer values for invokes issued on the SAP and identifies the SCCP user SAP to be used.  User SAPs (up to the maximum number specified in the general configuration) may be added any time after the general configuration has been set.






In addition to the API primitives, a standard configuration application is provided to read the TCAP configuration from a text file and download the configuration to the TCAP task running on the TX Series board (see the SS7 Installation and Configuration Manual). The configuration application (tcapcfg) is distributed in both source and executable form; the executable may be used as a stand-alone configuration tool or the source can be used as a guide to developing a configuration utility with the TCAP management API.


 






2.4.2	 Control Requests





The TCAP management control request primitive allows the caller to perform the following operations.






2.4.3	 Statistics Request





A statistics request is provided to collect statistics on an individual TCAP SAP.  Statistics provided include counts of the number of each transaction package type and each component type transmitted and received, as well as counts of the number of times various abnormal events have occurred.






2.5	 Unsolicited Alarms





Any of the tasks on the TX Series processor (including any of the SS7 layers) may generate unsolicited alarms at any time to indicate abnormal events or changes in the status of some entity.  For many host operating systems, a standard application is provided (in both source and executable form) to receive alarms and write them to a disk file on the host.  Systems employing other host operating systems, or those which require customized alarm handling, may implement their own alarm handlers.  











 
    (Page 1 of 1 in this chapter)




 




tech_support@nmss.com



Copyright © 1999, Natural MicroSystems, Inc.   All rights
reserved.