Feature Description

2 Feature Description

This chapter describes the following features:

The INAP-based Number Portability (INP) and ANSI-41 Number Portability Query (AINPQ) features provide subscribers the ability to switch their telephone service to a new service provider while retaining their original telephone number.
The Service Portability feature allows subscribers to change to another technology within the same service provider while retaining their original telephone number.
The S-Port Subscriber Differentiation feature can be used with Service Portability for INP Message Relay (INPMR) to allow use of ASD digits to provide an additional Routing Number per own-network subscriber. (ASD digits, if provisioned, are used in place of GRN digits.)
The INP Circular Route Prevention feature detects and prevents circular routes when used with the INP feature.

The chapter includes an overview of the EAGLE Provisioning Application Processor (EPAP). EPAP provides the Real Time Database (RTDB) that is used in the database lookup functions.

Overview

Throughout the world, wireline and wireless operators are receiving directives from their national regulators to support service provider number portability in their networks.

The INAP-based Number Portability (INP) and ANSI-41 Number Portability Query (AINPQ) features provide subscribers the ability to switch their telephone service to a new service provider while retaining their original telephone number.

The Service Portability feature can be used with INP and AINPQ to allow own-network subscribers to move between IS41 and GSM technology within the same network-operator while keeping the same subscriber number. Service Portability allows use of RTDB GRN Entity digits for own-network GSM and IS41 subscribers in place of the SP Entity digits (RN entity digits in case of RN/PT=0 own-network IS41 subscriber) used in INP and AINPQ digits formats. See Service Portability.

The S-Port Subscriber Differentiation feature can be used with Service Portability and the INP Message Relay (INPMR) service to allow identification of subscribers for special processing, by assigning multiple Routing Numbers per in-network subscriber. For example, provisioned Additional Subscriber Data can be assigned as a subscriber’s private Routing Number (for Message Relay) and the provisioned GRN can be assigned as the subscriber’s public Routing Number (for Query/Response functions). Provisioned ASD digits are used in place of GRN digits when S-Port Subscriber Differentiation is on and Service Portability is applicable for the INPMR service.

The INP Circular Route Prevention feature is used only by INP, for both the INP Query and INP Message Relay services, for the detection and prevention of circular routes on the EAGLE. See INP Circular Route Prevention (INP CRP).

Note:

Both INP and AINPQ are mutually exclusive with North American Local Number Portability (LNP), on an EAGLE node, unless the Dual ExAP Configuration feature is enabled.

The implementation of a Number Portability Database (NPDB) is the Real Time database (RTDB). Both the INP and AINPQ features use the same RTDB for for number portability processing. The Message Relay function is the same for both features. INP uses the INAP TCAP protocol and AINPQ uses the ANSI-41 TCAP protocol for Query functions.

The following functions are available for both the INP and AINPQ features:

Ported number lengths up to 15 digits.
- True variable-length numbers are supported without requiring padding of numbers in the provisioning and other input/output interfaces.
- Number lengths vary between countries and may even vary within a country. The RTDB structure supports numbers of varying length without requiring software modifications.
Number normalization
INP/AINPQ can be provisioned to accept queries with or without special prefixes on the DN. This capability allows INP/AINPQ to accommodate SSPs that do or do not include the prefix in their queries to the RTDB.
- INP/AINPQ can be provisioned to remove automatically a special prefix (such as an access code ’ or 1). INP/AINPQ can strip off the prefix, perform a database query using the international version of the DN, and return a response to the switch. (All RTDB queries are performed using the international version of the DN.)
- INP/AINPQ can be provisioned with options to map incoming NAI values to provisioned service NAI values for use in number conditioning.
National Escape Code (NEC) removal

INP/ AINPQ can be provisioned to automatically remove the National Escape Code (up to 5 hexadecimal digits).
Additional Subscriber Data (ASD)

Destination Routing Address (DRA) formats can include Additional Subscriber Data from the RTDB lookup. One use of ASD is for CNL information.

Additional Subscriber Data is supported in the outgoing DRA in INAP Connect messages or in the ANSI-41 Return Result with Routing Digits, if configured.
Generic Routing Number (GRN)

Destination Routing Address (DRA) formats can include the Generic Routing Number from the RTDB lookup.

The Generic Routing Number is supported in the outgoing DRA in INAP Connect messages or in the ANSI-41 Return Result with Routing Digits, if configured.
Generic Routing Number use to store ROP information

In addition to the Routing Number normally seen for number porting, an additional piece of information called the CNL (small geographic area) can also used when porting. Each ported subscriber needs to be associated with a CNL. In some cases, the number of supported CNLs (65K or more) can be problematic for routing and simple billing analysis. CNLs can be clustered into groups called ROPs. Configuration options can be provisioned to allow use of the Generic Routing Number (GRN) field for storing the ROP information. See INP/AINPQ Configuration Options.
CgPA Route-on Global Title support

CgPA Rt-on-GT is supported for both ITU INAP InitialDP query (for INP feature) and ANSI-41 NPREQ query (for AINPQ feature). GTT is performed on the CgPA of the query to determine the CdPA of the response message. See CgPA Route-on-Global Title.

INP and AINPQ Functions and Considerations

INP and AINPQ Functions

INP and AINPQ functions minimize challenges for network operators while they plan to implement number portability for their subscribers.

INP and AINPQ can operate on the same node as EAGLE features G-Port, A-Port, and G-Flex. INP and AINPQ functions are:

Because the number lengths can vary between countries (sometimes even within a country), INP and AINPQ support numbers of varying lengths in a flexible way, without requiring software modifications. The maximum number length of 15 digits for ported numbers is supported.
- INP performs number portability translations based on the received Called Party Number (CdPN) in the INAP portion of the message. For call-related messages, the database query is performed by using the digits from the Called Party Number parameter after converting them to an international number, if the number is not already in international format.
- AINPQ performs number portability translations based on the received dialed digits (DGTSDIAL).
The INP and AINPQ features can remove automatically the National Escape Code (NEC) that may be up to five hexadecimal digits.
The INP and AINPQ features can help to avoid problem situations with number normalization.
- Problems could occur where operators do not use NAI values that match the EAGLE standard number conditioning process. For example, a switch might send an NAI of a subscriber and expect the number to be treated as a National number, leading to problems.
  
  Number normalization allows the user to specify how certain NAI (Nature of Address Indicator) values are to be treated. This value treatment is performed by setting up rules that map incoming NAI values to internal SNAI (Service Nature of Address Indicator) values for the purpose of number conditioning.
- In some networks, users dial a special prefix, such as a 0 or 1 (an “access code”), before dialing the digits for the party they are trying to reach. Some SSPs strip off this prefix and do not include it in the query to the RTDB. However, other SSPs send the query using the entire dialed number, including the prefix.
  
  Number normalization lets INP and AINPQ accept queries either with or without special prefixes on the DN. Upon receipt, INP or AINPQ strips off the prefix if the DLTPFX configuration option is YES, converts the DN to an international number, performs the database query, and returns a response to the switch. The Called Party Number (for the INP feature) or the dialed digits (for the AINPQ feature) in the response can include the special prefix or not, depending on how the operator configures the feature.

INP/AINPQ Considerations

The following list contains considerations you should think over before installing and operating the INP and/or AINPQ feature:

The INP and the AINPQ features can co-exist on the same node if they share the same Subsystem Number (SSN).
INP and AINPQ responses are not routed by Global Title Translation.
The maximum length of the Application Context Name Object Identifier is 32 digits.
It is possible that PCs and/or PC + SSNs that are in the entity table of the database and are referenced by subscriber entries do not have the required data present on the EAGLE to route messages to them.

