The TCAP leg manager is a new type of event manager that is used within the IPSMGW.

The TCAP Leg Manager

The TCAP leg manager is used within the IPSMGW to manage GSM MAP 'legs'. Each TCAP leg corresponds to a Dialog between the IPSMGW and an external network element such as an SMSC, MSC or HLR.

tcap leg manager
Figure 1. The TCAP Leg Manager

1

The IPSMGW interconnects with a number of external network elements, such as an SMSC, MSC and HLR

2

Features (such as the MAP Proxy), running within the IPSMGW, interact with these external network elements by using the TCAP Leg Manager and TCAP Legs

3

The TCAP Leg Manager is responsible for managing all TCAP Legs that exist within the IPSMGW.

4

The TCAP leg manager provides an API (Application Programming Interface) that Features (such as the MAP Proxy) may use to create, remove and find TCAP Legs. In this particular example, the MAP Proxy feature in interested in two TCAP legs incoming and proxied

5

Each TCAP Leg is associated with a Dialog. The Dialog represents a real protocol session between the IPSMGW and an external network element. Features use the API of the TCAP Leg to operate on the Dialog. For example if the MAP Proxy feature calls refuseDialog() on a TCAP Leg, then the underlying Dialog will be refused by sending an OpenRefuse to the external network element.
Tip

To learn more about the TCAP leg manager and TCAP leg APIs see Introducing the TCAP Leg Manager API
Tip

See What is an Event Manager? to learn more about event managers.
Note

The TCAP leg manager may be used in future releases of Sentinel for other protocols such as INAP and CAP.

Events Processed by the IPSMGW

The IPSMGW receives events from several sources:

Source Received from Examples

GSM MAP

an external MAP network element (such as an SMSC or HLR)

TC-Begin (such as a DialogOpen)
TC-Continue (such as a DialogOpenAccept)
TC-End (such as a DialogOpenRefuse)

SIP

an external SIP network element (such as an S-CSCF)

SIP MESSAGE request

Diameter

the Sentinel mediation layer (related to events from an external OCS)

Extension

external network elements for sessions initiated by features within Sentinel

Timer

timers that features raise using the ServiceTimerProvider

Local

raised internally by Sentinel, as a result of processing other events and instructions

EndSessionEvent, when the Sentinel session has ended (that is, no more TCAP legs, SIP legs or charging instances remain active)

InstructionExecutionFailedEvent, when one or more event manager instructions failed during processing

IPSMGW event-processing algorithm

The IPSMGW extends Sentinel SIP by adding the TCAP Leg Manager. The following diagram is an overview of how the IPSMGW processes events:

ipsmgw event model
Figure 2. Processing Events in the IPSMGW
Tip

See: Sentinel SIP event-processing algorithm for additional detail related to SIP.

As shown above:

1

The IPSMGW receives a real event, such as an DialogOpen request from the SMSC or a SIP MESSAGE and starts an event loop:

Loop

Update Event Managers …​ Process Feature Script Execution Points …​ Process Event Manager Instructions

Until the local event queue is empty.

2

Event managers process the received event. They:

  • update their own state

    For example, the TCAP Leg Manager creates a new leg for an initial DialogOpen request

  • determine if one or more feature script execution points should be triggered for the event

3

If there are any feature script execution points to trigger, then process them; otherwise see if event managers have any instructions to carry out.

4

Process each feature script execution point in turn. Features may update the state of the Charging, TCAP and SIP Leg Managers as they execute. For example, a feature might create a new TCAP leg, or link two TCAP legs.

Once all feature script execution points have been processed, then check if the event managers have any instructions to carry out.

5

Ask each event manager in turn to carry out any pending instructions that have accumulated while processing the event.

Each event manager manages a set of instructions while features are executing. For example, if a feature calls issueOpenRequest(openRequest) on a TcapLeg, then the TCAP leg manager will record a pending instruction of sendTcapMessage.

Once all pending instructions have been processed, then see if there are any events in the local event queue. If the local event queue is empty, then wait for the next real event. Otherwise, de-queue a local event and process it.

6

Event processing ends once the session ends.
Previous page Next page