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 sytem 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 Excel platform 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;