You are here: SwitchKit 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 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 |
Receive |
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;