T-ADS Data Lookup gathers information from the received SIP signalling, and optionally queries the HSS, in order to determine available PS and CS routes that can be used to deliver the call to the served user.

All valid routes to PS and CS domains are written into session state. This information is then read by the appropriate T-ADS Routing feature, either SCCTADSRouting (for sequential routing) or SCCTADSParallelRouting (for parallel routing).

Feature Cheat Sheet

B2BUA Instance SAS Support Originating / Terminating Point(s) in Session Plan Network Operator Data Subscriber Data Stateful or Stateless POJO Feature or SBB Feature Other notes

SCC

Yes

Terminating

SipAccess_SubscriberCheck

Yes

No

Stateless

SBB

Prerequisite Features

Session Input Variables

Session state variable name Type Comments 
CallType

CallType (Enum)

The call-type for the incoming call (e.g. MobileTerminating).

 
RoutingMode

TADSRoutingMode (Enum)

Determines whether CS and/or PS routing is enabled and the preferred attempt order.

 
IsLoggedIn

boolean

Set to true when the served user is currently logged in to the IMS.

 
RegistrationRecords

List<RegistrationRecord>

This contains all of the current registration information for the served user.

 
CMSISDN

String

A string set to a non-null value if there is a C-MSISDN provisioned for the user, and if the user is logged in;
if the user is not logged in.

 
Subscriber

String

The subscriber’s identity.

 
SentinelSelectionKey

SentinelSelectionKey

Used to acquire configuration information.

Session Output Variables

Session state variable name Type Comments 
BlindPSRouting

boolean

Indicates whether blind PS routing is permitted.

 
RoutingMode

TADSRoutingMode (Enum)

The routing strategy to be used by the T-ADS routing features.

 
TADSSipInstanceRoutingPossible

boolean

Indicates whether T-ADS sip.instance routing is possible for the served user.

 
TADSCircuitRoutes

Queue<String>

Contains all valid CS domain routes (CSRNs) that the feature has calculated

 
TADSPacketRoutes

Queue<RouteAndTerminatingDomain>

Contains all valid PS domain routes that the feature has found along with the network type for each route.

Network Operator Data

T-ADS Data Lookup has network operator data in a JSLEE profile table named SCCTADSDataLookUpConfigProfileTable and also SCCTADSNetworkTypeConfigProfileTable. The data is scoped by Sentinel selection key.

SCCTADSDataLookUpConfigProfileTable

Attribute Type Meaning 
ForceSipUserEqualsPhone

boolean

If true, when attempting to extract a CS routable number from a SIP URI, the feature will proceed even if the URI does not have the user=phone parameter.

 
VoiceOverPSSupportRequired

boolean

If true, the HSS must be queried for voice over PS support as part of the decision to attempt to route via PS.

 
RequestUserIdentityType

TADSRequestIdentities (Enum)

Specifies which identities will be used for the voice over PS support request to the HSS.

 
EnableSipInstanceRouting

boolean

Determines whether the feature should attempt to use +sip.instance routing to calculate PS routes.

 
EndSessionWhenNoValidRouteFound

boolean

Will cause the feature to refuse an incoming INVITE with a 503 response if no valid routes can be found.

SCCTADSNetworkTypeConfigProfileTable

Attributes Type Meaning 
NetworkType

String

Either the RAT value or the Network Access Type value.

 
TerminatingDomain

String

The value used to populate the OC-Terminating-Domain Header when processing a response from a network of this type

 
Description

String

A text field for a description.

The SCCTADSNetworkTypeConfigProfileTable has multiple profiles, each one being either a RAT value or Network Access Type that will be checked to determine if a call can proceed on the PS network.

Each profile includes a TerminatingDomain value that T-ADS Data Lookup uses this value to populate the PSTerminatingDomainHeaderValue session state variable. The T-ADS Routing features use this to send information about the terminating access domain to upstream network nodes as described here.

The system comes with some default profiles pre-configured as follows, Where ${platform.operator.name} will be substituted with the value used on installation.

Profile Name Network Type TerminatingDomain Description 
${platform.operator.name}:::::1004

1004

PS=EUTRAN

RAT value 1004 = E-UTRAN from TS 29.212 section 5.3.31

 
${platform.operator.name}:::::3GPP-E-UTRAN

3GPP-E-UTRAN

PS=EUTRAN

P-Access-Network-Info value from TS 24.229 section 7.2A.4

 
${platform.operator.name}:::::3GPP-E-UTRAN-FDD

3GPP-E-UTRAN-FDD

PS=EUTRAN

P-Access-Network-Info value from TS 24.229 section 7.2A.4

 
${platform.operator.name}:::::3GPP-E-UTRAN-TDD

3GPP-E-UTRAN-TDD

PS=EUTRAN

P-Access-Network-Info value from TS 24.229 section 7.2A.4