For example, the PC may not have a route, or the PC+SSN may not be in the MAP table for a final GTT. In these cases, a UIM is output only when a message is discarded due to the lack of data. These data problems can be reduced by careful provisioning of the route and MAP tables.
For INP Message Relay messages with E.164 numbers in the SCCP CdPA, it is assumed that no truncation occurred if and when the routing number was prepended and that SCCP CdPA has the full DN of the subscriber.
INP Message Relay to the EAGLE local subsystem is not supported. INP Message Relay messages are handled by the INPMR service, and not by the INP local subsystem.
Only the first 21 digits of the CdPA are decoded for INP Message Relay. For example, if the CdPA contains an RN prefixed to a DN, the RN is seven digits, and the DN is 15 digits, then the total is 22 digits, and the DN used for processing will be only 14 digits (21 total digits less 7 RN digits).
GTT currently handles decimal digits only. Thus, if an operator/country is using hexadecimal digits ‘A’ through ‘F’ in RNs and the operator is providing GTT to messages that have RN prefixes other than its own prefixes, the operator must enter the RN+DN number ranges as DN ranges in the INP/AINPQ database. The only problem with this is that the beginning and ending DNs can only be 15 digits, which may not be enough for an RN+DN.
If ported-in numbers use RN entity, replacing the CdPA GT with the entity address of a Signalling Point is not supported. There is at least one case where this is required: Subsequent GTT is desired, but the STP providing subsequent GTT does not have Number Portability capability.
If number normalization is provisioned with the DLTPFX configuration option set to YES, INP/AINPQ removes the specified prefix digits from the beginning of the DN before searching the database. The digit sequence of the specified prefix must never match the initial digit sequence of a valid DN. For example, if a valid DN without any special prefix is 5551234, then 55 should not be provisioned as a special prefix. If it were, INP/AINPQ would remove the first two digits from the DN, resulting in an invalid DN: 51234.

