The HP OpenCall SS7 TCAP API

Hybrid Stacks

HP OpenCall SS7 ITU-T White Book TCAP connects with ANSI SCCP, thus providing ANSI and ITU-T application access to the SS7 network.

Connections for applications using the SCCP ITU-T White Book will be refused, as shown in Figure 6-4 “Hybrid stack: Application Connection”

Figure 6-4 Hybrid stack: Application Connection

General restriction - use of Global Title

The only restriction imposed on ITU-T White Book TCAP applications using a hybrid stack is the use of the Global Title. Only types 1 and 2 of the Global Title are supported, types 3 and 4 are not recognized by ANSI SCCP.

Reverse Hybrid Stacks

HP OpenCall SS7 also provides TCAP ANSI that can connect to ITU-T SCCP Blue Book (ABB). It is called the Reverse Hybrid Stack.

Connections for applications using the SCCP ANSI will be refused, as shown in Figure 6-5 “Reverse Hybrid Stack: Application Connection”

Figure 6-5 Reverse Hybrid Stack: Application Connection

Dialogue Portion

A TCAP application can negotiate the Application Context or transparently transfer user data by using the Dialogue Portion as described in ITU-T White Book TCAP.

ITU-T Blue Book TCAP applications are also supported by the White Book TCAP if the Dialogue Portion is not included in any dialogue handling primitives.

Non-disruptive Service Update

Access to TCAP can be outgoing only, thus allowing a TCAP user to initiate transactions without accepting incoming transactions.

With this feature, a TCAP user can terminate its access to TCAP and update its service, without any transactions with a remote TCAP user being aborted or lost.

Direct Access to the Transaction Sublayer

The TCAP API allows a TCAP user to access the transaction sublayer either indirectly, by using the component sublayer mechanisms, or directly, bypassing the component sublayer.

With direct access to the transaction sublayer, the TCAP user can use an ASN.1 compiler to encode and decode non-standard components, operations and parameters.

Message Priority

You can set the priority of the outgoing messages. If the MTP level 3 becomes congested, it will discard the messages with the lowest priority and keep those with the highest priority. This is set in the TCAP parameter tcx_importance. See “SCCP Service Quality Structure”.

Messages with priority 0 will be discarded at SCCP level if there is remote SP congestion. If the return option is set, a UDTS with the cause of network congestion is returned to the initiator of the message. For other priorities (1 or 2) the messages are given to MTP3 which is responsible for discarding them according to the level of congestion.

The same rule applies to messages coming from the network that must be relayed by SCCP after a translation.

	NOTE: SCCP management messages (SSA, SSP, SST, SOR, SOG) have a default priority of 0. This value can be changed via the SetMgtMsgPriority parameter. Use the cfgSccp command (for a description, see the man page). See also the HP OpenCall SS7 Operations Guide.

Receive Mechanism, Buffering and Test Message

To improve throughput the TCAP API stores incoming messages from the SS7 stack in a buffer. A more_messages parameter is set during the TCX_recv() call to indicate the number of TCAP messages that are still waiting to be received. These messages are received by the user one by one with a TCX_recv() call. Because of this:

The timeout returned by TCX_select_mask(), and used in select(), forces the user to call TCX_cnx_handler() periodically to serve TCAP connections.

The size of the TCX_recv() buffer can be configured with a TCX_control() command.

SS7 Stack Switchover

A 2-host cluster contains two host servers and provides highly available SS7 connectivity and functionality (using redundant software and hardware components). 2-host HP OpenCall SS7 platforms achieve continuous software availability by replicating and synchronizing an SS7 Stack on each of the two hosts. If a failure occurs on one of the hosts, the other will take care of the traffic. The process of moving the activity from one host to the other is known as a switchover.

Controlling the TCP/IP Flow

The default configuration for the API is to send every TCAP message to the SS7 stack immediately. In some cases it may be necessary to optimize message transfer between the API and the SS7 stack. This is always done from the SS7 stack to the API. In the other direction it must be controlled by the user.

When transfer optimization is on, the TCAP API concatenates several TCAP messages in one buffer. This buffer is sent to the SS7 stack provided one of the following conditions is met:

As the API does not use any process signals, in order to fulfil the second condition, the API must be called regularly by the user process to check if the transit time has been exceeded. The call that should be used is the TCX_cnx_handler call. If there is nothing to send or receive, the user may also call TCX_control with OUT_BUFFER_FLUSH_COND.

The command OUT_BUFFER_FLUSH forces the API to send the buffer contents whether the above conditions are satisfied or not.

The transit time for each message is computed depending on the average load at the time when the message is put in the buffer. It varies between two limits, which can be set by the LOW_TRANSIT_TIME and HIGH_TRANSIT_TIME controls.

The OUT_IPC_BUFFER_SIZE command configures the size of the socket internal buffer (refer to setsockopt command).

Transparent SS7 Stack Replication

The replication of the SS7 stack is transparent to all TCAP users. When TCX_open() is called, the TCAP API automatically establishes an IPC channel with each SS7 stack. The TCAP API transparently manages these channels and automatically directs the traffic to the active SS7 stacks. Thus, the TCAP user is only notified of a failure when both SS7 stacks are unable to provide any service.