Additionally if WLAN is chosen as part of the installation for allowed access types, the following entries will also be present in the profile table.

Profile Name Network Type TerminatingDomain Description 
${platform.operator.name}:::::0

0

PS=WLAN

RAT value 0 = WLAN from TS 29.212 section 5.3.31

 
${platform.operator.name}:::::3GPP-WLAN

3GPP-WLAN

PS=WLAN

P-Access-Network-Info value from TS 24.229 section 7.2A.4

 
${platform.operator.name}:::::IEEE-802.11

IEEE-802.11

PS=WLAN

P-Access-Network-Info value from TS 24.229 section 7.2A.4

 
${platform.operator.name}:::::IEEE-802.11A

IEEE-802.11A

PS=WLAN

P-Access-Network-Info value from TS 24.229 section 7.2A.4

 
${platform.operator.name}:::::IEEE-802.11B

IEEE-802.11B

PS=WLAN

P-Access-Network-Info value from TS 24.229 section 7.2A.4

 
${platform.operator.name}:::::IEEE-802.11G

IEEE-802.11G

PS=WLAN

P-Access-Network-Info value from TS 24.229 section 7.2A.4

 
${platform.operator.name}:::::IEEE-802.11N

IEEE-802.11N

PS=WLAN

P-Access-Network-Info value from TS 24.229 section 7.2A.4

Statistics

SCCTADSDataLookUp statistics are tracked by the SCCTADSDataLookUp SBB and can be found under the following parameter set: SLEE-Usage → volte.sentinel.sip service ID → SCCTADSDataLookUp SBB ID.

Name Type Description 
Started

Counter

Incremented when the feature is triggered.

 
FailedToStart

Counter

Incremented when the feature fails to start.

 
FailedDuringExecution

Counter

Incremented when the feature fails while executing.

 
IssuedWarning

Counter

Incremented when the feature issues a warning.

 
TimedOut

Counter

Incremented when the feature times out during execution.

 
QueriedShCache

Counter

Incremented when the Sh Cache is queried.

 
ShCacheDataReceived

Counter

Incremented when the Sh Cache returns data from the query.

 
FoundValidCSRoute

Counter

Incremented when the feature finds a valid route to the CS domain.

 
FoundValidPSRoute

Counter

Incremented when the feature finds a valid route to the PS domain.

 
BlindPSRoutingRequested

Counter

Incremented when the feature has set the BlindPSRouting Session State field.

 
NoForkDispositionOverrodeRoutingMode

Counter

Incremented when the feature does not fork due to disposition header.

 
TriggeredEndSession

Counter

Incremented when the feature rejects an INVITE request due to there being no valid routes to forward it on.

 
ResponseLatency

Sampled

Records elapsed time between requesting data from the Sh-Cache RA and getting a response (in milliseconds).

Behaviour

Determining Routing Strategy

On receiving an INVITE request, the feature will analyse several headers in the request to determine how terminating domain selection should proceed. The main value checked is the oc-tads-routing parameter on the top-most Route header URI; in addition the feature also looks for the oc-blindpsrouting parameter on the same header, and certain values in the Request-Disposition header.

OC-TADS-Routing Parameter

oc-tads-routing is a custom parameter for the Route header. It determines the routing strategy used by T-ADS for domain selection. The following table shows the possible values of the parameter and resulting behavior:

Parameter Value Behaviour

ps-cs

SCCTADSRouting feature will be invoked to attempt connection over PS first, sequentially forking to CS if that fails.

cs-ps

SCCTADSRouting feature will be invoked to attempt connection over CS first, sequentially forking to PS if that fails.

ps-only

SCCTADSRouting feature will be invoked to attempt connection over PS only.

cs-only

SCCTADSRouting feature will be invoked to attempt connection over CS only.

parallel

SCCTADSParallelRouting feature will be invoked to attempt connection over CS and PS simultaneously.

OC-Blindpsrouting Parameter

oc-blindpsrouting is another custom parameter for the route header. If this parameter is present on the top-most Route header URI, T-ADS will allow blind PS routing (i.e. no attempt will be made to verify that termination in the PS domain is supported/allowed).

Request-Disposition header

The Request-Disposition header is specified by RFC-3841. The header contains a comma separated list of values. There are many possible values that can be contained within this header, but TADS Data Lookup is only interested in two:

Value Behaviour

no-fork

This will cause T-ADS to override the oc-tads-routing parameter to prevent any forking by the T-ADS routing features. ps-cs and parallel will be overridden to ps-only, cs-ps will be overridden to cs-only.

redirect

If this value is present in the header, the no-fork value will be ignored (if present).

Determining CS Routes

A place holder CS route of 0 is added to the TADSCircuitRoutes. Then when CS routing is going to be attempted one of FetchCMSISDN, FetchMSRN or CDMAFetchTLDN features is run depending on your deploy to query the HSS, HLR (GSM), or HLR (CDMA) respectively. The CMSISDN, MSRN, or TLDN form part of the Circuit Switched Routing Number (CSRN). If the CMSISDN is in the third-party registration data store, then the FetchCMSISDN feature is not executed during INVITE processing.

