Introduction

The SS7 stack supplies a default dispatching algorithm (round robin). Using the TCAP Application Message Dispatcher, customers supply their own dispatching algorithm which replaces the default algorithm supplied by the stack.

If the TCAP Application Message Dispatcher is enabled and the dispatching library file is not found at the start-up of the stack, a LOG is generated and the stack does not start.

The following table presents a few of the messages used in this chapter.

Table 7-1 ITU and ANSI Versions of Messages

ITU Version

ANSI Version

Meaning

TC-BEGIN

TC-QUERY-WITH-PERMISSION

TC-QUERY-WITHOUT-PERMISSION

Message that begins a transaction.

TC-CONTINUE

TC-CONVERSATION-WITH-PERMISSION

TC-CONVERSATION-WITHOUT-PERMISSION

Message belonging to an established transaction.

TC-UNI

Uni-directional message (not belonging to a transaction).

Enabling and Disabling

TCAP Application Message Dispatcher is enabled and disabled using the cfgTcap command (for a description, see the man page).

If TCAP Application Message Dispatcher is enabled, a client supplied shared library named TCAProuter.<className>.so must be provided in the /opt/OC/lib directory.




	NOTE: If necessary, the shared library directory can be changed by modifying the `TCAProuterPath` variable in the [<classname>] section of the `global.conf` configuration file.

TCAP Application Message Dispatcher is enabled or disabled globally for all applications connected to the SS7 stack. Consequently, if the dispatcher is enabled, the customer-supplied library functions must route all incoming TC-BEGIN and TC-UNI messages for all applications.

Default Dispatching Algorithm

The default algorithm supplied by the stack is round robin. Figure 7-1 “Round Robin Algorithm” illustrates this algorithm for the case of four TCAP users connected to the same SSN.

Figure 7-1 Round Robin Algorithm

As shown in the figure, incoming TC-BEGIN and TC-UNI messages are distributed to each TCAP user connected to the same SSN, application id, and instance id, strictly in turn. For example, suppose that User 4 is the most “appropriate” user to handle the 2nd TC-BEGIN. The round robin algorithm gives this message to User 3 (since this algorithm has no way of knowing that User 4 is the most “appropriate” user).

Customer-Supplied Dispatching Algorithm

In this case, the customer supplies the dispatching algorithm to be used (in the form of a shared library loaded by the stack).

Figure 7-2 “Customer-Supplied Dispatching Algorithm” illustrates the role of a customer-supplied dispatching algorithm.

Figure 7-2 Customer-Supplied Dispatching Algorithm

Dispatching Outgoing Messages

The customer-supplied dispatching algorithm is not involved in the dispatching of outgoing TCAP messages. The dispatching of such TCAP messages is the concern of the destination stack.

ITU and ANSI Messages

In the discussion on TCAP-Layer application based routing in this document, the ITU messages are used. However, everything said about ITU messages also applies to their ANSI equivalents (see Table 7-1 “ITU and ANSI Versions of Messages”).

Dispatching Incoming `TC-BEGIN` and `TC-UNI` Messages

If the TCAP Application Message Dispatcher is enabled, TCAP layer dispatching is performed as shown in Figure 7-2 “Customer-Supplied Dispatching Algorithm”. When the SS7 stack receives a TC-BEGIN or TC-UNI message (or their ANSI equivalents), it asks the customer-supplied dispatching algorithm to make a dispatching decision. The SS7 stack then routes the message to the TCAP user selected by the dispatching algorithm.

Dispatching Incoming `TC-CONTINUE` and `TC-END` Messages

For TC-CONTINUE and TC-END messages (and their ANSI equivalents), the customer-supplied dispatching algorithm is not involved in the dispatching decision. These messages concern an existing transaction, so the stack routes them directly to the TCAP user associated with the transaction.

Distributing Incoming Transactions

There are a number of ways of distributing incoming transactions.

Some examples are:

Based on the originating point code, or on a value within the message itself, such as a free phone number or a ported number. For example, the customer defines ranges of telephone numbers (R1, R2, R3, R4, etc.). Messages with a telephone number within R1 are routed to application A1, those within R2 are routed to application A2, etc.
Randomly or in a round robin fashion.
Based on the current workload. If an application is overloaded, then the customer-supplied dispatching algorithm routes the message to another application (or filters, or deletes the message).
Giving more traffic to one application than to the others.




	NOTE: The shared library may implement a separate dispatch algorithm for different SSNs (for example, see Figure 7-3 “Example of Dispatching Algorithms”).

Identifying Application Instances (TCAP Users)

The identification of an application instance is passed between the stack and the customer-provided functions through a structure of type tcx_application_info.

This structure contains the applicationID and the instanceID. Each application instance must be uniquely identified through the combination of an applicationID and an instanceID.

Applications Must Connect Using `TCX_open`()

Applications using TCAP Application Message Dispatcher must connect using the API function TCX_open().

One of the parameters of this function is a pointer to a structure of type tcx_application_info containing an applicationID and an instanceID.

Introduction

Technical documentation

» Table of Contents