Figure 6-6 Transparent SS7 Stack Replication

Notification

If one of the active SS7 Stacks handling the traffic fails, all the transactions being handled by this stack are aborted, and the TCAP users are notified through a TC_P_ABORT primitive for each transaction lost. The TCAP user must reset its local timers and state-machines.

Simultaneous Access by Multiple TCAP Users

Multiple TCAP users can simultaneously access TCAP using the same or different SSNs. When the application opens a TCAP connection to the SS7 stack, the connection is assigned an SSN.

If multiple TCAP users use the same SSN to access TCAP, by default all incoming traffic is shared between the TCAP users using a round-robin algorithm. However, if the TCAP Application Message Dispatcher feature is used, incoming messages are shared between TCAP users using a customer-supplied algorithm (see Chapter 7 “Using the TCAP Application Message Dispatcher”, and the HP OpenCall SS7 Welcome Guide).

It is possible to assign multiple SSNs to a single TCAP user or multiple TCAP users on a single or multiple systems.

Single TCAP User

A single TCAP user can establish multiple TCAP stack connections. Each connection can be given identical or different SSN values.

Figure 6-7 “Single TCAP User with Multiple TCAP Stack Connections” shows how a single TCAP user, using TCX_open(), can open two TCAP stack connections identified as cnx_id1 and cnx_id2. cnx_id1 is assigned the SSN value SSNy, and cnx_id2 is assigned the SSN value SSNx.

Thus, all dialogues/transactions destined for SSNx and SSNy are received by the same TCAP user.

Figure 6-7 Single TCAP User with Multiple TCAP Stack Connections

Multiple TCAP Users

If several TCAP users are connected with the same SSN on the same stack, by default, all incoming transactions/dialogues are shared between them using a round-robin algorithm. All incoming TC_BEGINs are distributed statistically. All other transaction primitives are sent to the user handling the transaction.

The maximum number of connections is 32, with up to 8 SSNs.

Figure 6-8 “Multiple TCAP Users on the SS7 Stack” shows two TCAP users connected the SS7 Stack. Each stack connection is assigned an SSN value. Both TCAP USER1 and TCAP USER2 have 3 stack connections each. Each stack connection is assigned an SSN value.

All the stack connections belonging to TCAP USER2 have the same SSN values as the stack connections belonging to TCAP USER1. Hence, all transactions/dialogues routed to SSNy, SSNx and SSNz are shared between TCAP USER1 and TCAP USER2.

Figure 6-8 Multiple TCAP Users on the SS7 Stack

Take-over of TCAP Connections

The application can make active a second connection with the same application_id and instance_id as an already open/active connection. When this is done the first connection no longer accepts new incoming dialogues but continues to process dialogues in progress. In the following figure, two sets of replicate connections are shown, each set having the same SSN.

Figure 6-9 open/active, open/active and open/non-active, open/non-active

Active and non-active

The state of active and non-active is the responsibility of two identifiers, instance_id and application_id. The open/active connections accept traffic. The open/non-active connections have the same application_id and instance_id as the open/active connections but do not accept any new incoming dialogues. The application needs to make active the non-active connections in order for them to begin processing traffic.

If a second connection was previously configured, TCAP connection take-over occurs automatically if the first connection goes down. TCAP connection take-over can also occur on the specific request of an API. In this case the first connection no longer accepts new traffic but continues to process dialogs in progress. All new traffic uses the second connection.

application_id

The application_id is a user-application identifier.

See “Creating TCAP Stack Connections Using TCX_open()”.

Load sharing is possible by setting up several connections with the same application_id and different instance_id and by distributing in-coming traffic over these connections. This assumes that all instances of an application_id are connected on the same SSN.

instance_id

The instance_id is defined within an application_id, identifying an instance of the application, and is exclusive.

See “Creating TCAP Stack Connections Using TCX_open()”.

Open/active to open/non-active

When the connection in the open/active mode goes to open/non-active two main events occur:

Non-active to closed

To close the open/non-active connection you need to call TCX_close. Otherwise the connection will stay open/non-active. If you want the connection to be automatically closed, you can set the CloseOnCreate option to YES using the cfgTcap command (for a description, see the man page).

Figure 6-11 closed, open/active and open/active, open/non-active

Using ITU-T White Book TCAP for ITU-T Blue Book TCAP Applications

To run an ITU-T Blue Book TCAP application using the ITU-T White Book version of TCAP, you must observe the following conditions:

Called and Calling Party Address

You can set the called and calling party address from TCAP by setting parameters in file sys.<className>_TDx.tcap. You can change the calling address specified in TC_CONTINUE, TC_END, or TC_U_ABORT when TCAP receives a TC_BEGIN from the network.

To do this, use the cfgTcap command (for a description, see the man page). See also the HP OpenCall SS7 Operations Guide.

You can also control what information is stored in the called address by TCAP when routing on Global Title. It is used only after receiving TC_BEGIN or TC_QUERY. It does not concern the application; the application will receive the called address without any modification. This address is reused as the calling address for each outgoing TCAP message.