Other number normalization considerations include:
- INP and AINPQ features support up to 40 special prefixes per node.
- Special prefixes may not exceed 15 digits. All configurations of the 15 digit prefix are valid; that is, any digit from ‘0’ to ‘F’ in any sequence is valid for the prefix.
- A configuration option (CDPNPFX in the INPOPTS table for INP; DIALPFX in the AINPOPTS table for AINPQ) lets an operator enter the prefix digits to be deleted from the Called Party Number or dialed digits before the database lookup.
- The operator can return either the complete Called Party Number or dialed digits in the response to the SSP including the special prefix, or the DN without the special prefix. The DLTPFX option can be provisioned for each prefix. Up to 40 prefix-response combinations are supported.
- The operator can specify mappings from NAI to SNAI (Service NAI). Up to five mappings (for five unique NAI values) are supported. The valid SNAI values are subscriber (sub), national (natl), international (intl), unknown, (and none (none, which is used to delete existing entries).
- INP/AINPQ searches for the specified prefix at the beginning of the DN:
  - If the beginning digits of the DN match the provisioned prefix, they are removed before conditioning the number to the international format.
  - If the beginning digits of the DN do not match the provisioned prefix, the unchanged number is conditioned to the international format, which is used for the database search.
  - If NEC is provisioned and the beginning digits of the DN match the provisioned NEC, they are removed before conditioning the number to the international format.
- If the Called Party Number NAI value received in the INP query matches a NAI value provisioned in the NAI to SNAI mapping table, the value of SNAI is used when conditioning the number to international format according to existing rules defined for INP.
- After the database search, the response to the SSP is constructed using either the complete number as received in the query (with special prefix), or just the DN (without a prefix). This handling of the prefix depends on the user’s specification of various options during configuration, such as DLTPFX, DRA, and Response Type.

See INP/AINPQ Configuration Optionsand Provisioning the INP/AINPQ Number Normalizationfor information on provisioning configuration options for number normalization.

EPAP Data Provisioning Considerations for INP/AINPQ

The operator provisioning system (OPS) must address certain considerations when data is provisioned in the EPAP database for processing by the INP and AINPQ features.

Receiving INP/AINPQ Data from a National Database

The operator provisioning system (OPS) must address the following concerns when it gets its portability information from a national database:

In a two-step querying process where all but the recipient network uses an RN that identifies the recipient network and the recipient network itself uses a RN that identifies a particular exchange within its network, the data from the national database is the RN identifying the recipient network.

If the operator is the recipient, the operator provisioning system must override the “national” RN with the “local” RN.
The translation from the national database associated with an RN is to the point of interconnection (POI) for the recipient network. The recipient network operator provisioning system must override this translation with one that directs non-circuit-related messages to the correct signaling point within its network. If this is not done, the result will be either message discard or circular routing.

This problem also occurs when the national database provides RNs and associated translations for non-ported numbers. The provisioning system of the number range owner must take one of the following actions:
- Override the translations to its POI with a translation that directs non-circuit-related messages to the correct signaling points within its network.
- Remove the RNs and the associated translations, to cause the messages to use normal GTT processing.
- Replace the RN entities with SP entities when G-Flex is used.
When bulk loading the national database, the OPS must not wipe out any G-Flex data or any data change done to resolve these concerns.

Signaling Point (SP) Entity ID

When the user wants a Message Relay translation for a DN that does not have an RN, an entity ID number for the signaling point must be provided to the PDB even if one is not normally assigned:

Use the OPS to generate a unique ID number for an SP entity when it is entered, and use that number when communicating with the Provisioning Database (PDB), but identify the entity to the OPS user by other methods.
If a number is desired that does not require the use of the OPS to correlate to a specific entity, use the PC (converted to a 5-digit decimal number) and SSN to identify the entity; the PC and SSN together are guaranteed to be unique within a network.

If an International PC is used, some method is required to set it off from the National PCs because it is a separate network. One way of doing this is to use an extra digit to specify the network. The examples in Table 2-1 show how to use a 1 to identify National PCs and a 2 to identify International PCs.

Table 2-1 Entity ID Examples

Intermediate GTT to another STP whose PCN = 2345	`EntityID = 102345`
Final GTT to an SCP whose PCN = 2346 and SSN = 5	`EntityID = 102346005`
Final GTT to a different service (SSN = 7) on the same SCP	`EntityID = 102346007`
Intermediate GTT to another STP whose PCI = 3-4-5	`EntityID = 206181`

INP/AINPQ Configuration Options

Configuration option data is loaded to the LIM cards and to Service Module cards that contain the RTDB. The option values influence number conditioning, response message formatting and generation, and Service Portability processing.

Note:

Provisioning of the INPOPTS table is controlled by the INP feature; therefore, INP MR will operate with default INPOPTS option values DEFRN=none and SPORTTYPE=none if only the AINPQ feature is enabled.

Note:

The Service Portability feature, the IDP A-party Blocklist feature, and support for ROP data all use GRN data for different purposes. The IDP A-party Blocklist feature is mutually exclusive with the Service Portability feature; the restriction is enforced in feature provisioning. There is no enforced restriction for the Service Portability feature and ROP data support to be mutually exclusive. It is expected that support for ROP and Service Portability will be not be used in the same EAGLE system.

See EAGLE Commands and Commands User's Guide for a description of the EAGLE commands used to provision the option values.

Table 2-2 describes INP and Service Portability configuration options.

Table 2-3 describes AINPQ and Service Portability configuration options.

Table 2-4 describes the equivalence between INP options and AINPQ options.

SCCP Options Configuration Option for S-Port Subscriber Differentiation describes the SCCPOPTS SUBDFRN option for S-Port Subscriber Differentiation.

Guidelines for S-Port and NPP Configuration Options describes recommended configuration option values for features that use Service Portability and NPP.

Table 2-2 INPOPTS Configuration Options

Parameter	Value	Description
CDPNNAI - Called Party Number Nature of Address Indicator	0-127	1 - Subscriber 2 - Unknown 3 - National 4 - International Must be specified with SNAI. Used to map or recast message CDPNNAI to SNAI. See Provisioning the INP/AINPQ Service NAI.
CDPNPFX - Called Party Number Prefix See Provisioning the INP/AINPQ Number Normalization.	1-15 hexadecimal digits
CUTNPASTE - Indicator to include or not include the CutAndPaste parameter in the Connect message in response to the INP Query Used only by INP Query. See INP/AINPQ Message Protocol.	ON	Include the CutAndPaste parameter in the Connect message. If the DRA format includes the DN (as in dra=rndn), then the number of digits in the CutAndPaste NumDigits value is set to the number of digits in the incoming DN (CdPN). If the DRA format does not include the DN (as in dra=rn), then the CutAndPaste NumDigits value is set to 0.
	OFF	Do not include the CutAndPaste parameter in the Connect message. This is the default value.
DEFRN - Default Routing Number	1-15 hexadecimal digits	Used for own-network subscribers Can be used with or without Service Portability. See Service Portability.
DEFRN - Default Routing Number	NONE
DLTPFX - Delete Prefix	YES	If DLTPFX=yes, all formats that support a prefix will not include the prefix in the formatted digits.
DLTPFX - Delete Prefix	NO	If DLTPFX=no, all formats that support a prefix will include the prefix in the formatted digits.
DRA - Destination Routing Address If DLTPFX=no, all formats that support a prefix will include the prefix in the formatted digits. If DLTPFX=yes, all formats that support a prefix will not include the prefix in the formatted digits. NEC must be provisioned before any format that includes NEC can be selected. See the CUTNPASTE option for the use of the Connect message CutAndPaste parameter information when the DRA format contains the DN. See Provisioning the Routing Number Prefix of the Node (Home RN).	RNDN	RN + [CDPNPFX] + DN in the INP Connect response messages
	RN	Routing Number in the INP Connect response messages
	CCRNDN	[CDPNPFX] + CC + RN + DN in the INP Connect response messages
	RNNECDN	RN + [CDPNPFX] + NEC + DN in the INP Connect response messages
	HOMERNDN	Home Routing Number in the INP Connect response messages
	RNASD	RN + ASD in the INP Connect response messages
	ASDRN	ASD + RN in the INP Connect response messages
	RNASDDN	RN + ASD + [CDPNPFX] + DN in the INP Connect response messages
	ASDRNDN	ASD + RN + [CDPNPFX] + DN in the INP Connect response messages
	CCRNASDDN	[CDPNPFX] + CC + RN + ASD + DN in the INP Connect response messages
	ASDRNCCDN	ASD + RN + [CDPNPFX] + CC + DN in the INP Connect response messages
	CCASDRNDN	[CDPNPFX] + CC + ASD + RN + DN in the INP Connect response messages
	RNASDCCDN	RN + ASD + [CDPNPFX] + CC + DN in the INP Connect response messages
	RNASDNECDN	RN + ASD + [CDPNPFX] + NEC + DN in the INP Connect response messages
	ASDRNNECDN	ASD + RN + [CDPNPFX] + NEC + DN in the INP Connect response messages
	RNGRN	RN + GRN in the INP Connect response messages
	GRNRN	GRN + RN in the INP Connect response messages
	RNGRNDN	RN + GRN + [CDPNPFX] in the INP Connect response messages
	GRNRNDN	GRN + RN + [CDPNPFX] + DN in the INP Connect response messages
	CCRNGRNDN	[CDPNPFX] + CC + GRN + RN + DN in the INP Connect response messages
	CCGRNRNDN	CC+ GRN + RN + DN in the INP Connect response messages
	GRNRNCCDN	GRN + RN + [CDPNPFX] + CC + DN in the INP Connect response messages
	RNGRNCCDN	RN + GRN + [CDPNPFX] + CC + DN in the INP Connect response messages
	RNGRNNECDN	RN + GRN + [CDPNPFX] + NEC + DN in the INP Connect response messages
	GRNRNNECDN	GRN + RN + [CDPNPFX] + NEC + DN in the INP Connect response messages
	GRN	GRN in the INP Connect response messages
	GRNDN	GRN + [CDPNPFX] + DN in the INP Connect response messages
	CCGRNDN	[CDPNPFX] + CC + GRN + DN in the INP Connect response messages
DRANAI - Destination Routing Address Nature of Address Indicator	SUB	Subscriber Number
	UNKNOWN	Unknown
	NATL	National Significant Number
	INTL	International Number
	NTWK	Network
DRANAIV - Destination Routing Address Nature of Address Indicator Value	0-127	1- Subscriber Number 2 - Unknown 3 - National Significant Number 4 - International Number 5 - Network
DRANP - Destination Routing Address Numbering Plan	E164	ISDN/Telephony Numbering Plan
	X121	Data Numbering Plan
	F69	Telex numbering plan
DRANPV - Destination Routing Address Numbering Plan Value	0-7
NEC - National Escape Code Must be specified before a DRA format containing NEC can be selected. See Provisioning the INP/AINPQ Number Normalization.	1-5 digits
	NONE
RELCAUSE - Release Cause Reason for releasing the call when an INP Circular Route is detected. The INP Circular Route Prevention feature must be enabled to specify this option.	1-127	31 - Normal Unspecified For a complete list of values and meanings, refer to ITU-T Recommendation Q.850, Usage of cause and location in the Digital Subscriber Signalling System No. 1 and the Signalling System No. 7 ISDN User Part, May 1998, International Telecommunication Union.
SNAI - Service Nature of Address Indicator Must be specified with CDPNNAI. See Provisioning the INP/AINPQ Service NAI and Provisioning the Routing Number Prefix of the Node (Home RN)	SUB	Subscriber Number
	NATL	National Significant Number
	INTL	International Number
	UNKNOWN	Unknown NAI value If the DN digits do not have a leading country code (CC), the format is National. If the DN digits have a leading country code (CC), the format is International.
	NONE	NAI value NONE
SPORTTYPE - Service Portability Type	NONE	Service Portability is not performed for the feature
	GSM	Apply Service Portability prefix (RTDB GRN entity ID) for own-network GSM subscribers (Entity type = SP)
	IS41	Apply Service Portability prefix (RTDB GRN entity ID) for own-network IS41 subscribers (Entity type = RN with PT=0)
	ALL	Apply Service Portability prefix (RTDB GRN entity ID) for all own-network (IS41 and GSM) subscribers (Entity type = SP, or RN with PT=0)
SPRESTYPE - Service Portability Response Type The type of message sent if the following conditions exist: An IDP message is received for INP service. The DN digits match. The HLR ID is present. Either Entity Type = SP or Entity Type = RN with PT=0. Either the IGM feature is turned ON or the S-Port feature is enabled.	CONNECT	Send a Connect message
	CONTINUE	Send a Continue message

The AINPOPTS table contains values for the following AINPQ configuration options:

Table 2-3 AINPOPTS Configuration Options

Parameter	Value	Description
DEFRN - Default Routing Number used for own-network subscribers	1-15 hexadecimal digits	Used for own-network subscribers.
	NONE	Used for own-network subscribers.
DIALNAI - Digits Dialed Nature of Address See Provisioning the INP/AINPQ Service NAI.	0	National
	1	International
DIALPFX - Dialed (Called)Party Number Prefix See Provisioning the INP/AINPQ Number Normalization.	1-15 hexadecimal digits
DLTPFX - Delete Prefix	YES
DLTPFX - Delete Prefix	NO
NEC - National Escape Code See Provisioning the INP/AINPQ Number Normalization.	1-15 hexadecimal digits
	NONE
RFMT - Routing Address Format See Provisioning the Routing Number Prefix of the Node (Home RN). If DLTPFX=yes, all formats that support a prefix will not include the prefix in the formatted digits. If DLTPFX=no, all formats that support a prefix will include the prefix in the formatted digits.	RNDN	RN + [DIALPFX] + DN in the AINPQ Return Result response messages
	RN	Routing Number in the AINPQ Return Result messages
	CCRNDN	[DIALPFX] + CC+ RN + DN in the AINPQ Return Result response messages
	RNNECDN	RN+[DIALPFX] + NEC + DN in the AINPQ Return Result response messages
	HOMERNDN	Home Routing Number in the AINPQ Return Result messages
	RNASD	RN + ASD in the AINPQ Return Result response messages
	ASDRN	ASD + RN in the AINPQ Return Result response messages
	RNASDDN	RN + ASD + [DIALPFX] + DN in the AINPQ Return Result response messages
	CCRNASDDN	[DIALPFX] + CC + RN + ASD + DN in the AINPQ Return Result response messages
	ASDRNCCDN	ASD + RN + [DIALPFX] + CC + DN in the AINPQ Return Result response messages
	CCASDRNDN	[DIALPFX] + CC + ASD + RN + DN in the AINPQ Return Result response messages
	RNASDCCDN	RN + ASD + [DIALPFX] + CC + DN in the AINPQ Return Result response messages
	ASDRNNECDN	RN + ASD + [DIALPFX] + NEC + DN in the AINPQ Return Result response messages
	RNGRN	ASD + RN + [DIALPFX] + NEC + DN in the AINPQ Return Result response messages
	GRNRN	GRN + RN in the AINPQ Return Result response messages
	RNGRNDN	RN + GRN + [DIALPFX] + DN in the AINPQ Return Result response messages
	RGNRNDN	GRN + RN + [DIALPFX] + DN in the AINPQ Return Result response messages
	GRNRNDN	GRN + RN + [DIALPFX] + DN in the AINPQ Return Result response messages
	CCRNGRNDN	[DIALPFX] + CC + RN + GRN + DN in the AINPQ Return Result response messages
	GRNRNCCDN	GRN + RN + [DIALPFX] + CC + DN in the AINPQ Return Result response messages
	RNGRNCCDN	RN + GRN + [DIALPFX] + CC + DN in the AINPQ Return Result response messages
	RNGRNNECDN	RN + GRN + [DIALPFX] + NEC + DN in the AINPQ Return Result response messages
	GRNRNNECDN	GRN + RN + [DIALPFX] + NEC + DN in the AINPQ Return Result response messages
	GRN	GRN in the AINPQ Return Result with Routing Digits response messages
	GRNDN	GRN + [DIALPFX] + DN in the AINPQ Return Result with Routing Digits response messages
	CCGRNDN	[DIALPFX] + CC + GRN + DN in the AINPQ Return Result with Routing Digits response messages
RNAI - Routing Nature of Address Indicator	NATL	National Significant Number
	INTL	International Number
	FRMSG	NAI from the incoming message
RNAIV - Routing Nature of Address Indicator Value	0	National
RNAIV - Routing Nature of Address Indicator Value	1	International
RNP - Routing Number Plan	UNKNOWN	IS41 Numbering Plan Unknown
	E164	IS41 Telephony Number
	E212	IS41 Land Mobile Number
	PRIV	IS41 Private Number
RNPV - Routing Number Plan Value	0-15
SNAI - Service Nature of Address Indicator See Provisioning the INP/AINPQ Service NAI and Provisioning the Routing Number Prefix of the Node (Home RN).	SUB	Subscriber Number Default Country Code (DEFCC) and Default Network Destination Code (DEFNDC) will be prepended to the DN to condition to International format for lookup.
	NATL	National Significant Number Default Country Code (DEFCC) will be prepended to the DN to condition to International format for lookup.
	INTL	International Number
	UNKNOWN	Unknown NAI value If the DN digits do not have a leading country code (CC), the format is National. The DEFCC will be prepended to the DN to condition to International format. If the DN digits have a leading country code (CC), the format is International.
	NONE	NAI value NONE
SPORTTYPE - Service Portability Type performed for the feature	NONE	Service Portability is not performed for the feature
	GSM	Apply Service Portability prefix (RTDB GRN entity ID) for own-network GSM subscribers (Entity type = SP)
	IS41	Apply Service Portability prefix (RTDB GRN entity ID) for own-network Is41 subscribers (Entity type = RN with PT=0)
	ALL	Apply Service Portability prefix (RTDB GRN entity ID) for all own-network (GSM and IS41) subscribers (Entity type = SP, or RN with PT=0)
SPRESTYPE - Service Portability Response Type The type of message sent if the following conditions exist: An NPREQ message is received. The DN digits match. The HLR ID is present. The Entity type = SP, or RN with PT=0 Either the IGM feature is on or the Service Portability feature is enabled.	RRSDGTS	Send a Return Result with Digits message
	RRWODGTS	Send a Return Result without Digits message

Table 2-4 INPOPTS and AINPOPTS Equivalents

INPOPTS		AINPOPTS
Option	Value	Option	Value
DRANAI	SUB	RNAI	FRMSG
	UNKNOWN		FRMSG
	NATL		NATL
	INTL		INTL
	NTWK		FRMSG
DRANAIV	0-2	RNAIV	2
	3		0
	4		1
	5-127		2
DRANP	(No equivalent)	RNP	UNKNOWN
	E164		(No equivalent)
	(No equivalent)		E164
	X121		(No equivalent)
	F69		(No equivalent)
	(No equivalent)		E212
	(No equivalent)		RIV
DRANPV	0-7	RNPV	0-7
DRANPV	8-15 (Not supported)	RNPV	8-15
DRA	RN	RFMT	RN
	RNDN		RN
	CCRNDN		CCRNDN
	RNNECDN		RNNECDN
	HOMERNDN		HOMERNDN
	RNASD		RNASD
	ASDRN		ASDRN
	RNASDDN		RNASDDN
	ASDRNDN		ASDRNDN
	CCRNASDDN		CCRNASDDN
	CCASDRNDN		CCASDRNDN
	ASDRNCCDN		ASDRNCCDN
	RNASDCCDN		RNASDCCDN
	RNASDNECDN		RNASDNECDN
	ASDRNNECDN		ASDRNNECDN
	RNGRN		RNGRN
	GRNRN		GRNRN
	RNGRNDN		RNGRNDN
	GRNRNDN		GRNRNDN
	CCRNGRNDN		CCRNGRNDN
	CCGRNRNDN		CCGRNRNDN
	GRNRNCCDN		GRNRNCCDN
	RNGRNCCDN		RNGRNCCDN
	RNGRNNECDN		RNGRNNECDN
	GRNRNNECDN		GRNRNNECDN
	GRN		GRN
	GRNDN		GRNDN
	CCGRNDN		CCGRNDN
SNAI	SUB	SNAI	SUB
	NATL		NATL
	INTL		INTL
	UNKNOWN		UNKNOWN
	NONE		NONE
SPRESTYPE	CONNECT	SPRESTYPE	RRWDGTS
SPRESTYPE	CONTINUE	SPRESTYPE	RRWODGTS
CDPNNAI	0	DIALNAI	0
	1		1
	2-127		Not supported
CUTNPASTE	ON	Not supported
CUTNPASTE	OFF	Not supported
DLTPFX	YES	DLTPFX	YES
DLTPFX	NO	DLTPFX	NO
CDPNPFX	1-15 hexadecimal digits	DIALPFX	1-15 hexadecimal digits
CDPNPFX	No digits	DIALPFX	No digits
NEC	NONE	NEC	NONE
NEC	1-5 hexadecimal digits	NEC	1-5 hexadecimal digits
RELCAUSE	1-127	Not supported
SPORTTYPE	NONE	SPORTTYPE	NONE
	GSM		GSM
	IS41		IS41
	ALL		ALL
DEFRN	NONE	DEFRN	NONE
DEFRN	1-15 hexadecimal digits	DEFRN	1-15 hexadecimal digits

SCCP Options Configuration Option for S-Port Subscriber Differentiation

The SCCPOPTS SUBDFRN option turns the S-Port Subscriber Differentiation function on and off in the system The S-Port Subscriber Differentiation feature must be enabled and turned on before the option can be provisioned.

See EAGLE Commands and Commands User's Guide for a description of the SCCPOPTS SUBDFRN option and the EAGLE chg/rtrv-sccpopts commands that are used to provision the option.

Provisioning the INP/AINPQ Service NAI

The MSU CdPN NAI value to check for is provisioned as the INPOPTS CDPNNAI option value for the INPQ feature and the AINPOPTS DIALNAI option value for the AINPQ feature. There is a one-to-one mapping from INPOPTS:CDPNNAI to INPOPTS:SNAI (and also similarly for AINPOPTS).

SNAI is a service NAI and indicates what kind of “service or conditioning” to apply to the extracted DN – whether the DN should be considered subscriber, national or international so that it can be appropriately conditioned to international format for RTDB lookup. All RTDB lookups use only the international DN. This SNAI is available in both the Service Selector table and the INPOPTS and AINPOPTS tables. The purpose though is the same.

This INPOPTS:SNAI and AINPOPTS:SNAI is different from the Service Selector table SNAI. The CdPN NAI from the incoming MSU is compared with the INPOPTS:CDPNNAI (for INP Query) or the AINPOPTS:DIALNAI (for AINPQ feature). If there is a match, then the corresponding mapped INPOPTS:SNAI or AINPOPTS:SNAI provisioned for that INPOPTS:CDPNNAI or AINPOPTS:DIALNAI entry is used as the SNAI for number conditioning. If there is no INPOPTS:SNAI or AINPOPTS:SNAI provisioned, or the CdPN NAI from the MSU does not match, then the CdPN NAI from the MSU is treated as an SNAI for number conditioning prior to RTDB lookup as follows:

The MSU CdPN NAI of ‘subscriber’ shall be considered as the SNAI value of SUB.
The MSU CdPN NAI of ‘international’ shall be considered as the SNAI value of INTL.
Otherwise, the MSU CdPN NAI shall be considered as the SNAI value of ‘NATL’.

The SNAI value (either from INPOPTS or AINPOPTS, or the MSU CdPN in case of no match) is then used to condition the extracted DN (from TCAP layer) to international format prior to RTDB lookup. For INP and AINPQ Query services:

If SNAI is ‘NATL’ the default country code is prefixed to the DN to condition it to international format.
If SNAI is ‘SUB’ the default country code and the default national destination code are prefixed to the DN to condition it to international format.
If SNAI is ‘INTL’, then no further conditioning is required as the extracted DN is already considered to be in international format.

For the INP message relay case, the service NAI from the Service Selector table is used to decide how the DN (extracted from SCCP CdPA) should be conditioned to international format prior to RTDB lookup. The INPOPTS:CDPNNAI and INPOPTS:SNAI are not used in this case.

Provisioning the Routing Number Prefix of the Node (Home RN)

When the portability cluster uses RN prefixes for relayed messages, a message for a ported-in number arrives at the EAGLE with an RN prefixed to the DN in the CdPA. In this case, the RN is one of the RNs for the EAGLE operator network.

Because the database contains only the DN, the following logic is performed to remove the RN before performing the database lookup:

When the SNAI (from the provisioned SRVSEL table entry) for a message is RNSDN, RNNDN, or RNIDN, the EAGLE searches all provisioned Home RNs or a match with the same number of leading digits in the CdPA.
If one or more matches are found, the match with the greatest number of digits is considered the Home RN for that message. The CdPA digits matching the Home RN are removed from the CdPA before the database lookup.
If a matching Home RN is not found, the entire string of the received digits (except for any ST digit on the end) is considered for the database lookup. If the database does not contain that entry, the database lookup fails, resulting in the being handled by GTT.

The correct removal of the RN prefixes depends on the provisioned configuration options:

Combinations of service selectors for incoming INP/AINPQ Message Relay messages with RN prefixes must have the appropriate SNAI (RNSDN, RNNDN, or RNIDN).
RNs to be removed must be provisioned in the HOMERN table.

Messages without an RN prefix can, in some cases, use the same selector values as messages with RN prefixes. If so, the SNAI must be set to RNxDN, but the leading CdPA digits of the non-prefix messages must not match any Home RN entries. If the digits do match, the matching part of the DN is removed before database lookup, resulting in the database lookup failing to find the full DN.

Provisioning the INP/AINPQ Number Normalization

When the MSC/SSP uses a prefixed CdPN or DGTSDIAL in the queries, a message arrives for INPQ service with a prefixed CdPN number. All prefixes to be removed from the CdPN or DGTSDIAL must be provisioned as configuration option values using the chg-inpopts command or the chg-ainpopts command.

The correct removal of prefixes depends on the content of the data that is provisioned. It is possible that CdPNs or DGTSDIALs without a prefix can have the same first digits as the prefix digits. If the digits match a provisioned prefix, that portion of the DN would be removed before database look up. The database lookup would fail because the full DN is not found. A similar situation could occur if an NEC is provisioned and the digits match the provisioned NEC.

The following logic is performed to remove the prefix before performing the database lookup.

The decoded INAP CdPN or DGTSDIAL digits are compared with the list of provisioned prefixes.
If a matching prefix is found, INP/AINPQ strips the prefix digits from the number.
After the prefixes are compared, the digits are also compared to any provisioned NEC value. If the beginning digits match the NEC, INP/AINPQ strips the matching digits.
If a matching prefix is not found, the entire string of the received digits ( except for any ST digit on the end) is considered for the database lookup without stripping the prefix.
Number conditioning, if required, is applied after deleting the prefix, the NEC, or both.

The INP Local Subsystem

Local subsystems in the EAGLE are maintainable entities for query and response that are used when the STP acts as an SCP. Specific point codes can be defined for routing to local subsystems independently of the STP in the network. A local subsystem can be taken online and offline as needed in the system.

INP supports ITU INAP InitialDP query. AINPQ supports ANSI-41 NPREQ query. INP MR does not use the INP local subsystem. The INP local subsystem in the EAGLE processes UDT and unsegmented XUDT messages

For the INP local subsystem, EAGLE supports ITU-I and ITU-N capability point code types for Message Relay and only ITU-I capability point code types for Query. The EAGLE true point code cannot be an ITU-I or ANSI point code. ITU-N24 point codes are not supported. Capability point codes for the INP local subsystem can be configured only after the INP or AINPQ feature is enabled.

A Rt-on-GT INP Query to the INP CPC when the local subsystem is inhibited will cause a response-method TFP to be sent to the SSP. If the same CPC is used for Message Relay (MR), then the SSP will be prevented from sending MR messages to the EAGLE even though they can still be processed. MR messages to an INP CPC will not cause TFP messages when the subsystem is inhibited. For these reasons, it is recommended that customers use separate CPCs for MR and Query. For the most safety, MR should use CPCTYPE=STP instead of using separate INP CPCs in order to correctly handle any stray route-set-test message for the MR CPC. (if a RSTP message was received for a MR INP CPC and the subsystem was inhibited, a TFA would not be sent even though the EAGLE could still process MR messages.)

The INP local subsystem can have a mate subsystem and a concerned point code group assigned to it. The INP local subsystem cannot be set to Load Shared mode (as end nodes do not perform load sharing), but can be set only to Dominant or Solitary mode. The INP local subsystem can be provisioned in MAP table if the INP feature or AINPQ feature is enabled.

The INP local subsystem can be taken online and offline using the procedures in Provisioning the INP Local Subsystem.

Messages for the INP Local Subsystem

Messages for the INP local subsystem can arrive Rt-on-SSN or Rt-on-GT. All MSUs must contain either the EAGLE true or secondary point code (TSPC), or the INP or STP capability point code (CPC) in the DPC field of the message.

Rt-on-SSN Handling - Messages that arrive Rt-on-SSN with the EAGLE INP subsystem number in the Called Party Subsystem field of the message are forwarded to the INP local subsystem.

Rt-on-GT Handling - Rt-on-GT MSUs can be received, with the result of translation being the EAGLE true point code and the the INP local subsystem. After GTT processing the messages are forwarded to the INP local subsystem.

Multiple Local Subsystems

The EAGLE supports provisioning Capability Point Codes for two or more local subsystems, allowing local subsystems for two or more EPAP-related features to operate at the same time in the system. For example, local subsystems for the INP feature and the EIR feature can coexist in the system. INP/AINPQ and LNP are mutually exclusive in the same EAGLE node, unless the Dual ExAP Configuration feature is enabled.

INP/AINPQ Message Protocol

INP/AINPQ support UDT SCCP messages and non-segmented XUDT messages.

INP and AINPQ support Rt-on-SSN and Rt-on GT messages. For Rt-on GT, GTA digits must be present.

INP and AINPQ support two TCAP protocols: INAP (for the INP feature) and ANSI-41 (for the AINPQ feature). The effective processing of the messages is the same for INAP and ANSI-41 protocols.

Primary INP/AINPQ Functions

INP and AINPQ provide the following main functions:

Message discrimination: INP and AINPQ translate ported numbers, and consequently can differentiate between messages for INP or AINPQ or other services. Discrimination is performed using a Service Selector table where INP services (INPQ and INPMR) can be defined for a combination of selectors. These selectors define whether INP Message Relay or INP/AINPQ Query is to be performed on an incoming message.
Number conditioning: Because the subscriber database stores international DNs only, INP/AINPQ can condition incoming numbers to be international DNs by inserting a default CC, a default NDC, or both, before performing a database look up. See INP and AINPQ Functions and Considerations.
- When a DN is extracted from the CdPN (TCAP layer), then the processing is for a Query service (INPQ or AINPQ). When the DN is extracted from the SCCP CdPA, then processing is for the INP Message Relay service.
- If the service is INPMR and the SNAI is either a RNSDN or RNNDN or RNIDN, and the RN prefix matches the home network RN prefix, INPMR strips off the RN prefix and conditions the number, if needed, before performing a database lookup.
- If the service is INPQ and the message is destined to the INP subsystem, INPQ does the following:
  - Strips off the CdPN prefix if it matches a cdpnpfx option value provisioned in the INPOPTS table.
  - Strips off the DGTSDIAL prefix if it matches the dialpfx option value provisioned in the AINPOPTS table.
  - Strips off any digits that match the NEC, if the NEC is provisioned.
  - Conditions the number to International format, if needed, before performing a database lookup.
INAP Connect Response: INP generates a Connect response for an InitialDP message if the conditioned number is found in the RTDB lookup. INP uses the Routing Number (RN) associated with the DN entry to build the Destination Routing Address (DRA) number.
- If the DLTPFX option value is NO, the prefix digits are included in the outgoing DRA digits.
- If the DLTPFX option value is YES, the prefix digits are excluded from the outgoing DRA.
- If the CUTNPASTE option value is ON, the CutAndPaste parameter is included in the CONNECT response to an InitialDP query.
  If the DRA format contains the DN, the NumDigits value in the CutAndPaste parameter is set to the length of the incoming DN (CdPN) digit string. This indicates to the originating node to discard all of the original CdPN digits and use the DRA entirely as the Routing Number.
  
  If the DRA format does not contain the DN, then the CutAndPaste NumDigits value is zero.
The supported formats are listed in the INPOPTS DRA option description in INP/AINPQ Configuration Options.
INAP Continue Response: A Continue response is generated for an InitialDP message if the conditioned number is not found in the RTDB lookup.
ANSI-41 Return Result with Routing Digits: If the TCAP query is ANSI-41 protocol, AINPQ responds to the queries with a Return Result message. This message has the Routing Digits encoded. If the conditioned number is found in the RTDB and the NE is listed in the AINPOPTS RFMT option description in INP/AINPQ Configuration Options, and the Response Type (SPRESTYPE) option is RRWDGTS, a Return Result with Routing Digits message will be the response. If the DLTPFX value is NO, the prefix digits are included in the outgoing RFMT digits. If the DLTPFX value is YES, the prefix digits are excluded from the outgoing RFMT.
ANSI-41 Return Result without Routing Digits: If the query is ANSI-41 protocol and the conditioned number is not found in the RTDB, a Return Result without Routing Digits response is generated. If the conditioned number is found, and NE is not assigned, and the Response Type (SPRESTYPE) option is RRWODGTS, a Return Result without Routing Digits is generated.
INP Message Relay: INP performs Message Relay when a combination of service selectors of like domain (ITU or ANSI), Global Title Indicator (GTI), Translation Type (TT), Numbering Plan (NP), and Nature of Address Indicator (NAI) indicate INP Message Relay is to be performed. (ANSI is not supported for INP Mesage Relay. The SCCP and MTP layers must be ITU-I or ITU-N.)
If the translation data exists, INP Message Relay does one of the following:
- Provides the ability to prefix the entity ID to the CdPA digits after deleting any home RN prefix
- Replaces the CdPA digits with the RN prefix
- Performs no change to the CdPA digits
- If the INP Circular Route Prevention feature is turned on and a circular route is detected (see INP Circular Route Prevention (INP CRP)),
  - UIM 1256: NP Circular Route detected is generated and the message falls through to GTT.
  - INP generates a Release Call response for an InitialDP message if the INP Circular Route Prevention feature is turned on and a circular route is detected. The CAUSE parameter in a Release Call message is encoded with the value of the RELCAUSE option provisioned in the INPOPTS table.

The Stages of INP/AINPQ Execution

INP/AINPQ is performed in the following stages:

The message arrives at EAGLE route-on-gt. The SCCP portion is decoded; the data is used to perform the service selection, based on the CdPA GT fields other than ES and GTAI. The result of this selection identifies the set of translations to be used for INP/AINPQ and also specifies whether INP Message Relay or INP/AINPQ Query is to be performed on the message. If a selector does not match the incoming GT fields, then GTT is performed.
If stage 1 indicates INP/AINPQ is required and the message is not a UDTS or XUDTS (Unitdata Service message or Extended Unitdata Service message) generated by EAGLE, the remaining SCCP portion is decoded. If INP/AINPQ Query is required, the TCAP and INAP portions are also decoded. If the message is a UDTSor XUDTS generated by the EAGLE, GTT is performed on the message.
If the service indicator is INP Message Relay:
1. If SNAI is CCRNDN or RNSDN or RNNDN or RNIDN, the leading digits of the DN number from the SCCP portion of the message are checked for the Home Routing Number (HOMERN), if any are provisioned. If found, INP/AINPQ strips off the HOMERN and condition the DN to be an international number.
2. The conditioned number's length is validated and the number is looked up in the subscriber database. First, the individual number database is searched. If the number is absent, the number range database is searched.
3. If the INP Circular Route Prevention feature is turned on and a circular route is detected, the message falls through to GTT.
4. If the number is found, the EAGLE uses the Message Relay GT information from the associated entity and prefixes the entity ID to the DN if specified, or, based on the option, can replace the CdPA digits with the entity ID or leave the DN unchanged. If no entity is associated with the DN or if the entity does not have translation (MR) data, then GTT is performed on the message.
5. If no match is found for the conditioned number in the subscriber database, GTT is performed on this message.
6. If the DPC in the translation data is the EAGLE point code or is for a different domain that the message (ANSI vs. ITU or ITU vs. ANSI), a UDTS or XUDTS is sent and the processing stops here.

If the service indicator is INP Query,

Two types of messages are allowed: messages with InitialDP as the INAP op-code and ANSI-41 messages with NPREQ op-code. During decoding, INP/AINPQ identifies whether the tcap-type is ANSI-41 or INAP from the package type field (second byte) of the TCAP portion of the message. The INP feature handles InitialDP messages; the AINPQ feature handles NPREQ messages.

If the INAP op-code is InitialDP, INP decodes the CdPN parameter and performs number conditioning to convert the INAP CdPN to an international number. This operation is performed in the following steps:

Leading digits of the CdPN number from the INAP portion of the message are compared to provisioned prefixes. If matching prefix digits are found, INP strips the prefix from the CdPN digits if the INPOPTS DLTPFX option value is YES.
If an NEC is provisioned and an NEC is present in the CdPN, strip off the NEC.
Remove any stop digits that are present in the CdPN.
After removing the prefix, ST Digits, and NEC, INP maps the CdPN NAI to the Service NAI by doing a lookup in the INPOPTS table. If the CdPN NAI is found in the INPOPTS table, its corresponding SNAI value is used for number conditioning. Otherwise, INP treats the number as national (natl), unless the NAI field in the CdPN is subscriber (sub) or international (intl).

If the INP Circular Route Prevention feature is turned on, the numbering format is determined using the Service NAI.

Table 2-5 Service NAI and Numbering Format

Service NAI	Number Format
International - DEFCC is provisioned and DEFCC matches the leading digits in the CdPN	CC+RN+DN
International - DEFCC is provisioned and DEFCC does not match the leading digits in the CdPN	RN+CC+DN
International - DEFCC is not provisioned	RN+CC+DN
National	RN+DN
Subscriber	RN+SN

If the INP Circular Route Prevention feature is turned on, the RN is matched with the Home RNs in the HomeRN table. The Home RN that matches with the maximum number of leading digits of the CdPN in removed from the CdPN.

If the ANSI-41 OPcode is NPREQ, AINPQ decodes the Dialed Digits number and performs number conditioning to convert the Dialed Digits to an international number.
1. The leading digits of the Dialed Digits from the TCAP portion of the message are compared to any provisioned prefixes (dialpfx). If found, the prefix is stripped from the Dialed Digits.
2. If an NEC is provisioned and a matching NEC is present in the Dialed Digits, strip off the NEC.
3. Remove any stop digits that are present in the Dialed Digits.
4. After removing the prefix, ST digits, and NEC from the Dialed Digits, the NAI is mapped to the Service NAI from the AINPOPTS table, and the corresponding SNAI value is used for number conditioning. If mapping is not found, AINPQ treats the number as National, unless the NAI field in the Dialed Digits is Subscriber or International.

The conditioned number's length is validated, and the number is looked up in the subscriber database.
The response depends on the implemented feature (INP or AINPQ), the Response Type (SPRESTYPE) option specified in the INPOPTS table (connect or continue) or in the AINPOPTS table (rrwdgts or rrwodgts), and on the result type of the query of the RTDB (RN or SP), as follows:
- A Connect message (for the INP feature) or a Return Result with Digits message (for the AINPQ feature) is sent in the following cases:
  For INP:
  - The number is found, the associated entity type is RN and not own-network IS41 subscriber. The Connect message has a Destination Routing Address (DRA) format specified by the provisioned DRA option.
    If GRN is returned in entity data, then GRN is included in the outgoing formats if specified in the provisioned DRA option.
    
    If the provisioned DRA format includes the GRN and the GRN is not returned in entity data, the message processing shall continue with an empty GRN.
  - The number is found, the associated entity type is SP or own-network IS41 subscriber (RN with PT=0 and the IGM feature on or the Service Portability feature enabled). The Connect message has the Destination Routing Address format specified by the provisioned DRA option. The RN in the INPOPTS DRA is interpreted as either the Generic Routing Number (GRN) from EPAP if required by Service Portability, or the Default RN (INPOPTS DEFRN option) if DEFRN is provisioned, or as entity ID (SP or RN).
  For AINPQ:
  - The number is found, the associated entity type is RN and not own-network IS41 subscriber. The Return Result with Digits message has the Destination Routing Address (DRA) format specified by the provisioned RFMT option.
    If GRN is returned in entity data, then GRN is included in the outgoing formats if specified in the provisioned RFMT option.
    
    If the provisioned RFMT format includes the GRN and the GRN is not returned in entity data, the message processing shall continue with an empty GRN.
  - The number is found, the associated entity type is SP or own-network IS41 subscriber (RN with PT=0 and the IGM feature on or the Service Portability feature enabled). The Return Result with Digits message has the Routing Digits format specified by the provisioned RFMT option. The RN in the AINPOPTS RFMT is interpreted as either the Generic Routing Number (GRN) from EPAP if required by Service Portability, or the Default RN ( AINPOPTS DEFRN option) if DEFRN is provisioned, or as entity ID (SP or RN).
- A Continue message (for the INP feature) or a Return Result without Digits message (for the AINPQ feature) is sent in the following cases:
  For INP:
  - The number is found and the entity type is SP or own-network IS41subscriber, (RN with PT=0 and the IGM feature is on or the Service Portability feature is enabled) and the Response Type (SPRESTYPE) option is continue.
  - The Generic Routing Number (GRN) was required for Service Portability, but was not provisioned. UIM 1426 is generated.
  - The number is Not Found (in this case, the Response Type (SPRESTYPE) option does not matter).
  For AINPQ:
  - The number is found and the entity type is SP or own-network IS41 subscriber (RN with PT=0 and the IGM feature is on or the Service Portability feature is enabled) and the Response Type (SPRESTYPE) option is rrwodgts .
  - The Generic Routing Number (GRN) was required for Service Portability, but was not provisioned. UIM 1426 is generated.
  - The number is Not Found (in this case the Response Type (SPRESTYPE) option does not matter).
- If for INP messages, a circular route is detected, a TCAP END with Invoke Release Call operation is sent as the response. The CAUSE parameter in the Release Call is encoded as the value of the RELCAUSE option in the INPOPTS table.

CgPA Route-on-Global Title

CgPA Rt-on-GT is supported for both ITU INAP InitialDP query (for INP feature) and ANSI-41 NPREQ query (for AINPQ feature). GTT is performed on the CgPA of the query to determine the CdPA of the response message. INPQS and AINPQ support CgPA Rt-on-SSN and Rt-on-GT CgPA. For Rt-on-GT, GTA digits must be present.

Incoming message SCCP validation and decoding includes the following processing for CgPA Rt-on-GT:

The CgPA SSN, if present, will be used as the CdPA SSN in response. If an SSN is not present, the default SSN=8 (MSC) will be used as the CdPA SSN of the response.
The CgPA PC, if present, is stored as the SSP PC for generating the response. If the CgPA PC is not present, the MTP OPC is stored as the SSP PC to generate the response. If this SSP PC is not in the EAGLE 5 ISS Route table, the query will not be discarded. A subsequent GTT on the CgPA that will be performed at the time of response encoding could translate to a point code that has a valid route. If a valid route is not found at that time, then encode time error handling handles this error.

Encoding of fields in the INP Query response MTP/SCCP portion are either the incoming values or are set based on the result of GTT processing on the CgPA.

INP Circular Route Prevention (INP CRP)

If the INP CRP feature is on, a circular route is detected if the provisioned HomeRN matches the leading digits of the SCCP CdPA in an IDP message that is received for INPMR service, and one of the following conditions also occurs:

The IGM feature is on or the Service Portability feature is enabled, and and an individual or range DN match is found with NE = RN and PT not zero or with NE not specified and PT is none, 0, 1, 2, or 36.
Individual or range DN match is found with NE = RN and PT is any value or with NE not specified and PT is none, 0, 1, 2, or 36.

For INPMR, UIM 1256 “NP Circular Route detected” is generated and the message falls through to GTT. GTT can generate a UDTS message if it cannot find any route entry for RN+DN CdPA digits.

For INPQ, a Release Call message is generated that contains the configured Release Cause (RELCAUSE option value).

Service Portability

Service Portability (S-Port) is an extension of Number Portability. Service Portability allows subscribers to move between IS41 and GSM technology within the same network-operator while keeping the same subscriber number. Service Portability applies to only own-network subscribers.

Service Portability allows use of RTDB GRN Entity digits for own-network GSM/IS41 subscribers in place of the SP Entity digits (RN entity digits in case of RN/PT=0 own-network IS41 subscriber) used in INP and AINPQ digits formats. The SPORTTYPE configuration option is provided to specify whether GRN should be used for own-network IS41 subscribers only, own-network GSM subscribers only, both, or neither cases.

A global Default Routing Number (INPOPTS and AINPOPTS DEFRN ) option value can be used as a Routing Number (RN) in place of the EPAP Entity digits in encoding digits in the case of own-network subscribers. For instance, if the EPAP Entity Type of a subscriber is SP, the subscriber is considered to be an own-network subscriber and the SP entity digits are used in encoding routing digits in the format specified in configuration option values (INPOPTS DRA or AINPOPTS RFMT). This entity ID is typically an HLR E.164 address. In some applications, the HLR address may not be applicable (such as in billing and certain routing contexts), and the network operator may instead want a global Routing Number to be used instead of the SP entity digits for all own-network subscribers. The Default RN is applicable in general to Number Portability and can be used whether Service Portability is ON or OFF. Service Portability use of GRN in place of the routing digits will override Default RN usage and behavior.

S-Port Subscriber Differentiation

S-Port Subscriber Differentiation can be used with Service Portability to allow use of provisioned ASD digits in place of GRN digits as an alternative Routing Number for own-network subscribers. For example, the ASD can be used as the subscriber’s private routing number (for message relay features) and the GRN as the subscriber’s public routing number (for query/response features).

The S-Port Subscriber Differentiation controlled feature (Part Number P/N 893-0379-01) and the SCCPOPTS SUBDFRN configuration option control S-Port Subscriber Differentiation operation. The SUBDFRN option cannot be provisioned unless the S-Port Subscriber Differentiation feature is enabled and turned on.

When the Service Portability feature and option are on, the S-Port Subscriber Differentiation feature and option are on, and Service Portability is applicable, then provisioned ASD digits are used in place of GRN digits.Subscribers without ASD provisioned will follow standard Service Portability processing and will always use GRN.

Guidelines for S-Port and NPP Configuration Options

Feature-specific configuration options, EPAP, and EAGLE data and NPP Formatting Actions work together to produce the “routing tag” that is used to modify digits in applicable messages. A “routing tag” is the Number Portability or Service Portability digits chosen to prefix the DN. Own-network GSM and IS41 subscribers can be tagged with the GRN (from EPAP entity data), the DFLTRN configuration option value, SP (EPAP entity digits), or no tag. OLO subscribers can be tagged with the RN (EPAP entity digits) or no tag.

Table 2-6 indicates the recommended provisioning for features that use NPP, based on how the subscriber numbers will be tagged. Service Portability provides the capability to use the GRN to tag own-network GSM and IS41 subscribers. A few potential combinations are not supported, because standard Number Portability processing does not differentiate between GSM and IS41 subscribers.

The following acronyms are used in the table header for feature-specific configuration options. The option names are not the same across all features that use NPP, but each feature does provide a similar option:

NPTYPE - determines lookup success criterion
SPORTTYPE - determines which own-network subscribers to tag with the GRN prefix (IS41, GSM, all, or none)
DFLTRN – specifies feature-specific value for a default Routing Number
SPFILL – specifies whether NPP should populate both SP and RN Formatting Action values even when DFLTRN or GRN is being used for local subscribers. In some scenarios, setting SPFILL to YES can cause double digits to be present. IS41 digits (RN/PT=0) are considered SP, because they should contain an E.164 HLR ID.

Because S-Port Subscriber Differentiation operates within the Service Portability call flow, when both are on and Service Portability is applicable, then ASD digits are used, if provisioned, in place of GRN digits. If ASD digits are not provisioned, then standard Service Portability processing is used. Wherever GRN appears in Table 2-6, provisioned ASD digits will be used if S-Port Subscriber Differentiation and Service Portability are ON.

Table 2-6 Recommended Provisioning for "Routing Tags"

Requested Tagging			Recommended Feature Configuration for NPP and S-Port Processing
GSM (SP/any PT)	IS41 (RN/PT=0)	OLO	NPTYPE	SPORTTYPE	DFLTRN	SPFILL	NPP Formatting Action
GRN	GRN	RN	RNSP	ALL	N/A	N/A	RN+DN
DFLTRN	GRN	RN	RNSP	IS41	DFLTRN	N/A	RN+DN
SP	GRN	RN	RNSP	IS41	None	No	RN+SP+DN
None	GRN	RN	RNSP	IS41	None	N/A	RN+DN
GRN	DFLTRN	RN	RNSP	GSM	DFLTRN	N/A	RN+DN
DFLTRN	DFLTRN	RN	RNSP	None	DFLTRN	N/A	RN+DN
SP	DFLTRN	RN	Not supported: Use SP/GRN instead
None	DFLTRN	RN	Not supported: Use None/GRN instead
GRN	SP	RN	RNSP	GSM	None	No	RN+SP+DN
DFLTRN	SP	RN	Not supported: Use GRN/SP instead
SP	SP	RN	RNSP	None	None	N/A	RN+SP+DN
None	SP	RN	Not supported: NP does not differentiate tags for own-network subscribers
GRN	None	RN	RNSP	GSM	None	N/A	RN+DN
DFLTRN	None	RN	Not supported: Use GRN/None
SP	None	RN	Not supported: NP does not differentiate tags for own-network subscribers
None	None	RN	RN	N/A	N/A	N/A	RN+DN
GRN	GRN	None	SP	ALL	N/A	N/A	RN+DN
DFLTRN	GRN	None	SP	IS41	DFLTRN	N/A	RN+DN
SP	GRN	None	SP	IS41	None	No	RN+SP+DN
None	GRN	None	SP	IS41	None	N/A	RN+DN
GRN	DFLTRN	None	SP	GSM	DFLTRN	N/A	RN+DN
DFLTRN	DFLTRN	None	SP	None	DFLTRN	N/A	RN+DN
SP	DFLTRN	None	Not supported: Use SP/GRN instead
None	DFLTRN	None	Not supported: Use None/GRN instead
GRN	SP	None	SP	GSM	None	No	RN+SP+DN
DFLTRN	SP	None	Not supported: Use GRN/SP instead
SP	SP	None	SP	None	None	N/A	SP+DN
None	SP	None	Not supported: NP does not differentiate tags for own-network subscribers
GRN	None	None	SP	GSM	None	N/A	RN+DN
DFLTRN	None	None	Not supported: Use SP/GRN instead
SP	None	None	Not supported: NP does not differentiate tags for own-network subscribers
None	None	None	N/A	N/A	N/A	N/A	DN

Hardware Requirements

EPAP-related features that perform an RTDB lookup require Service Module cards (E5-SM4G, E5-SM8G-B, or SLIC cards) running the SCCPHC application. The EAGLE can be equipped with up to 32 (31+1) Service Module cards.

Features that do not perform an RTDB lookup require Service Module cards only for GTT processing that might be performed for the feature. These features can coexist in systems with EPAP, but do not require an EPAP connection.

MPS/EPAP Platform

Oracle provides the Multi-Purpose Server (MPS) platform as a subsystem of the Oracle Communications EAGLE. The MPS provides support for EPAP-related features that perform Real Time Database (RTDB) lookups.

The MPS is composed of hardware and software components that interact to create a secure and reliable platform. For details about the MPS hardware, refer to Application B Card Hardware and Installation Guide. The MPS provides the means of connecting the customer provisioning application with the EAGLE and accepts the customer number portability data, while accommodating numbers of varying lengths.

The Oracle Communications EAGLE Application Processor (EPAP) is software that runs on the MPS hardware platform. EPAP collects and organizes customer provisioning data, and forwards the data to the EAGLE Service Module cards. For detailed information about EPAP, refer to Administration Guide for EPAP.

In this manual, Service Module card refers to an E5-SM4G, E5-SM8G-B, or SLIC card unless a specific card is required. For more information about the supported cards, refer to Hardware Reference.