Description

Feature name

Reorigination

Applicable contexts

SS7 service

SAS Support

No

Prerequisite Features

Classify Call Scenario Feature

The reorigination capability is needed when:

  • Roaming partners are triggering calls with CAMELv1.

  • Roaming partners are triggering calls with CAPv2, and cannot send the ERB(disconnect) in the same TCAP message as the ACR)(see CAMEL2 issue).

  • The calling party number is lost in the ISUP signalling when traversing an international carrier. In this case Sentinel must store the calling party number and set it in the connect. As setting the calling party number is not supported in CAMEL, this capability requires INAP CS1, CS2, or a proprietary variant. See Noldus​[1] section 3.6.3 Short Number Dialling with CLI Guarantee pp.82. Currently not supported in Sentinel.

In these cases, the call is reoriginated to the HPLMN using a pool of special routing numbers. The reoriginated call is re-triggered from the HPLMN MSC.

The Reorigination feature should run at one of the pre credit check feature execution points for both the original InitialDP and the reoriginated InitialDP. The Reorigination feature uses the reorigination-correlation-ra to choose the special routing number, and to store data from the original InitialDP that should be correlated with the reoriginated InitialDP.

Tip See Correlation Resource Adaptor to understand how the reorigination-correlation-ra works and how it can be configured
Note If the dialog should not be reoriginated, or represent a reoriginated dialog, then the Reorigination feature will silently end to allow subsequent features to process the InitialDP.

The two phases of roaming reorigination

  • Reoriginating a session. The Reorigination feature analyses the InitialDP stored in session state to decide if it should be reoriginated. If the dialog should be reoriginated, then it chooses a free special routing address and routes the call to this special routing address. The reoriginated call may then be re-triggered from the HPLMN MSC

  • Receiving a reoriginated trigger.

Session state inputs and outputs

Inputs

Name Type Format Description Behaviour if null/invalid

SentinelSelectionKey

com.opencloud.sentinel.common.SentinelSelectionKey

selection key (for example, <platform>::::)

For selecting configuration data

Report featureCannotStart, featureHasFinished

InitialDPArg

com.opencloud.slee.resources.cgin.cap_v1.CAP1InitialDPArg

CAP-DataTypes.InitialDPArg

InitialDP which triggered this session — CalledPartyBCDNumber may be used in identifying reoriginated calls and may be modified

Runtime exception to be handled by feature runner

CallType

com.opencloud.sentinel.common.CallType

One of: MobileOriginating, MobileTerminating, MobileForwarded, NetworkInitiated, EmergencyCall

Session type of this call

Call will not be reoriginated or identified as reoriginated

RoamingIndicator

Boolean

true or false

Indicates whether this is a roaming call

Reorigination will not be attempted

Outputs

Name Type Format Description

InitialDPArg

com.opencloud.slee.resources.cgin.cap_v1.CAP1InitialDPArg

CAP-DataTypes.InitialDPArg

CalledPartyBCDNumber be restored or replaced if the call has or will be reoriginated

RoamingIndicator

Boolean

true or false

Will be set to true if this call is a reoriginated request, otherwise unchanged

CCConnectArg

com.opencloud.slee.resources.cgin.cap_v2.CAP2ConnectArg

CAP-DataTypes.ConnectArg

The connect arg Sentinel will use if the call is to be reoriginated — not modified otherwise

Error scenarios

Scenario Handling

Sessionstate SentinelSelectionKey is null

Report featureCannotStart

Invoked for a non CAP dialog

Report featureIssuedWarning

No available correlation entries

Report releaseCallAndCloseDialog

Could not find a mapper to build the ConnectArg

Report featureFailedToExecute

Error retrieving the correlated data to restore InitialDP

Report releaseCallAndCloseDialog

Feature responses

Response Reason

featureCannotStart SessionState

SentinelSelectionKey is not set

featureIssuedWarning

non CAP dialog

releaseCallAndCloseDialog

Error while restoring the original Called Party Address address, error while reoriginating: unsupported network, could not find a mapper to build the ConnectArg

connectAndCloseDialog

Attempt to trigger reorigination

featureHasFinished