Determining PS Routes

The T-ADS Data Lookup feature has two ways of determining PS routes. Which one it uses depends on whether +sip.instance routing is enabled in the feature configuration. If +sip.instance routing is disabled, the feature will attempt to use the subscriber’s identity from Sentinel session state as a destination route. If +sip.instance routing is enabled, the feature will analyse all active registrations for the served user, searching for pub-gruus to use as destination routes. Regardless of how a route is determined, the feature will perform additional analysis to discover if the route is actually usable for PS routing.

If the subscriber is not logged in to the IMS according to the IsLoggedIn session state field, the T-ADS Data Lookup feature will not select any PS routes under any circumstances.

Determining Possible Route When +sip.instance Routing is Disabled

When +sip.instance routing is not in use, the feature will attempt to use the current subscriber identity from Sentinel session state. This identity is determined by the SIP Subscriber Determination Feature. The subscriber identity will be checked using the procedures outlined below, and if it is found to be a valid PS route it will be added to the TADSPacketRoutes queue in session state.

Determining Possible Routes When +sip.instance Routing is Enabled

When using +sip.instance routing, the feature will search for PS routes in the served user’s registration data. The Contact headers associated with every active registration for the served user will be checked for a pub-gruu parameter. The value of each pub-gruu parameter that is found will be checked using the procedures outlined below, and if it is found to be a valid PS route it will be added to the TADSPacketRoutes queue in session state. If no valid +sip.instance routes are found, the feature will attempt to find a PS route with the procedure used when +sip.instance routing is disabled.

Determining Validity of a PS Route

Regardless of which of the above methods were used to find the possible PS route(s), each route will be checked to ensure it is valid to attempt to route to it over the PS domain.

There are three approaches the feature can use to validate the route:

  1. Checking the registration data associated with the route

  2. Querying the HSS for T-ADS information

  3. No additional validation beyond checking the subscriber is logged into the IMS

Which method is used is based on the VoiceOverPSSupportRequired feature configuration option, and the oc-blindpsrouting Route header parameter:

VoiceOverPSSupportRequired oc-blindpsrouting Route Parameter Validation method

False

Absent

Registration Data

False

Present

No Additional Validation

True

Absent

HSS Query

True

Present

No Additional Validation

Once a route is found to be valid, it will be added to the TADSPacketRoutes queue in session state.

Validation by Registration Data

When validating a route by registration data, the feature will retrieve the registration record associated with the route:

  • For routes determined with +sip.instance routing, this will be the registration that contained the pub-gruu that is being validated.

  • For routes determined without +sip.instance routing, every active registration will be checked (only one needs to pass validation).

The feature will check the P-Access-Network-Info header information in the registration data to decide if PS can be supported. If the access-type values in any of the P-Access-Network-Info headers can be found in the SCCTADSNetworkTypeConfigProfileTable then the feature will consider the route valid.

Validation by HSS Query

If the feature needs to validate routes using the HSS it will form a query to the Sh-Cache RA. This query uses Data Reference 26 T-ADS Information. The access key is determined by the value of the RequestUserIdentityType feature configuration value:

RequestUserIdentityType Access Key Public ID Access Key Private ID

IMPU

SessionState → Subscriber

None

MSISDN

SessionState → CMSISDN

None

IMPU_IMPI

SessionState → Subscriber

Registration → PrivateID

MSISDN_IMPI

SessionState → CMSISDN

Registration → PrivateID

Which registration is used to get the private ID will depend on how the PS routes were determined:

  • For routes determined with +sip.instance routing, this will be the registration that contained the pub-gruu that is being validated.

  • For routes determined without +sip.instance routing, every active registration will be checked (only one needs to pass validation).

This means when an IMPI is required in the query, multiple queries may be needed.

The response to each query will be analysed:

  • If the HSS response indicates that voice over PS is not supported, then the associated route(s) will be considered invalid.

  • If the HSS response indicates that voice over PS is supported and the RAT type in the same response is present in the SCCTADSNetworkTypeConfigProfileTable, then the associated route(s) will be considered valid.

If No Valid Routes Are Found

If the feature is unable to determine any valid PS or CS routes for the given routing strategy, then its behaviour will be determined by the EndSessionWhenNoValidRouteFound configuration parameter. If the parameter is set to false (the default), then T-ADS will allow the incoming INVITE to be forwarded as-is. If the parameter is set to true, the feature will generate a 503 response to the incoming INVITE request, terminating the call.

Graceful Handling of Originating Access

The feature will finish execution without modifying any state, if invoked in an originating call attempt.

Previous page Next page
Sentinel VoLTE Version 2.8.0