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 |
|
Yes |
No |
Stateless |
SBB |
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; |
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 |
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 |
EndSessionErrorCode |
int |
The response code used when ending the session. |
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 Microservice RA is queried. |
ShCacheDataReceived |
Counter |
Incremented when the Sh Cache Microservice RA 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. |
CompanionDeviceOverrodeRoutingMode |
Counter |
Incremented when the feature selects |
TriggeredEndSession |
Counter |
Incremented when the feature rejects an |
ResponseLatency |
Sampled |
Records elapsed time between requesting data from the Sh Cache Microservice 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.
The feature also checks the x-msw-companion-device
header to determine if the subscriber has a
companion device.
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 |
---|---|
|
SCCTADSRouting feature will be invoked to attempt connection over PS first, sequentially forking to CS if that fails. |
|
SCCTADSRouting feature will be invoked to attempt connection over CS first, sequentially forking to PS if that fails. |
|
SCCTADSRouting feature will be invoked to attempt connection over PS only. |
|
SCCTADSRouting feature will be invoked to attempt connection over CS only. |
|
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 |
---|---|
|
This will cause T-ADS to override the |
|
If this value is present in the header, the |
X-Msw-Companion-Device
The X-Msw-Companion-Device
header may be set by the upstream terminating MMTel-AS, if the
SubscriberDataLookupFromHSS feature found
companion device
information in the subscriber’s service data.
The value of this header is the companion device’s radio access type — currently only the value "PS" is supported, other values are ignored.
If this header is present with the value "PS", then TADS Data Lookup sets the routing mode to parallel
,
overriding the oc-routing-mode
header. This can however be overridden if the Request-Disposition
header is present.
In which case the rules described in Request-Disposition header above are followed.
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:
-
Checking the registration data associated with the route
-
Querying the HSS for T-ADS information
-
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 Microservice 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 → |
None |
MSISDN |
SessionState → |
None |
IMPU_IMPI |
SessionState → |
Registration → |
MSISDN_IMPI |
SessionState → |
Registration → |
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 there are no registrations, then no HSS query will be performed, and it will be assumed that no valid routes are available).
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 response with the error code from EndSessionErrorCode
to the incoming INVITE
request, terminating the call.