feature has finished

Below are details of the two phases, followed by Call Flow, Configuration, Configuration Profile Naming, and Provisioning Interfaces.

Phase one: reoriginating a session

Reoriginating a session includes these steps:

Determining if a dialog should be reoriginated

The Reorigination feature analyses the InitialDP to determine if the dialog should be reoriginated. The Reorigination feature checks:

  1. if the dialog is for originating treatment. The first InitialDP will be triggered on DP2 (Collected Info). Terminating and forwarded dialogs are not reoriginated.

  2. if the application context is supported. Supported application contexts are:

    • cap_v1_gsmSSF_to_gsmSCF-AC

    • cap-v2-gsmSSF-to-gsmSCF-AC

    • capssf_scfGenericAC (CAP3).

  3. if the InitialDP VLR address is for a roaming party for which reorigination is supported. Roaming partners that do not support the ERB(Disconnect) + ACH guarantee are listed in a reorigination configuration table which includes the VLR addresses of the operator. The Reorigination service determines if the VLR address is present in the table, and if so triggers reorigination.

Processing a reoriginated session

If a session is to be reoriginated, the feature uses the Correlation RA to:

  • get an ID that is used to route the call to

  • associate some data with the correlation ID that can be used when the dialog is reoriginated.

The important steps are:

  1. Create the address we will use to select an id-pool.

  2. Create the data that we will associate with the correlation ID.

  3. Get a new correlation entry (passing the address and correlation data).

  4. Construct the outgoing connect arg.

Step one is achieved with a Mapper. The Reorigination feature looks for a mapper:

// a mapper that takes an {{InitialDP}} and generates a String.
final Mapper mapper = mapperLibrary.findMapper(selectionKey, initialDpArg.getClass(), String.class);

Sentinel includes a Mapper for this purpose — CAPInitialDPToCorrelationIdPoolAddress — that returns the MCC from location information in the InitialDP.

Note An alternative mapper that uses a different method for choosing an address to choose the id-pool can be written using the Sentinel SDK.

Step two is achieved with a Mapper. The Reorigination feature looks for a mapper:

// a mapper that takes an {{InitialDP}} and generates a {{byte\[\]}}.
final Mapper mapper = mapperLibrary.findMapper(selectionKey, cap1IdpArg.getClass(), byte[].class);

Sentinel includes a Mapper for this purpose, (CAPInitialDPArgToCorrelationData), that:

  • creates a new CAP1InitialDPArg object

  • copies the called party bcd number to the new cap 1 InitialDP

  • copies the bearer capability (if present) to the new cap 1 InitialDP

  • copies the redirecting party ID (if present) to the new cap 1 InitialDP

  • copies the redirection information (if present) to the new cap 1 InitialDP

  • copies the location information (if present) to the new cap 1 InitialDP

  • copies the extensions (if present) to the new cap 1 InitialDP

  • uses CGIN persist factory to turn this CAP1InitialDP → byte[].

Note An alternative mapper that uses a different method for building the correlated data to be associated with the correlation ID can be written using the Sentinel SDK. Step four uses a configuration profile selected from the ReoriginationConfigProfileTable to construct a new DRA, and a Mapper from the trigger class (for example, Cap2InitialDPArg) to a ConnectArg, to map it to an outgoing connect arg.

Phase two: receiving a reoriginated trigger

Receiving a reoriginated trigger includes these steps:

Determining if a dialog has been reoriginated

The reorigination feature analyses the InitialDP to determine whether the dialog is a reoriginated dialog; if:

  1. The reoriginated InitialDP will be triggered on DP3 (Analyzed Info).

  2. The application context is supported. Supported application contexts are:

    • cap-v2-gsmSSF-to-gsmSCF-AC

    • capssf_scfGenericAC (CAP3).

  3. The called party is a special routing number.

Note See Correlation Resource Adaptor to understand how the Correlation resource adaptor works and how it can be queried to see if the called party is a special routing number.

Processing a reoriginated trigger

If this session corresponds is a reoriginated trigger:

  • use the correlation ID (the called party number) to get the correlated data from the Correlation RA

  • restore fields from the original InitialDP (that is stored in the correlation data) into the reoriginated InitialDP.

