You are here: SwitchKit® Development Environment - Installation and Maintenance Guide > 7 Device Connectivity > LLC: Application Load Balancing for TCAP

LLC: Application Load Balancing for TCAP

This feature facilitates routing between the LLC and applications, based on the number of Inbound Initial Dialogue Primitives (IDP) each registered SwitchKit application has. The LLC is capable of performing the following:

• Monitoring dialogue states

• Providing a registration mechanism for SwitchKit applications to receive TCAP-related PPLEventIndication messages based on a combination of stack and Sub System Number (SSN).

• Routing TCAP-related PPLEventIndication messages to the registered application with the lowest number of active dialogues

How to Keep Track of Dialogue States

Once dialogue monitoring has been enabled, the LLC automatically keeps track of dialogue states. Each state can be derived from any one of the multiple TCAP primitives listed in the next table. TCAP Primitives are extracted from TCAP-related PPLEvent messages received by the LLC.

The following terms represent the three possible states the LLC can derive within its dialogue management system for a given dialogue ID:

• NOT_ALLOCATED - Dialogue ID is not allocated.

• ALLOCATED_A_SIDE - Dialogue ID has been allocated by an application using a PPLEventRequest message.

• ALLOCATED_B_SIDE - Dialogue ID has been allocated by the CSP using a PPLEventIndication message. The next table shows the type of primitive for each LLC state. Primitives are both requests and indications, unless shown otherwise.

Important! The next table contains the following notation.

** If a TCAP_RESTART Event is received, all Dialogues on that stack should end (enter the NOT_ALLOCATED state).
*** Detection of a Dialogue Termination TLV always results in the LLC putting that dialogue into the NOT_ALLOCATED state. The LLC does not check these events for the dialogue termination TLVs.

Event Criteria (TCAP Primitives) | APP Initiated | Network Initiated | Receive Dialogue | LLC Action
--- | --- | --- | --- | ---
| A Side | B Side Event | B Side Event |
TC-BEGIN | X | X |  | Allocate
TC_QUERY_WITH_PERMISSION | X | X |  | Allocate
TC_QUERY_WITHOUT_PERMISSION | X | X |  | Allocate
TC_BEGIN_PRIMITIVE_SET | X | X |  | Allocate
TC_QUERY_WITH_PERMISSION_PRIMITIVE_SET | X | X |  | Allocate
TC_QUERY_WITHOUT_PERMISSION_PRIMITIVE_SET | X | X |  | Allocate
TC_END |  | X | X | Deallocate
TC_RESPONSE |  | X | X | Deallocate
TC_RESULT_L |  | X | X | Deallocate
TC_RESULT_NL |  | X | X | Deallocate
TC_U_ERROR |  | X | X | Deallocate
TC_L_CANCEL |  | X | X | Deallocate
TC_INVOKE_L |  | X | X | Deallocate
TC_INVOKE_NL |  | X | X | Deallocate
TC_U_REJECT |  | X | X | Deallocate
TC_L_REJECT |  | X | X | Deallocate
TC_R_REJECT |  | X | X | Deallocate
TC_INVOKE |  | X | X | Deallocate
TC_RESPONSE | X |  |  | Deallocate
TC_END | X |  |  | Deallocate
TCAP_RESTART** | X | X |  | Deallocate
TC_RESPONSE_PRIMITIVE_SET*** |  |  |  | Deallocate
TC_END_PRIMITIVE_SET*** |  |  |  | Deallocate
TC_P_ABORT*** |  | X |  | Deallocate
TC_DIALOGUE_TIMEOUT*** |  | X |  | Deallocate
TC_NOTICE*** |  | X |  | Deallocate
TC_TCAP_INITIATED_ABORT*** |  | X |  | Deallocate
TC_U_ABORT*** | X | X |  | Deallocate

As TCAP-related PPL events are passed in and out of the LLC, a dialogue monitor parses each PPL event and derives the current state of each dialogue using the state machine outlined in the next figure.

Diagram of Transitional States

In Finite State Machine Used by the LLC’s Dialogue Monitoring System, each number represents a group of transitional events (TCAP primitives) that result in a particular finite state (Dialogue State). The events (TCAP Primitives) represented by each number are listed in the table and correspond to the transition arrows in the state diagram

Figure 7-2 Finite State Machine Used by the LLC’s Dialogue Monitoring System

.

Dialogue state and application data are then stored for maximum retrieval efficiency using a series of C++ STL containers. Application statistics can then be queried to provide load balancing information such as the number of active dialogues given an application number, or the number of active dialogues given a RoutingID. These statistics are then used by the LLC to determine Best Response Transaction Allocation.

How the LLC Determines Best Response Transaction Allocation

When a PPL event indication with component ID 0x70 (TCAP TUSI) is received by the LLC, it determines whether or not this message is an Initial Dialogue Primitive (IDP). If this is an IDP, then the stack, SSN, and dialogue are extracted from the message and are queried to determine which registered application has the least number of active dialogues. If the numbers are equal, a random application number is chosen. Otherwise, the application number with the lowest number of active dialogues is chosen and the PPL event indication is sent to that application. If the dialogue was activated by the A side (activated by a PPL event request) then the remaining dialogues are sent to the application that activated it.

Limitations/Assumptions/Dependencies

The LLC must be configured for TCAP Routing. In addition to this configuration, to enable TCAP Application Load Balancing you must do the following:

//set the following environment variable to activate the

//LLC's Dialogue Monitor

SK_DIALOGUE_MONITOR=1

//call this SK function from your app

sk_pplTCAPRegister(int what, UBYTE registerType);

//derive the function parameters from the following macros and constants

int what = getSS7TCAP_MultiCard_RoutingID(stackID, ssn);

UBYTE registerType = SK_TCAP_REG_STACK_SSN = 0x02;

See Transaction Capability Application Part.
Tag-Length-Value block. A standardized block that allows data to inserted in a standard way into API messages.
See Programmable Protocol Language.
In PPL, a condition that, when met, drives a state machine (PPL Component) from one state to another, by invoking an associated Primitive. In PPL files, an Event is marked by an arrow and text.
The condition of a component at a given instant. The current "context" of a PPL object, such as Idle, Seizing, Answered. In PPL files, a State is represented by a circle.
A State Machine defines the events (functions) required to drive a channel from one state to another through a graphical interface tool. A State Machine is configured and managed using API Messages or the PPL Tool. Based on the occurrence of an Event, a State Machine drives each channel through its Protocol Tables. It creates one state from another, invoked by an event. Processing is complete when a "normal" state is reached. "Wait" and "Stable" are normal states.