This is achieved with a mapper. The reorigination feature looks for a mapper:

// a mapper that takes a {{byte\[\]}} and returns a {{CAP1InitialDPArg}}
final Mapper mapper = mapperLibrary.findMapper(selectionKey, byte[].class, CAP1InitialDPArg.class);

Sentinel core bundles a mapper for this purpose (CorrelationDataToCAPInitialDP) that:

  • uses CGIN persist factory to turn this byte[] into a CAP1InitialDPArg object

  • copies the cap 1 InitialDP called party bcd number to the reoriginated InitialDP

  • copies the cap 1 InitialDP bearer capability (if present) to the reoriginated InitialDP

  • copies the cap 1 InitialDP redirecting party ID (if present) to the reoriginated InitialDP

  • copies the cap 1 InitialDP redirection information (if present) to the reoriginated InitialDP

  • copies the cap 1 InitialDP location information (if present) to the reoriginated InitialDP

  • copies the cap 1 InitialDP extensions (if present) to the reoriginated InitialDP

  • sets the InitialDP session state field with the updated reoriginated InitialDP.

Note An alternative mapper that uses a different method for reconstructing the correlated data associated with the correlation ID can be written using the Sentinel SDK.
Tip

The mapper used to reconstruct the correlated data and update the reoriginated InitialDP should be thought of as the mirror to the mapper used in step two for processing the original InitialDP. If a custom method for choosing the data to associate with the correlation ID is built with the Sentinel SDK, then two new mappers are needed that:

  • take an InitialDP and generate a byte[]

  • take a byte[] and return a CAP1InitialDPArg.

Determining service type in reoriginated dialogs

The Classify Call Scenario Feature may not be able to correctly determine that a reoriginated dialog is roaming. To ensure that the roaming indicator is set correctly, the Reorigination service must set the service type to isRoaming.

Call flow

400

Configuration

Correlation RA configuration

Note See Correlation Resource Adaptor to understand how the correlation resource adaptor works and how it can be configured.

Feature configuration

A configuration profile table is used to configure the parameters of the new DRA sent out in the first connect (Phase 1).

Parameter Type Description

Nature

CalledPartyNumber.Nature

The address nature

NumberingPlan

CalledPartyNumber.NumberingPlan

The numbering plan of the address

RoutingToInternalNetworkNumber

CalledPartyNumber.RoutingToInternalNetworkNumber

either ALLOWED or NOT_ALLOWED

Address list configuration

A VLR address list table is maintained, for the service to identify roaming partners requiring reorigination. A VLR address entry is an extension of the standard Address list entry, the addition being a listing of the set of supported application contexts:

Parameter Type Description

OriginatingContextNames

String[]

Array of context names: cap_v1_gsmSSF_to_gsmSCF_AC, cap_v2_gsmSSF_to_gsmSCF_AC, capssf_scfGenericAC

Configuration profile naming

Configuration Profile Table Name Description Profile Naming

${PLATFORMOPERATOR}_Reorigination_AddressListConfigurationTable

Address list configuration

${SELECTIONKEY}:Reorigination:VLRAddressList

${PLATFORMOPERATOR}_Reorigination_AddressListEntryProfileTable

Feature specific Address List entry table

${SELECTIONKEY}:Reorigination:VLRAddressList:${ADDRESS}

ReoriginationConfigProfileTable

new DRA parameters

${SELECTIONKEY} (for example, OpenCloud::::)

ReoriginationCorrelationIdPools

Sets of reorigination numbers

Arbitrary eg Pool-1, however must include at least one profile named DEFAULT

CorrelationConfigTable

reorigination-correlation-ra configuration

ReoriginationCorrelationConfigProfile — can be redefined in the reorigination-correlation-ra configuration properties

Provisioning interfaces

The feature is provisioned using the Sentinel Features REST API or web interface.

1. Noldus, Rogier (2006), "CAMEL: Intelligent Networks for the GSM, GPRS and UMTS Network", John Wiley & Sons, Ltd
Previous page Next page
Sentinel Express Version 4.1