2 Feature Description

This chapter describes the G-Port feature and related features which include:

• MT-Based GSM SMS NP
• MT-Based GSM MMS NP
• G-Port SRI Query for Prepaid
• GSM MAP SRI Redirect to Serving HLR

2.1 Introduction

Throughout the world, an increasing number of governments are mandating that telecommunications network operators support service provider number portability. These mandates are intended to promote competition among service providers and apply to both wireline and mobile phone networks. The GSM Mobile Number Portability (G-Port) feature is focused on service provider portability in GSM (Global System for Mobile Communications) networks.

Service provider portability allows a consumer to change service providers while retaining the same phone number. While consumers benefit from number portability, the implementation can present challenges for network operators. G-Port minimizes the challenges for GSM network operators, while enabling them to efficiently meet their regulatory obligations.

G-Port implements Mobile Number Portability for GSM networks according to the ETSI GSM 03.66 standard. The focus is on service provider portability among GSM networks in a defined portability cluster, usually a country. With service provider portability, subscribers can change operators while retaining their MSISDNs (Mobile Station international ISDN number). The MSISDN is the number dialed by a caller trying to reach the subscriber. The IMSI (International Mobile Station Identifier) number is not portable. The IMSI identifies the SIM (Subscriber Identity Module) card, which plugs in as a module to the GSM handset.

The G-Port feature is based on the EAGLE platform, and is deployed in a node that is also performing the STP function. G-Port uses the Real Time Database (RTDB) to derive the portability status of subscribers.

MNP Circular Route Prevention

The MNP Circular Route Prevention (MNPCRP) feature detects circular routing caused by incorrect information in one or more of the network number portability databases. For example, a subscriber may have ported from network A to network B. Network A has the correct routing information, indicating the subscriber now belongs to network B. However, network B may have incorrect routing information, indicating that the subscriber still belongs to network A. In this case, network A routes the call to network B, based on its portability data, but network B routes the call back to network A, based on its incorrect data. The result is a circular route. The MNPCRP feature provides logic to prevent the circular routing from occurring.

The MNP Circular Route Prevention feature (MNPCRP) is enhanced to allow Circular Route Prevention based on the Translation Type (TT) of the SCCP CdPA to be performed for SRI messages when a Home Routing Number (HomeRN) is not present. For the Circular Route Prevention on Translation Type processing to be performed, the crptt parameter of the chg-gsmopts command must be set to a value between 0 and 255. If the crptt parameter of the chg-gsmopts command is set to the default value of none, then no Circular Route Prevention on Translation Type processing is performed. The MNP Cicular Route Prevention feature cannot be turned off if the crptt parameter is provisioned to any value other than none. If a message is processed for Circular Route Prevention based on HomeRN, then Circular Route Prevention on Translation Type processing does not occur.

SRI messages must meet these criteria to be eligible for Circular Route Prevention on Translation Type:

• The message is selected for G-Port or IS41 GSM Migration processing.

• The message is not identified as G-Port SRI Query for Prepaid.

• The message is not MTP-routed. (The CdPA is Route-on-GT.)

• The translation type of the SCCP CdPA matches the provisioned translation type (crptt).

• The ITU TCAP Package type is ITU Begin.

• The OpCode is an SRI (hexadecimal 16).

• The Optimal Routing Interrogation Parameter (Tag = 0x04) is not present.

• The MSISDN is not assigned to the subscriber's network provider.

DigitAction Expansion

The DigitAction Expansion feature provides more flexibility to formulate the SCCP Called Party Address - Global Title Address (GTA) field of the MAP messages relayed by G-Port. Without DigitAction Expansion, G-Port supports four options (none, insert, prefix, and replace) to overwrite the SCCP CdPA GTA field. With DigitAction Expansion, four additional options (delcc, delccprefix, spare1, and spare2) are included to overwrite the SCCP CdPA GTA field.

DigitAction Expansion is provisioned via the PDBI Enter Network Entity or Update Network Entity commands. DigitAction Expansion can also be modified via the Add an NE and Update an NE GUI screens.

Digit Action DELCCPREFIX

The Digit Action to delete country code if present and prefix database entity feature allows the DELCCPREFIX Digit Action to be applied to the Called Party Global Title Address (CdPA GTA) when the GTA has a National format, as well as when the GTA has an International format. The DELCCPREFIX option in the SCCPOPTS table specifies how the DELCCPREFIX digit action is applied to a Called Party Global Title Address (CdPA GTA).

• When the SCCPOPTS:DELCCPREFIX option is set to PFXWCC, the DELCCPREFIX digit action is applied to the CdPA GTA only when the address has a International format. The Country Code is deleted and the GTA is prefixed with the Entity ID.
• When the SCCPOPTS:DELCCPREFIX option is set to PFX4ALL, the DELCCPREFIX digit action is applied to the CdPA GTA in all cases. For an International format, the Country Code is deleted and the GTA is prefixed with the Entity ID. For a National format, the GTA is prefixed with the Entity ID.

The chg-sccpopts command is used to specify the delccprefix parameter value to configure the DELCCPREFIX Digit Action functionality.

G-Port SCCP Service Re-Route

The G-Port SCCP Service Re-Route feature is used when the G-Port subscriber database is incoherent with MPS data and the GTT data is valid. The G-Port SCCP Service Re-Route feature provides the capability to re-route the traffic from the EAGLE to other G-Port subscriber database nodes and inform the originating nodes to re-route the G-Port service related traffic to other G-Port service nodes.

The G-Port SCCP Service Re-Route feature is designed to handle and control re-routing of G-Port traffic from an affected node to alternate nodes within an operators network. This feature is an optional feature and does not affect the normal G-Port functionality. This feature also provides the option to mark G-Port offline to perform a controlled re-routing during this state.

Multiple Country Code

The Multiple Country Code (MULTCC) feature supports up to 10 MULTCCs for customers having one MNP node servicing several countries, or areas with differing country codes. The MULTCCs are not used for conditioning of non-International numbers to International format for database lookup. The MULTCCs are used for the construction of the Mobile Station Roaming Number (MSRN) parameter in the case of a Send Routing Information acknowledgement (SRI Ack) message from G-Port, and in certain cases for the formulation of the SCCP CdPA. The EFCC parameter in STPOPTS is used for conditioning of numbers to International format when necessary, and also for constructing the MSRN and SCCP CdPA parameters in addition to a MULTCC list. The MULTCC list is optional. If no values are provisioned, G-Port uses the DEFCC to process messages. If values are provisioned, G-Port automatically uses both the DEFCC and the MULTCC to process messages. The chg-gsmopts command along with the MULTCC and NMULTCC parameters are used to provision Multiple Country Code list entries.

MSISDN Truncation Support for G-Port

The MSISDN Truncation Support for G-Port feature is an optional feature that allows an operator to specify a certain number of digits to be deleted from the beginning of the National MSISDN (MSISDN without Country Code) prior to formulating the MSRN parameter of the SRI Ack message. This feature only changes the behavior of the encoding of the MAP MSRN parameter in an SRI Ack message formulated by the EAGLE. It does not affect the encoding of any other parameters or any other messages processed by G-Port. The International MSISDN is 12 digits long, and the RN is 5 digits long. So when the RN is added to form the MSRN parameter, it will exceed 15 digits in length. Some carriers require MSISDN digits to be truncated when formulating the MSRN parameter of SRI Ack message in G-Port to maintain a maximum length of 15 digits. This feature works in conjunction with the MULTCC Support feature. The DefCC and MULTCC table are used to determine which digits are the CC and which digits are the National MSISDN. If a match is not found on the leading digits of the International MSISDN, then the truncation is not performed and standard G-Port processing is followed. The chg-gsmopts command along with the MISDNTRUNC parameter is used to set-up the MSISDN Truncation Support feature.

Mobile-Originated Based GSM SMS Number Portability

The MO-Based GSM SMS NP feature provides network information to the Short Message Service Center (SMSC) for subscribers using the GSM network. This information allows the SMSC to select a protocol to deliver SMS messages to the called party. For more information about the MO-Based GSM SMS NP feature, refer to MO SMS User's Guide.

Mobile-Terminated Based GSM SMS Number Portability

The Mobile Terminated (MT)-Based GSM SMS NP feature allows wireless operators to route short message service (SMS) messages destined to mobile subscribers within a number portability (NP) environment. If the MT-Based GSM SMS NP feature is not enabled and turned on, then messages are processed by the G-Port feature.

In general, there are two kinds of messages of concern to number portability: call related and non-call related. The call-related messages query the HLR in real time for delivering the call to the subscriber. The G-port feature handles these.

Non-call related messaging involves the Short Message Service Center (SMSC) querying the HLR for the destination subscriber for SMS delivery. For SMS, these query messages are called SRI_SM. The HLR responds to these messages with routing information that can be used by the querying node (SMSC) to deliver the SMS message. In this feature, the EAGLE intercepts SRI_SM messages destined to the HLR and replies with routing information for out-of-network destination subscribers.

The MT-Based GSM SMS NP feature intercepts SRI_SM messages and replies with routing information for out-of-network destination subscribers using the following process:

1. An SRI_SM message from the SMSC is intercepted by the EAGLE before the message reaches the home location register (HLR).
2. The message destination address (SCCP Called Party GTA), is extracted, the digits are conditioned, and lookup is performed in the Real Time Database (RTDB).
3. If the destination address/subscribers belongs to a foreign network, then a reply message is sent to the SMSC with routing information. If the destination address/subscribers belongs to a local network, then the SRI_SM message is relayed to the HLR according to the options set for normal G-Port processing.

The feature provides configurable options for controlling processing of SRI_SM messages and the content of the response:

• Selecting the SMSC response message type and digit format
• Specifying when an RTDB lookup is considered to be successful
• Specifying the format of digits encoded in the response message.

Mobile-Terminated Based GSM MMS Number Portability

The MT-Based GSM MMS NP feature provides routing information to the Multimedia Message Service Center (MMSC) for subscribers using the GSM network. This information can be used by the MMSC to route the MMS messages to the called party.

Note:

The MT-Based GSM MMS NP feature can be used only in conjunction with the MT-Based GSM SMS NP feature.

The MT-Based GSM MMS NP feature intercepts SRI_SM messages and replies with routing information for out-of-network destination subscribers using the following process:

1. An SRI_SM message from the MMSC is intercepted by the EAGLE before the message reaches the home location register (HLR).
2. The message destination address (SCCP Called Party GTA), is extracted, the digits are conditioned, and lookup is performed in the RTDB.
3. If the destination address/subscribers belongs to a foreign network, then a reply message is sent to the MMSC with routing information. If the destination address/subscribers belongs to a local network, then the SRI_SM message is relayed to the HLR according to the options set for normal G-Port processing.

The feature provides the following configurable options for controlling processing of SRI_SM messages and the content of the response:

• Selecting the MMSC response message type and digit format
• Specifying when an RTDB lookup is considered to be successful
• Specifying the format of digits encoded in the response message.

Routing Options

The ETSI standards for SRF-based MNP define two routing options, direct routing and indirect routing. G-Port supports both options:

• With direct routing, the network where the call is originated is responsible for determining whether the called party has ported and routing the call to the new subscription network.

• With indirect routing, this is the responsibility of the network that originally owned the number.

Dialed Number Lengths

Number lengths vary between countries and may even vary within a country. As a result, the G-Port subscriber database structure supports numbers of varying length in a flexible way without necessitating software modifications. A maximum number length of 15 digits for ported numbers is supported. This length is based on the maximum length for MSISDN numbers as defined in the ETSI GSM 03.03 standard.

SRF vs INAP Mobile Number Portability

The ETSI standards are defined so that GSM carriers can choose to implement either Signaling Relay Function (SRF)-based (using MAP protocol) MNP or IN-based (using INAP protocol) MNP. G-Port supports only the SRF-based solution for MNP. (INAP-based MNP processing is similar to wireline networks; this function is supported by the INP feature.)

SRF-based MNP processing involves intercepting existing MAP messages to check for ported numbers. For call-related messages, G-Port acts as an NP HLR in the case where the number has been exported, by responding to the switch with a MAP SRI Ack message. For calls to imported numbers and non-call related messages, G-Port performs message relay.

G-Port SRI Query for Prepaid

The G-Port SRI Query for Prepaid feature allows the EAGLE to provide portability information to a Service Control Point (SCP) database. This information enables the database to determine the network used by a called subscriber. The G-Port SRI Query for Prepaid feature enables the following Message Signal Unit (MSU) values to be provisioned in the EAGLE GSERV table:

• translation type (TT)—The TT of the called party (CdPA)
• originating point code (OPC)—The OPC from the message transfer part (MTP) layer
• global title address (GTA)—The GTA of the calling party (CgPA)

These values are used to determine whether an SRI should receive G-Port SRI Query for Prepaid service or normal G-Port SRI service.

Service Portability (S-Port) support for the G-Port SRI Query for Prepaid feature allows subscribers to retain their same subscriber numbers after moving between different network technologies (example: IS41 and GSM) within the same operator. Service Portability applies to only own-network subscribers.

GSM MAP SRI Redirect to Serving HLR

The GSM MAP SRI Redirect to Serving HLR feature provides the capability to resolve the incompatibility introduced by the proprietary implementation of the GSM MAP SRI message. This feature is an extension to the G-Port protocol. The GSM MAP SRI Redirect to Serving HLR feature is compatible with other G-Port enhancement features.

Additional Subscriber Data Support

The G-Port feature is enhanced to support new Mobile Station Routing Number (MSRN) formatting options that use Additional Subscriber Data (ASD). ASD information is inserted into the outgoing SRI Ack messages. If the GSMOPTS:MSRNDIG digit formatting option specifies the use of ASD information and a successful database lookup returns ASD, then the ASD is encoded into the outgoing message and the existing behavior for encoding messages for G-Port is followed.

ROP Support

The G-Port feature allows Small Geographic Areas (CNLs) to be grouped into Large Geographic Areas (ROPs). This grouping simplifies the routing and allows a call to be delivered as close to the interconnection destination as possible. ROP information is stored in the Generic Routing Number (GRN) field. Both CNL and ROP information can be provisioned for a single subscriber entry; however, only one of the CNL or ROP fields can be selected for the outgoing message.

The G-Port SRI Query for Prepaid, SRI Redirect, IS41 GSM Migration (IGM), AINPQ, INP, and ATINP features also support ROP.

Include Optional CUG Parameter in SRI Ack Messages

The Include Optional CUG Parameter in SRI Ack Messages functionality allows an existing Closed User Group-CheckInfo (CUG-CheckInfo) parameter in an incoming SRI message to be included in the outgoing SRI Ack message.

The Include Optional CUG Parameter in SRI Ack Messages functionality is controlled by the encodecug option of the chg-gsmopts command off and on parameters. The encodecug option of the chg-gsmopts off/on parameter can be changed only if the G-Port or IGM feature is enabled.

The CUG-CheckInfo parameter in an incoming SRI message is copied in the original sequence to the outgoing SRI Ack message when these conditions are met:

• The encodecug option of the chg-gsmopts command is set to on.

• The CUG-CheckInfo parameter is present in an incoming SRI message.

• The CUG-CheckInfo parameter in an incoming SRI message is encoded in definite length format that is less than or equal to 30 bytes.

If the three conditions descibed above are met, the original CUG-CheckInfo sequence from the incoming SRI message is copied into the SRI Ack message. If encoded in the SRI Ack message, the CUG-CheckInfo parameter is located after the MSRN (Tag = 0x04) and before the MSISDN (Tag = 0x8C) or NPS parameter (Tag = 0x8D), if either MSISDN or NPS parameter is present. The CUG-CheckInfo parameter in an SRI Ack message uses Tag = 0xA3.

If the CUG-CheckInfo parameter is greater than 30 bytes and all other conditions for encoding are met, then only the CUG-Interlock and CUG-OutgoingAccess parameters are copied from an incoming SRI message to the outgoing SRI Ack message. The ExtensionContainer is omitted.

When the encodecug option is set to off, the CUG-CheckInfo parameter is not encoded in the SRI Ack message.

If the encodecug option is set to on but the CUG-CheckInfo parameter in an incoming SRI message uses an indefinte length format, the CUG-CheckInfo parameter is not encoded in the SRI Ack message.

Route SRI_SM and ReportSMSDeliveryStatus for Non-local or Ported-out Subscribers using GTT

The Route SRI_SM and ReportSMSDeliveryStatus for Non-local or Ported-out Subscribers using GTT functionality modifies SRI_SM and ReportSMSDeliveryStatus messages to allow routing of the message to an alternate network using Global Title Translation (GTT). This functionality allows processing to occur when the Directory Number (DN) in the database is associated with both the Service Point (SP) and Generic Routing Number (GRN) network elements and the GRN is not present in the EAGLE HomeRN table, or when the subscriber is ported out and associated with the Routing Number (RN).

The message is altered by changing the SCCP Called Party Address (CdPA) to the Country Code (CC) + GRN + DN or to CC + RN + DN. This alteration allows GTT to redirect the query to an alternate network. If a CC is not located in the DN, then the SCCP CdPA is converted to a GRN + DN or RN + DN format.

This conversion is performed only on ITU TCAP Begin MSUs with Op Code of SRI_SM or ReportSMSDeliveryStatus delivered to the GPort or MNP service selector for processing. If the MT-Based GSM SMS NP feature or the IS41 GSM Migration (IGM) feature generates a response for the SRI_SM message, then this functionality is not applicable.

The Route SRI_SM and ReportSMSDeliveryStatus for Non-local or Ported-out Subscribers using GTT functionality is controlled by the srismgttrtg option of the chg-gsmopts command off and on parameters. The srismgttrtg option of the chg-gsmopts off/on parameter can be changed only if the G-Port or IGM feature is enabled.

Option to Suppress NumberPortabilityStatusIndicator in SRI Ack

The Option to Suppress NumberPortabilityStatusIndicator in SRI Ack functionality allows the Number Portability Status Indicator (NPSI) to be omitted from all SRI Ack messages.

The Option to Suppress NumberPortabilityStatusIndicator in SRI Ack functionality is controlled by the encodenps option of the chg-gsmopts command off and on parameters. The encodenps option of the chg-gsmopts off/on parameter can be changed only if the G-Port or IGM feature is enabled. The default setting of the encodenps option is on.

The NumberPortabilityStatusIndicator parameter is encoded in an SRI Ack message when these conditions are met:

• The encodenps option of the chg-gsmopts command is set to on.

• SRI is considered MAP Phase 2+.

• DN Portability Type is 0, 1, 2, or 36. (Portability Type = 36 is encoded as Portability Type = 0.)

Note:

MAP Phase is set based on the dialog portion, unless the dialog portion does identify. If the dialog portion does not identify, then the MAP Phase is based on GSMOPTS:DEFMAPVR.

The NumberPortabilityStatusIndicator parameter is not encoded in any SRI Ack message if the encodenps option of the chg-gsmopts command is set to off.

G-Port Considerations

• G-Port can be turned on, but cannot be turned off.

• The G-Port, A-Port, IGM, G-Flex C7 Relay, INP, and AINPQ features can run concurrently on an EAGLE node.

• When G-Port and G-Flex run on the same node, interactions between the two features must be addressed.

• G-Port and North American LNP are mutually exclusive on an EAGLE node, unless the Dual ExAP Configuration feature is enabled.

• G-Port SCCP Service Re-Route Capability is not supported for the Prepaid Short Message Service Intercept feature.

• G-Port, A-Port, or IGM must be turned on before the MNP Circular Route Prevention feature can be turned on.

2.2 G-Port Protocol

2.2.1 Main Functions

G-Port and MNPCRP provide these main functions:

Message Discrimination

Because the G-Port feature provides translation of ported numbers, the feature provides a method to identify which messages should receive G-Port or GTT. This task of identification is provided by a service selector table in which the user can define G-Port service for a combination of selectors. If a selector match is not found then, G-Port falls through to GTT.

RN Prefix Deletion - SCCP

The decoded SCCP CdPA digits can have a RN concatenated with the MSISDN number in two forms:

• RN + DN

• CC+RN+DN

When the SNAI is either RNIDN, RNNDN, or RNSDN, G-Port compares the decoded MSISDN number with the list of provisioned home RN prefixes defined in the RTDB. If a match is found, G-Port removes the RN digits from the number.

Number conditioning, if required, is performed after deleting the RN.

When the SNAI is CCRNDN, G-Port first compares the CC to the DEFCC/MULTCC list:

• If CC is not equal to the DEFCC/MULTCC, then no prefix deletion is performed and G-Port processing continues.

• If CC=DEFCC/MULTCC then, G-Port compares the digits after CC with the list of provisioned Home RN prefixes that are defined in the RTDB. If a match is found, then G-Port strips off the RN digits from the number. If no match is found, the no-prefix deletion is performed and G-Port processing continues.

RN Prefix Deletion - TCAP

The decoded MAPMSISDN digits can have a RN concatenated with the MSISDN number in two forms:

• RN + DN

• CC+RN+DN

The MAP NAI is used to determine the type: International, National or Subscriber. If MNPCRP is OFF, RN prefix deletion is not attempted. If MNPCRP is ON, then RN prefix deletion is attempted on all MSISDNs. If the MAPNAI indicates International, then a check is performed for the DEFCC/MULTCC prefix on the MSISDN. If DEFCC/MULTCC is detected, then HomeRN deletion is attempted using the CC+RN+DN format. All other MSISDNs will use the RN+DN format. G-Port compares the decoded MSISDN number with the list of provisioned home RN prefixes defined in the RTDB. If a match is found, the G-Port strips off the RN digits from the number.

Number conditioning, if required, is performed after deleting the RN.

If CC+RN+DN search is performed, G-Port compare the digits after CC with the list of provisioned home RN prefixes defined in the RTDB. If a match is found, G-Port strips off the RN digits from the number. If no match is found, then no prefix deletion is performed and G-Port processing continues.

Number Conditioning

The RTDB stores international MSISDNs only. The received MSISDN number or SCCP CdPA digits may need to be converted to an international number to perform a database lookup.

When G-Port is required to be performed on a message and the number is not international (that is, the NAI of MSISDN number is “National (Significant) Number” or “Subscriber Number”, or the SNAI is NATL or SUB or RNNDN or RNLDN), the National/Local to International number is triggered.

For a National (Significant) Number, the received CdPA/MAP MSISDN digits are prepended with the default country code; for a Subscriber number, the CdPA/MAP MSISDN digits are prepended with the default country code and the default network code.

Database Lookup

G-Port performs an RTDB lookup using the MSISDN in international format. RTDB individual subscriber records have precedence over subscriber range records. If the MSISDN does not represent an individual subscriber in the RTDB, then the subscriber range records are searched. If the MSISDN is not represented by an individual subscriber record or by a subscriber range record in the RTDB, then the RTDB lookup fails.

If the first RTDB lookup fails but the MSISDN contains an even number of digits, ends with zero, and does not include a method for determining the exact number of digits (for example, an odd/even indicator), then the G-Port repeats the RTDB lookup using the MSISDN without the last digit.

If both RTDB lookup attempts fail, then G-Port does not process the message further; the message is passed to GTT to be routed out of the EAGLE.

Since a DN may be the target of the A-Port, G-Port, or IS41 GSM Migration (IGM) message processing in a hybrid network, where an operator owns both GSM and IS41 networks, message processing call disposition is based on which applications are turned on. Table 2-1 shows call dispositions for these configurations:

G-Port Only (Table 2-1)

G-Port and IGM (Table 2-2)

The following notations apply to Table 2-1 and Table 2-2:

PT = Portability Type for the DN values:

0 – Not known to be ported

1 – Own number ported out

2 – Foreign number ported to foreign network

3 – Prepaid1, Prepaid Short Message Service Intercept (PPSMS) subscriber on server #1

4 – Prepaid2, PPSMS subscriber on server #2

5 – IS41 GSM migrated subscriber with only GSM handset active

6 – Prepaid3, PPSMS subscriber on server #3

through

35– Prepaid32, PPSMS subscriber on server #32

36 - Not identified to be ported

FF - No Status, None, No Portability Type

RN = Routing Number

SOR = Support for Optimal Routing

SRI = Send Routing Information

SP = Signaling Point

NE = Network Entity

Table 2-1 summarizes the actions taken based on the database result, and assumes that the IS41 GSM Migration feature is not turned on.

Table 2-1 G-Port Database Lookup

Message Type	MSISDN Found	Entity Result	MNPCRP on and HomeRN deleted from DN	Action
SRI	Yes	RN	No	SRI Ack using RN prefix. If Portability Type = 0, 1, 2, or 36 is present with MSISDN, NPS will be encoded. For Portability Type = 36, NPS will have a value of 0.
SRI	Yes	RN	Yes	Issue UIM 1256 and fall through to GTT
SRI	Yes	SP	N/A	Forward SRI message to the destination using SP data
SRI	Yes	None	No	Portability Type result is 0, 1, 2, 36, or no status. SRI Ack using MSISDN. Portability Type = 36 or no status will map to NPS=0 in response. Portability Type = 0, 1, or 2 will have the values of 0, 1, or 2.
SRI	Yes	None	No	Portability Type result is 3 - 35. Fall through and perform GTT
SRI	Yes	None	Yes	Portability Type result is 0, 1, 2, 36, or no status. Issue UIM 1256 and fall through to GTT
SRI	No	N/A	N/A	Fall through and perform GTT
Non-SRI or SRI-SOR	Yes	RN	No	Forward the message to the next node using RN data
Non-SRI or SRI-SOR	Yes	RN	Yes	Issue UIM 1256 and fall through to GTT
Non-SRI or SRI-SOR	Yes	SP	N/A	Forward the message to the next node using SP data
Non-SRI or SRI-SOR	Yes	None	No	Fall through and perform GTT
Non-SRI or SRI-SOR	Yes	None	Yes	Issue UIM 1256 and fall through to GTT
Non-SRI or SRI-SOR	No	N/A	N/A	Fall through and perform GTT

Table 2-2 IGM and G-Port Message Processing

NE/PT	SRI	SRI_SM	Other GSM
RN and PT = 0	MIGRPFX = single: ACK (use GSM2IS41 prefix) MIGRPFX = multiple: ACK (RN from EPAP)	SRI_SM_ACK with Return Error Component	Relay
RN and PT≠ 0	ACK (RN from EPAP)	Relay	Relay
SP and PT = 5	Relay	Relay	Relay
SP and PT ≠ 5	Relay	Relay	Relay
No NE and PT = 5	GTT	GTT	GTT
No NE PT= 0, 1, 2, or No PT	ACK (no NE)	GTT	GTT
No DN entry found	GTT	GTT	GTT

Database lookup results in the following:

1. Fall through to GTT or

2. Relaying the message to the destination as noted in the database or

3. Returning an acknowledge message to the originating switch.

Message Relay describes how the EAGLE formulates a relayed message or a returned Ack.

Message Relay

The rules for formatting the SCCP CdPA GTA field are based on the value specified in the DigitAction field. If DigitAction = none, the EAGLE does not overwrite the SCCP CdPA GTA. For all other values, the EAGLE formats the SCCP CdPA GTA according to the value assigned to DigitAction. Refer to Table 2-3 for examples of DigitAction Expansion on the SCCP CdPA GTA of an outgoing message when the Entity ID = 1404 and the default country code = 886...

Table 2-3 DigitAction Applications

DigitAction	Value in Incoming CdPA GTA	Value in Outgoing CdPA GTA	Meaning
none	886944000213	886944000213	No change to the Called Party GTA (default)
prefix	886944000213	1404886944000213	Prefix Called Party GTA with the entity id
replace	886944000213	1404	Replace Called Party GTA with the entity id
insert	886944000213	8861404944000213	Insert entity id after country code. (CC + Entity Id + NDC + SN)
delccprefix	886944000213	1404944000213	Delete country code and add prefix (No action is taken if country code is not present.)
delcc	886944000213	944000213	Delete country code
spare1	886944000213	treated as none	No change to the Called Party GTA (default)
spare2	886944000213	treated as none	No change to the Called Party GTA (default)

Returning Acknowledgement

When an SRI Ack message is returned, the EAGLE follows the SRI Ack encoding rules along with these enhancements for added flexibility:

1. Allow users to specify which SRI parameter (the TCAP MSRN parameter) encodes the RN (and/or DN) information.

2. Allow users to specify the value to encode the Nature of Address field of the TCAP MSRN parameter.

3. Allow users to specify the value to encode the Numbering Plan field of the TCAP MSRN parameter.

MSRN Encoding

Refer to Commands User's Guide for detailed descriptions of the chg-gsmopts command, parameters, and parameter values.

The MSRN is encoded based on the MSRNDIG, MSRNNAI and DN NAI values.

If MSRNDIG and MSRNNAI are not provisioned in the GSMOPTS table, these default values are used:

• MSRNDIG = RN

• MSRNNAI = National Significant (0x02)

• MSRNNP = ISDN (0x01)

MSRN NAI that is not International (0x01) or Subscriber (0x04) is treated as National Significant (0x02) for the digit encoding format. The NAI field will be encoded with the original GSMOPTS value.

DN and DN NAI are determined by the SRIDN setting.

• If SRIDN = SCCP, then the DN is from CdPA and DN NAI is the Service NAI for the message as specified in the Service Selector information.

• If SRIDN = TCAP, then the DN is the MSISDN and DN NAI is the MSISDN NAI from the MAP portion of the message.

DN NAI that is not International (0x01) or Subscriber (0x04) is treated as National Significant (0x02). DN digits used for encoding have the HomeRN prefix, ST, and filler digits deleted. The DN is carried by an incoming message. An RN, SP, ASD, or GRN is extracted from the RTDB. If the RN is not found during the RTDB lookup, then MSRN is encoded with MAP MSISDN information.

When searching for a CC match, the DEFCC list and MULTCC list are searched. The Best CC Match from the DEFCC list or MULTCC List is referred to as MatchCC. The Best CC Match is defined as the largest number of identical leading digits during a comparison of Country Code digits against an MSISDN. If a DEFCC list or MULTCC list contains 1, 12, and 124 and the MSISDN is 12345, then the Best CC Match is 12.

If DEFCC or DEFNDC is not provisioned, those fields are ignored during MSRN encoding. No insertion or deletion of the DEFCC or DEFNDC occurs

To keep the transmitted MSRN from being too large after RN addition, MSISDN National Leading Digit (NLD) Truncation is allowed. When provisioned, a selected number of leading digits are removed from the National portion of the MSISDN before encoding the MSRN.

Some MSRN generation rules are not applied because the rules represent scenarios that result in processing of the message in a way that does not require MSRN generation. For example, RTDB queries are performed based on DS values in International format. If G-Port encounters an MSISDN with a National NAI and the STPOPTS:DEFCC value is not defined, then the MSISDN cannot be converted to the International format as required for an RTDB query. The system does not generate an MSRN if an RTDB query cannot be performed first.

SRI Ack Message Encoding

Table 2-4 summarizes the possible changes by G-Port to the TCAP/MAP fields.

Table 2-4 G-Port SRI Ack message: TCAP/MAP Portion

Field	Value
Invoke ID	copied from SRI Invoke Id
Sequence Tag	0x30 for MAP Phase 1 or Phase 2 0xA3 for MAP Phase 2+
Parameter Sequence Length	adjusted based on the parameters included in the response
IMSI digits	RFIMSI digits obtained from SRF data associated with the RN - If SRFIMSI is not available, then the GSMOPTS table will be searched for an MCCMNC match to the CCNC from DN. If an MCCMNC match is not available, DEFMCC is padded to 5 digits and used. If DEFMCC is not provisioned, a length of 0 is used.
CUG-CheckInfo	copied from the SRI message
MSRN NAI	obtained from MSRNNAI in GSMOPTS table or National
MSRN Numbering Plan	obtained from MSRNNP in GSMOPTS table or E.164
MSRN digits	Refer to MSRN Encoding.
MSISDN (optional)	copied from SRI MSISDN parameter sequence based on whether non-concatenated MSRN is selected with MSRNDIG option in the GSMOPTS table
NumberPortabilityStatus (optional)	Number Portability Status parameter will be included in the SRI Ack message only if: MAP phase is 2+. The ENCODENPS option in the GMSOPTS table is set to on and the DN is found in the RTDB with Portability Type (PT) = 0, 1, 2, or 36. The ENCDNPSPTNONE option in the GMSOPTS table is set to on and the DN is found in the RTDB with PT = 255. The ENCDNPSDNNOTFOUND option in the GMSOPTS table is set to on and the DN is not found in the RTDB. SRI Ack message is sent by G-Port SRI Query for Prepaid feature if the DN is not found in the RTDB.

Determination of MAP Phase

The phase or version of the MAP protocol is determined from the ACN.

If ACN received is found to be from SRI (in the form: map-ac-locInforetrieval(s) version xx, such as ‘04000010005xx’), the last byte (‘xx’) of the ACN determines the version/phase of the MAP, as shown in Table 2-5. If the ACN does not match the one defined in ETSIGSM 03.18, the MAP version/phase is assumed to from thedefmapvr parameter of GSMOPTS specification.

Table 2-5 MAP Phase Determination

Last Byte in ACN	MAP Phase
00	Specified by defmapvr parameter of a GSMOPTS command
01	Phase 1
02	Phase 2
03	Phase 2+
Greater than 3	Specified by defmapvr parameter of a GSMOPTS command

G-Port Message Handling

G-Port performs message handling in the following steps.

1. The message arrives at the EAGLE route-on-gt. The EAGLE decodes the SCCP portion and uses the data to perform the G-Port selection based on the CdPA GT fields other than the ES and GTAI. The result of the selection provides a service indicator. The service indicator is G-Port if it is determined that MNP-SRF is required. If a G-Port selector does not match the incoming GT fields, the message is passed on for GTT selection.

2. If step #1 indicates that MNP SRF is required and the message is not a UDTS generated by the EAGLE, then the EAGLE performs SSN-based discrimination. If the message is a UDTS generated by the EAGLE, then regular GTT is performed on the message.

3. MNP-SRF first decodes the Operation Code of the MAP message to distinguish the SRI or SRI_SM message from the rest. If the Operation Code is SRI , the OR Interrogation indicator is absent, and the GSMOPTS parameter SRIDN=TCAP, then the MSISDN parameter is decoded from the MAP portion of the message. If the Operation Code is SRI_SM and the GSMSMSOPTS parameter SRISMDN=TCAP, then the MSISDN parameter is decoded from the MAP portion of the message. If the value is SCCP for GSMOPTS parameter SRIDN (if an SRI message) or for GSMSMSOPTS parameter SRISMDN (if an SRI_SM message), or if the message is not SRI or SRI_SM, then , the digits available in the SCCP CdPA GTAI are used for database lookup.

4. The decoded DN from either the MAP MSISDN or SCCP CdPA is conditioned to an international number before performing the database lookup. The conditioning which is performed depends on whether the digits are obtained from SCCP or TCAP part of the message.

   • If the digits are from the SCCP part, the number conditioning is based on SNAI value. The RN prefix deletion is performed, followed by conversion to an international number based on its value. Conversion to international format is based on DEFCC and DEFNDC, as required. If the incoming number is CCRNDN, DEFCC and MULTCC are used to determine the Best Match CC to locate the RN digits for RN prefix deletion

   • If the digits are from the MAP part, the number conditioning is based on NAI of MSISDN parameter. Prefix deletion is performed if MNPCRP is on. The number is converted to an international number, if necessary. Conversion to international format is based on DEFCC and DEFNDC, as required. If the incoming number is international, DEFCC and MULTCC are used to determine if the format is CCRNDN or RNIDN. If a Best Match CC is located, then it is used to locate the RN digits for RN prefix deletion.

5. The database lookup is performed in two steps:

   • The exception or individual number database is searched for a match. If the match is found, the data associated with this entry is considered.

   • If the conditioned number is absent in the exception database, the number range database is searched. If the match is found, the data associated with this range entry is considered. If the search is unsuccessful, the result is no match.

6. If the number is found and an RN prefix is present for this entry, then:

   • for SRI message: If MNPCRP is off or if MNPCRP is on with CRP on Translation Type off and a HomeRN was not present in the incoming DN (a HomeRN was not deleted from the SCCP CdPA/MAP MSISDN), then G-Port generates an SRI Ack message with the RN prefix in the Routing Number parameter.

     • If SRI_SM GTT Routing is on, then SRI_SM messages are not relayed. The CdPA GTA in the message is modified in CC + RN + DN format, or RN + IDN format if a CC match is not found in the leading digits. The NAI of CdPA GTA is set to International and the SRI_SM message falls through to GTT.

   • for non-SRI message: If MNPCRP is off or if MNPCRP is on and a HomeRN was not present in the incoming DN (a HomeRN was not deleted from the SCCP CdPA), then G-Port uses the translation data for the number to alter the CdPA digits and route the message to the destination.

   • for SRI or non-SRI message: If MNPCRP is on and a HomeRN was present in the incoming DN (a HomeRN was deleted from the SCCP CdPA/MAP MSISDN), then G-Port generates UIM #1256 and the message falls through to GTT. In most network implementations the message contains RN+DN which will cause a GTT failure. This GTT failure results in the EAGLE sending a UDTS to the originator if the Return Message on Error flag was set in the incoming UDT.

7. If the number is found and an SP entity is present for this entry, G-Port uses the SP translation data as the number to route the message to the destination. This is true whether or not the MNPCRP feature is on. However, the SRI_SM message is not relayed if SRI_SM GTT Routing on, the GRN is associated along with the SP entity with the DN, and the GRN is not present in the HomeRN table. In this case, the CdPA GTA of the SRI_SM is modified in CC + GRN + DN format , or GRN + IDN format if a CC match is not found in the leading digits. The NAI of CdPA GTA is set to International and the SRI_SM message falls through to GTT.

8. If the number is found and neither SP nor RN data is associated with it (direct routing case with number not known to be ported or not identified to be ported), these occur:

   • for SRI message: If MNPCRP is off, or if MNPCRP is on and no HomeRN is present in the incoming DN (a HomeRN was not deleted from the SCCP CdPA/MAP MSISDN), and the portability type associated with the DN entry is other than 3 through 35, then G-Port generates an SRI Ack message with the MSISDN in the Routing Number parameter. If MNPCRP is off, or if MNPCRP is on and no HomeRN was present in the incoming DN (a HomeRN was not deleted from the SCCP CdPA/MAP MSISDN), and the portability type associated with the DN entry has a value of 3 through 35, then the SRI falls through to GTT and no SRI Ack message is generated.

   • for non-SRI message: If MNPCRP is off, or if MNPCRP is on and no HomeRN is present in the incoming DN (a HomeRN was not deleted from the SCCP CdPA), then the message falls through to GTT.

   • for SRI or non-SRI message: If MNPCRP is on and a HomeRN was present in the incoming DN (a HomeRN was deleted from the SCCPCdPA/MAP MSISDN), then G-Port generates UIM #1256, and the message falls through to GTT. In most network implementations, the message contains RN+DN which will cause a GTT failure. This GTT failure results in the EAGLE sending a UDTS to the originator if the Return Message on Error flag was set in the incoming UDT.

   • The Number Portability Status Indicator (NPSI) is encoded in the SRI Ack message if either (1) GSMOPTS:ENCODENPS=ON and the DN is associated with PT = 0, 1, 2, 36 or (2) GSMOPTS:ENCDNPSPTNONE=ON and the DN is associated with PT = no status

9. If the number is not found in the database, then the GSMOPTS:SRIDNNOTFOUND option is consulted if the query is not G-Port SRI Query for Prepaid. if the query is identified as G-Port SRI Query for Prepaid, then an SRI Ack message is returned. The Number Portability Status Indicator (NPSI) is encoded in the SRI Ack message if GSMOPTS:ENCDNPSDNNOTFOUND=ON.

10. If the GSMOPTS:SRIDNNOTFOUND option is set to SRINACK, then a negative acknowledgement is generated in response to the message.

11. If the GSMOPTS:SRIDNNOTFOUND option is set to GTT, then GTT is performed on the message.

2.2.2 G-Port Call Flows

This section contains several illustrative sample call flows: G-Port supports all call flows identified in GSM 03.66 other than noted exceptions. This section contains a mix of call flows using both indirect and direct routing.

These call flows, including calls to imported or non-ported numbers, show one possible scenario regarding how messages are routed in the network and where various stages of GTT are performed. G-Port may perform intermediate or final GTT depending on the message received and provisioned data.

Several call flows refer to non-call related messages. Examples of non-call related messages are SRI for Short Message Service and SRI for Optimal Routing.

In all G-Port call flows, the MSISDN used for the database search is converted to an international number, if necessary, prior to the database search.

Mobile Terminated Call to Non-Ported or Imported Number (Indirect Routing)

The first call flow example is for a mobile terminated call to a non-ported or imported number by indirect routing. Refer to Figure 2-1.

Figure 2-1 Mobile Terminated Call by Indirect Routing

1. The originating exchange sends an IAM message to GMSCB in the subscription network. When the number is imported, the original number range owner network has already performed a database lookup and determined the new subscription network (Routing Number). As shown in the figure, this could be sent in the IAM along with the MSISDN.

2. GMSCB sends an SRI request to the MNP-SRF. This request may or may not contain the new TT = SRI. Global title information triggers G-Port processing. The MNP-SRF determines the message is an SRI and uses the MSISDN from the MAP message to search the database. A match is found with no Routing Number and an HLR GT address for HLRB, or no match is found and falls through to GTT, producing a routing to HLRB. Alternatively and not illustrated in the figure, GTT could route to another node, possibly in a different network.

3. The message is routed to HLRB.

4. HLRB responds to GMSCB with an SRI ack. This message can be GT routed through the STP or MTP routed.

5. GMSCB sends an IAM with the roaming number to the visited network.

Mobile Originated/Terminated Call to an Exported Number (Direct Routing)

This call flow example is for a call that is mobile originated or terminated to an exported number by direct routing. Refer to Figure 2-2.

Figure 2-2 Call to an Exported Number by Direct Routing

This call flow assumes the originating network is not the subscription network. If indirect routing were used in this example, the originating network would first route the call to the number range owner network, according to pre-portability rules, where the MNP-SRF and NPDB are accessed to locate the Routing Number.

1. When the call is originated, VMSCA sends an IAM message to GMSCA.

2. GMSCA sends an SRI request to the MNP-SRF. This may or may not contain the new TT = SRI. Global title information triggers G-Port processing. The MNP-SRF determines the message is an SRI and uses the MSISDN from the MAP message to search the database. A match is found with the Routing Number field populated.

3. The MNP-SRF responds to GMSCA with an SRI ack containing the Routing Number prefixed to the MSISDN number as the Roaming Number.

4. GMSCA sends an IAM with the roaming number to the subscription network. The Routing Number is used by GMSCA and possibly by transit exchanges to route the call to the subscription network.

MO/MT Call to a Number Not Known to be Ported (Direct Routing)

This call flow example is for a call that is mobile originated (MO) or mobile terminated (MT) to a foreign number that is not known to be ported by direct routing. Refer to Figure 2-3.

Figure 2-3 MO/MT Call to Number Not Known to be Ported (Direct Routing)

This call flow assumes the originating network is not the subscription network.

1. When the call is originated, VMSCA sends an IAM message to GMSCA.

2. GMSCA sends an SRI request to the MNP-SRF. This request may or may not contain the new TT = SRI. Global title information triggers G-Port processing. The MNP-SRF determines the message is an SRI and uses the MSISDN from the MAP message to search the database. A match is found, but the Routing Number and HLR Address fields are not populated.

3. The MNP-SRF responds to GMSCA with an SRI ack containing the MSISDN number.

4. GMSCA sends an IAM with the roaming number to the subscription network.

Non-Call Related Message for Non-Ported Number (Indirect Routing)

This call flow example is for a non-call related message for a non-ported number by indirect routing. Refer to Figure 2-4.

Figure 2-4 Non-Call Related Message for Non-Ported Number

1. The Interrogating Network Entity (INE) sends the non-call related message to MNP-SRFB in the number range owner network. The SCCP CdPA contains the MSISDN number of the subscriber and the TT. The TT may be either 0 as shown in the figure, or another value depending upon the service, such as TT=17 for CCBS service.

2. Global title information triggers G-Port processing. MNP-SRFB determines the message is non-call related (i.e. not an SRI that doesn't require Optimal Routing) and uses the MSISDN from the SCCP CdPA to search the database. No match is found, so MNP-SRFB uses GTT to locate the GT address associated with the MSISDN to route the message to HLRB.

Non-Call Related Message for Ported Number (Indirect Routing)

This call flow example is for a non-call related message for a ported number by indirect routing. Refer to Figure 2-5.

Figure 2-5 Non-Call Related Message for Ported Number

1. The Interrogating Network Entity (INE) sends a non-call related message to MNP-SRFA in the number range owner network. The SCCPCdPA contains the MSISDN number of the subscriber and the TT. The TT may be either 0 as shown in the figure, or another value depending upon the service, such as TT=17 for CCBS service.

2. Global title information triggers G-Port processing. MNP-SRFA determines the message is one requiring message relay (that is, not an SRI that doesn't require Optimal Routing) and uses the MSISDN from the SCCPCdPA to search the database. A match is found, and MNP-SRFA uses the Message Relay GT address associated with the match to route the message to the subscription network.

3. MNP-SRFB receives the message and determines the message is one requiring message relay (that is, not an SRI that does not require Optimal Routing). It checks if the SCCPCdPA begins with a Prefixed RN. If it does, it removes the prefix. In either case, it uses the MSISDN from the SCCPCdPA to search the database. A match is found, and MNP-SRFB uses the HLRGT address associated with the match to route the message to HLRB.

Non-Call Related Message for Ported or Non-Ported Number (Direct Routing)

This call flow example is for a non-call related message for either a ported or non-ported number by direct routing. Refer to Figure 2-6.

Figure 2-6 Non-Call Related Message for Any Number

This call flow assumes the originating network is not the subscription network.

1. The Interrogating Network Entity (INE) sends the non-call related message to MNP-SRFA in the interrogating network. The SCCP CdPA contains the MSISDN number of the subscriber and the TT. The TT may be either 0 as shown in the figure, or another value depending upon the service, such as TT=17 for CCBS service.

2. Global title information triggers G-Port processing. MNP-SRFA determines the message is one requiring message relay (that is, not an SRI that doesn't require Optimal Routing) and uses the MSISDN from the SCCP CdPA to search the database.

   • If a match is found (ported case), MNP-SRFA uses the Message Relay GT address associated with the match to route the message to the subscription network.

   • If a match is not found (non-ported case), MNP-SRFA uses GTT to route the message to MNP-SRFB.

3. MNP-SRFB receives the message and determines the message requires message relay (that is, not an SRI that does not require Optimal Routing). It checks to see if the SCCP CdPA begins with a Prefixed RN. If so, it removes the prefix. In either case, it uses the MSISDN from the SCCP CdPA to search the database.

   • If a match is found (imported case), MNP-SRFB uses the HLR GT address associated with the match to route the message to HLRB.

   • If a match is not found, MNP-SRFB uses GTT to route the message to HLRB.

2.3 Network Perspectives

GSM Mobile Number Portability (G-Port) provides the capability for a mobile subscriber to change the GSM subscription network within a portability cluster while retaining the original MSISDNs. Because the IMSI is not ported, the recipient network of the porting process issues a new IMSI for the ported subscriber.

In a Public Land Mobile Network (PLMN) that supports G-Port, SCCP messages that are sent to an HLR can be relayed by either:

• An MNP-SRF

• An EAGLE with G-Port depending on the type of message (call-related or non-call-related) and on the porting status of the called subscriber.

For call-related messages, MNP-SRF either generates an SRI_ACK response with the routing number if the number is ported, or relays the message to an appropriate HLR if the number is not ported.

For non-call related messages, MNP-SRF can modify the SCCP called party address and route the message to the HLR of the recipient network or to the subscription network.

Figure 2-7 shows the location of the G-Port in a GSM network. Note the basic functions G-Port performs:

• G-Port performs a query/response for call-related SRI messages when the number is ported-out, not known to be ported, or not identified to be ported.

• G-Port performs a message relay function for non-call-related messages and for call-related messages when the number is non-ported or ported-in.

G-Port performs the following actions based on the message received and number status:

• If the message received is call-related SRI (not-SOR) and the number is ported-out, not known to be ported, or not identified to be ported, G-Port sends the SRI ack to the MSC with the Routing Number information in the MAP portion of the message.

• If the number is ported-out and the message received is non-call related (non-SRI), G-Port performs a message relay function and forwards the translated message based on the Routing Number information.

• If the number is non-ported or ported-in, G-Port performs an HLR translation and forwards the translated message to the HLR.

An additional user option allows configuration of G-Port to modify the above processing as follows:

• If the number is not found in the RTDB (individual or range), then G-Port returns a negative acknowledgement in response to an SRI.

Figure 2-7 G-Port Node in GSM Network

2.4 G-Port Considerations

The following items must be considered before installing and operating the G-Port feature.

1. SRI responses are routed by both MTP and Global Title Translation.

2. The maximum length of the Application Context Name Object Identifier is 32 digits.

3. For G-Port 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.

4. G-Port Message Relay to the EAGLE local subsystem is not supported.

5. Only the first 21 digits of the CdPA are decoded for G-Port 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).

6. With the Hex Digit Support for GTT feature enabled and turned on, Message Signaling Units (MSUs) containing either decimal or hexadecimal digits in the Called Party Address (CdPA) are processed. Unless the Hex Digit Support for GTT feature is enabled and turned on, GTT processes decimal digits only.

   If the Hex Digit Support for GTT feature is not enabled and not turned on and an operator or 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, then the operator must enter the RN + DN number ranges as DN ranges in the RTDB. The beginning and ending DNs can be only 15 digits, which may not be sufficient for an RN + DN.

7. In this document, Mobile Number Portability (MNP) applies within a single portability cluster. This is defined as a set of networks in a country or multi-country region having a common numbering plan and across which a subscriber already inside the cluster can port. Any individual G-Port node is required to support only an MNP within such a portability cluster.

8. The EAGLE examines the TCAP portion of the MAP message to determine the message type. Although GSM 03.66 defines a new translation type for SRI-MNP messages, G-Port does not rely upon the use of this TT.

9. The routing number found in the database is either prefixed to the dialed number to form a new concatenated roaming number that is returned to the switch, or is sent on its own as the roaming number.

10. No MAP overload procedures, as defined in GSM 09.02, need to be supported by G-Port.

11. All non-call related messages affected by MNP contain the MSISDN number in the SCCP CdPA. In the case of the SRI message, G-Port may get the number from the MAP level.

12. TCAP operation codes uniquely distinguish MAP SRI messages and do not change from one phase (or version) of MAP to another.

13. PCs or PC + SSNs that are in the entity table of the database and referenced by subscriber entries do not necessarily have the required data present on the EAGLE to route messages to them. For example, the point code may not have a route or the PC + SSN may not be in the MAP table for a final GTT. In this event, a UIM is output only when a message is discarded because of the lack of data.

14. The parameters of the SRI Ack message generated by G-Port are based solely on the provisioned data or options; they are not based on the MAP phase of the SRI message. For example, if the message received is phase 1 or 2, MSRNDIG=RN, and the portability status is “NotKnowntobePorted”, G-Port generates an SRI Ack message containing IMSI, MSRN, MSISDN, and NPS parameters, despite the MSISDN and NPS parameters not being defined for phase 1 or 2.

15. If SRFIMSI is not provisioned with an RN entity and an incoming message is an SRI message, G-Port sets IMSI parameter as one of these options:

    1. If a CCNDC>MCCMNC match in GSMOPTS is found, then the MCCMNC is encoded.

    2. If DefMCC is provisioned in GSMOPTS, then DefMCC is encoded.

    3. Zero digits are encoded.

16. G-Port uses the MTP route for the SRI Ack message, even when the final GTT is performed on the response.

17. When the concatenated number (RN + MSISDN) option is selected for encoding the Routing Info (MSRN) in the SRI Ack message, G-Port encodes the complete concatenated number because the concatenated number length may otherwise exceed 16 digits, which is the maximum allowed in MSRN.

18. Routing an SRI Ack message to a network domain different from the network domain from which query was received is not supported by G-Port. Routing failures or unexpected routing of SRI Ack messages may result.

19. Post G-port, EAGLE routes the Eagle generated SRI_ACK message only to the translated point code as result of fall back to GTT. It does not check the MRNSET or MAPSET mapped to the GT translation. It will not check even the DEFAULT MRNSET or MAPSET.

2.5 General Numbering Requirements

Incoming called party numbers, from the SCCP portion, destined for IGM processing are conditioned to fit the GDB requirements where possible. The following factors are used to condition the SCCP numbers.

• Based on provisioning: If the GTT selectors available in the incoming message match an entry in the IGM selector table, then the service numbering plan from the selector table entry uses that number's numbering plan. Further conditioning is applied based on this new numbering plan.

• Based on configurable options: If the GTT selectors available in the incoming message match an entry in the IGM selector table, then the service nature of address from the selector table entry uses that number's nature of address. Further conditioning is applied based on this new nature of address.

• If the nature of address is Subscriber, the default CC + default NC (network code for E.164) are prepended to the number. The default codes to be used by the EAGLE must be previously provisioned by the EAGLE operator. If not, a UIM is issued, and the message falls through to GTT.

Numbers with fewer than five digits after the above conditioning are not used for IGM. In this case, a UIM is issued, and the message falls through to GTT.

Numbers with more than fifteen digits after the above conditioning are not used for IGM. In this case, a UIM is issued, and the message falls through to GTT.

2.6 G-Port SCCP Service Re-Route Capability

This feature is designed to handle and control re-routing of G-Port traffic from an affected node to alternate nodes within an operators network. This feature is an optional feature and doesn't affect the normal G-Port functionality. This feature consists to the following main functions:

• Service State

• MNP Re-Routing

• MNP Capability Point Codes

G-Port SCCP Service Re-Route Capability is not supported for the Prepaid SMS Intercept feature. G-Port SCCP Service Re-Route Capability is supported for the IS-41 to GSM Migration feature.

Service State

Service state is part of the G-Port SCCP Service Re-Route Capability. Service state is used to indicate the current state of G-Port, either ONLINE or OFFLINE . Service state also gives the user the option to mark G-Port as OFFLINE or ONLINE based on the current behavior. If a G-Port problem is identified, G-Port can be marked OFFLINE to initiate the re-routing procedure. This feature also provides the option to mark G-Port OFFLINE to perform a controlled re-routing during this state.

MNP Re-Routing

MNP Re-Routing is an optional feature and is enabled by defining a list of alternate PCs or by defining the GTT option. G-Port re-routing is activated by marking G-Port OFFLINE . When G-Port is OFFLINE and alternate PCs are provisioned, any messages destined for G-Port are re-routed to the available alternate PCs that are defined for G-Port. If alternate PCs are not provisioned or none are available, then the GTT option is used. If the GTT option is set to YES, then messages destined for G-Port will fall through to GTT as part of the re-routing procedure.

Re-Routing is applied to all G-Port messages (based on SRVSEL). There is no distinction of DPC of the messages. The DPC of the message can be either True, Secondary, or Capability Point code.

MNP Capability Point Codes

Capability Point Codes (CPC) are also supported for G-Port. The use of MNP capability point code aids the adjacent nodes in knowing about G-Port outages. When G-Port is brought down though administrative commands, all traffic destined to this G-Port node will generate a Transfer Prohibited (TFP) message to the adjacent node about the G-Port CPC. The TFP response to the adjacent node causes the traffic originating nodes to stop sending G-Port traffic to this node. All G-Port traffic coming into this node is sent to the alternate G-Port nodes. Adjacent nodes will initiate route-set-test procedures after receipt of the TFP response.

If the messages are destined to the EAGLE true point code, then TFP messages are not generated when the G-Port service is OFFLINE. The originator would not be aware of the outage.

Once G-Port is back in service on the EAGLE, a Transfer Allowed (TFA) message is sent to the traffic adjacent nodes in response to route-set-test message. The traffic originating nodes will then start sending G-Port traffic to the original G-Port node.

MNP Capability point codes can be provisioned when the G-Port feature is on. There can be more than one Capability Point Code assigned to G-Port CPC Type.

When the G-Port feature is turned on and the G-Port service state is set to offline, the user can change the service to online at any point. After the feature is turned online, G-Port starts processing messages if at least one Service Module card is IS-NR.

The G-Port service can be set to OFFLINE at any point. This causes the EAGLE to stop processing G-Port traffic and re-routing is performed.

The G-Port service state is persistent. Booting the OAM or all the Service Module cards will not change the service state. Commands must be used to change the service state.

G-Port supports up to seven alternate PCs per domain. All six domains (ANSI, ITU-I, ITU-I Spare, ITU-N, ITU-N Spare, and ITU-N24) are supported. An entire set of alternate PCs is considered as a re-route set. A GTT option is supported for G-Port re-route. When the G-Port service is OFFLINE, G-Port messages fall though to GTT based on the GTT option. This option is set to YES by default.

G-Port SCCP Service Re-Route Capability Summary

If the G-Port service is not normal (because the RTDB is not in sync with MPS or if cards are misrouting G-Port messages) then the G-Port service state should be changed to OFFLINE .

Before changing G-Port service to OFFLINE , it should be decided what kind of re-routing will be used during the outage. The EAGLE supports re-routing data to alternate point codes or falling through to GTT as two possible options. Rerouting to alternate point code has priority over falling through to GTT. Examples of the two options follow:

Option 1

Define alternate point codes to re-route G-Port traffic. This is the recommended option. Up to 7 alternate G-Port nodes can be provisioned to re-route all the incoming G-Port traffic. Once provisioned, the G-Port service can be changed to OFFLINE . This example has any incoming being G-Port traffic being load-shared to point codes based on the relative cost.

chg-sccp-serv:serv=gport:pci1=1-1-1:rc1=10:pci2=2-2-2:rc2=10:pc i3=3-3-3:rc3=10:pci4=4-4-4:rc4=10

chg-sccp-serv:serv=gport:pci1=5-5-5:rc1=10:pci2=6-6-6:rc2=10:pc i3=7-7-7:rc3=10:pci4=8-8-8:rc4=10

chg-sccp-serv:serv=gport:state=offline

Option 2

With this option default GTT translations are provisioned for G-Port service. Then the chg-sccp-serv command is used to provision GTT=YES. All G-Port messages will fall through to GTT. An example command follows:

chg-sccp-serv:serv=gport:gtt=yes (it is yes by default)

Once the G-Port re-routing data is provisioned, G-Port service can be changed to OFFLINE . At this point all G-Port traffic will be re-routed. The use can take necessary steps to correct the G-Port service on the node. Until all the cards or enough cards are in active state with valid G-Port database, G-Port service should not be changed to ONLINE .

Table 2-6 shows the actions taken when the G-Port service is offline, a message arrives at the affected node requiring G-Port service, and Servicve Module cards are available.

Table 2-6 G-Port SCCP Service Re-Route Capability Summary

Result of service selector	DPC	Alternate point code defined and available	GTT to be performed as fall through	Message Handling	Network Management
G-Port	G-Port Capability PC	Yes	N/A	Re-Route to alternate point code based on relative cost	TFP concerning CPC
G-Port	G-Port Capability PC	No*	Yes	Fall through to GTT and perform GTT	TFP concerning CPC
G-Port	G-Port Capability PC	No*	No	Generate UDTS (return cause = network failure)	TFP concerning CPC
G-Port	G-Port Capability PC	Not Defined	Yes	Fall through to GTT and perform GTT	TFP concerning CPC
G-Port	G-Port Capability PC	Not Defined	No	Generate UDTS (return cause = no xlation for this addr)	TFP concerning CPC
Not G-Port	G-Port Capability PC	N/A	N/A	Perform appropriate Service/GTT	None
G-Port	True or Secondary PC or non-G-Port CPC	Yes	N/A	Re-Route to alternate point code based on relative cost	None
G-Port	True or Secondary PC or non-G-Port CPC	No*	No	Generate UDTS (return cause = network failure)	None
G-Port	True or Secondary PC or non-G-Port CPC	No*	Yes	Fall through to GTT and perform GTT	None
G-Port	True or Secondary PC or non-G-Port CPC	Not Defined	Yes	Fall through to GTT and perform GTT	None
G-Port	True or Secondary PC or non-G-Port CPC	Not Defined	No	Generate UDTS (return cause = no xlation for this addr)	None
Not G-Port	True or Secondary PC or non-G-Port CPC	N/A	N/A	Perform appropriate Service/GTT	None
* Alternate point codes are defined and unavailable (prohibited or congested).

Table 2-7 shows the actions of LIM re-route functionality when Service Module cards are unavailable or down.

Table 2-7 G-Port LIM Re-Route Message Handling Summary

Routing Indicator in Incoming Message	DPC	Full or Partial Failure	G-Port Service Status	Message Handling	Network Management
rt-on-gt	G-Port Capability PC	Full	N/A	Generate UDTS	TFP concerning CPC, UPU
rt-on-gt	Non G-Port Capability PC	Full	N/A	Generate UDTS	TFP concerning CPC, UPU
rt-on-gt	True PC	Full	N/A	Generate UDTS	UPU
rt-on-gt	G-Port Capability PC	Partial*	ONLINE	Generate UDTS	None
rt-on-gt	True PC or non G-Port Capability PC	Partial*	ONLINE	Generate UDTS	None
rt-on-gt	G-Port CPC	Partial*	OFFLINE	Generate UDTS	TFP concerning CPC, UPU
rt-on-gt	True PC or non-G-Port CPC	Partial*	OFFLINE	Generate UDTS	None
* A partial failure occurs if some Service Module cards are available but are overloaded.

2.7 MT-Based GSM SMS NP

The Mobile Terminated-Based GSM SMS NP feature allows wireless operators to route short message service (SMS) messages destined to mobile subscriber within a number portability environment. If the Mobile Terminated (MT)-Based GSM SMS NP feature is not enabled and turned on, then messages are processed by the G-Port feature.

The MT-Based GSM SMS NP feature allows database lookup to be performed on short message service (SMS) messages that are routed from a short message service center (SMSC).

The MT-Based GSM SMS NP feature intercepts SRI_SM messages and sends response messages with routing information for out-of-network destination subscribers using the following process:

1. An SRI_SM message is intercepted by the EAGLE before the message reaches the home location register (HLR).
2. The message destination address (SCCP Called Party GTA) is extracted, the digits are conditioned, and lookup is performed in the database.
3. If the destination address/subscribers belongs to a foreign network, then a reply message is sent to the SMSC with routing information. If the destination address/subscribers belongs to a local network, then the SRI_SM message is relayed to the HLR.

2.7.1 Options

The MT-Based GSM SMS NP feature provides configurable options for controlling processing of SRI_SM messages and the content of the response:

• Selecting the SMSC response message type and digit format
• Specifying when a database lookup is considered to be successful
• Specifying the format of digits encoded in the response message.

2.7.2 Feature Control Requirements

The MT-Based GSM SMS NP feature has the following control requirements:

• The defcc parameter in the chg-stpopts command must be set to a value other than none before the feature can be turned on.
• The defmcc parameter in the chg-gsmopts command must be set to a value other than none before the feature can be turned on.
• A FAK for part Part number 893-0200-01
• The G-Port feature must be enabled before the MT-Based GSM SMS NP feature can be enabled.
• The G-Port feature must be turned on before the MT-Based GSM SMS NP feature can be turned on.
• The MT-Based GSM SMS NP feature cannot be enabled if the LNP feature is enabled.
• A temporary FAK cannot be used to enable the feature.
• The feature cannot be turned off after it has been turned on.

2.7.3 System Options for MT-Based GSM SMS NP

The system level options that control the MT-Based GSM SMS NP feature are stored in the GSMSMSOPTS database table. The MT-Based GSM SMS NP feature must be enabled before the following options in the GSMSMSOPTS table can be provisioned.

The content of the GSMSMSOPTS table is used to help perform number conditioning, response generation, and other feature-specific options. Table 2-8 shows the options stored in the GSMSMSOPTS table, their possible values, and the action taken for each value.

Table 2-8 MT-Based GSM SMS NP Options

GSMSMSOPTS Option	Value	Action in the EAGLE
MTSMSIMSI	RN	This setting specifies the required format of digits which will be encoded in the "IMSI" parameter of the SRI_SM return result response (ACK). Note: The MT-Based GSM SMS NP feature will require STPOPTS:DefCC to be set before the feature can be activated. Also, DefCC will not be allowed to change to "NONE" as long as this feature is turned ON.
	RNDN
	CCRNDN
	DN
	SRFIMSI	IMSI is encoded from the "SRFIMSI" parameter from the RTDB entity.
	MCCRNDN (default)	IMSI is encoded as MCCRNDN. The MCC will be encoded using the GSMOPTS:DefMCC setting. Note: The MT-Based GSM SMS NP feature requires GSMOPTS:DefMCC to be set before the feature can be turned on. GSMOPTS:DefMCC will not be allowed to change to "NONE" as long as this feature is turned ON.
MTSMSNNI	RN (default)	This setting specifies the required format of digits which will be encoded in the "Network Node Number" parameter ISDN digits field within the LocationInfoWithLMSI TCAP parameter in the of the SRI_SM response (ACK). In the response, the Nature of Number field will always be encoded as "International" (0x1) and the numbering plan will always be encoded as ISDN/Telephony Numbering (Rec ITU-T E.164) (0x1).
	RNDN
	CCRNDN
	DN
	SRFIMSI	IMSI is encoded from the "SRFIMSI" parameter from the RTDB entity.
	MCCRNDN	IMSI is encoded as MCCRNDN. The MCC will be encoded using the GSMOPTS:DefMCC setting. Note: The MT-Based GSM SMS NP feature requires GSMOPTS:DefMCC to be set before the feature can be turned ON. GSMOPTS:DefMCC will not be allowed to change to "NONE" as long as this feature is turned ON.
	NONE	This parameter is not encoded in the response message. The LocationInfoWithLMSI TCAP parameter is included; the Network Node number sub-parameter is present; however the length of the parameter is 0.
MTSMSTYPE	SP	When the lookup in the RTDB has entitytype=SP, then the lookup is considered successful.
	RN (default)	When the lookup in the RTDB has entitytype=RN, then the lookup is considered successful.
	SPRN	When the lookup in the RTDB has entitytype=SP or RN, then the lookup is considered successful.
	ALL	When the lookup in the RTDB has entitytype=SP or RN or no_entity, then the lookup is considered successful.
	NONSP	When the lookup in the RTDB does not have an entitytype SP, then the lookup is considered successful. This could mean that no entity was found or an entity with type RN was found.
	Note: This option is applied to messages in which the source is considered to be a Home SMSC.
MTSMSACKN	ACK (default)	This indicates that when the SRI_SM lookup is considered successful, a SRI_SM_ACK (Return Result Last) is sent back.
	NACK	This indicates that when SRI_SM look is considered successful, a SRI_SM_NACK (Return Error) is sent back.
	Note: This option is applied to messages in which the source is considered to be a Home SMSC.
MTSMSDLTR	NO (default)	This option specifies if delimiter digit(s) need to be inserted in the MTSMSIMSI and MTSMSNNI digits. A value of NO means that no delimiter is inserted.
	PRERN	This option specifies that a delimiter (MTSMSDLTRV) is to be inserted before the RN when the RN is used in the MTSMSIMSI and MTSMSNNI digits. (RN included in the digit format is MTSMSDLTRV + RN from RTDB)
	POSTRN	This option specifies that a delimiter (MTSMSDLTRV) is to be inserted after the RN when the RN is used in the MTSMSIMSI and MTSMSNNI digits. (RN included in the digit format is RN from RTDB + MTSMSDLTRV)
MTSMSDLTRV	1-5 hex digits	This specifies if delimiter digit(s) need to be inserted in the MTSMSIMSI and MTSMSNNI if required (per MTSMSDLTR). This value can consist of 1-5 hexadecimal digits. A value must be defined here before MTSMSDLTR can be set to PRERN or POSTRN. Once set, the MTSMSDLTRV can never be configured to "NONE" again.
MTSMSNAKERR	0-255 (default is 0x1 - Unknown Subscriber)	This specifies the TCAP error choice code to be included in the SRI_SM_ACK generated by SMS_MT. Note: This option will affect only the Error code choice byte. Certain error code choices (e.g., systemFailure and callBarred) have additional mandatory data as per GSM specifications. However, the MT-Based GSM SMS NP feature will not encode any additional data in SRI_SM_NACK. Note: The MTSMSNAKERR is applicable to responses generated to both the SMSC and MMSC.
MTSMSCHKSRC	YES	This parameter value specifies that the SCCP CgPA GTA of the message will be used to determine whether the source of the message is a Home SMSC. If this option is set to YES and the SCCP CgPA GTA is present and there is not a match in the Home SMSC list, the source of the message is not considered to be a Home SMSC. In this case, the message is considered inapplicable for MT-SMS processing. If this option is YES and SCCP CgPA GTA is not present or has a 0 length, then it is assumed that the source is a Home SMSC. If this option is YES and SCCP CgPA GTA is present and there is a match in the Home SMSC list, then the message source is considered to be Home SMSC. Note: The order of checks performed follows: Home MMSC check is performed. If a Home MMSC check is to be performed (The MT-Based GSM MMS NP Feature is turned ON and GSMSMSOPTS:MTMMSGTA is not “NONE”), the SCCP CgPA GTA will be compared against GSMSMSOPTS:MTMMSGTA for a match. A match identifies the source to be a Home MMSC. This option (MTSMSCHKSRC) does not influence this first check for Home MMSC. If the Home MMSC check is not successful, AND MTSMSCHKSRC is YES, then Home SMSC check is required if SCCP CgPA GTA is present.
	NO (default)	This parameter value specifies that EAGLE will not validate the SCCP CgPA GTA for Home SMSC check. If the initial check for Home MMSC is not successful and if this option is NO, then the source is assumed to be Home SMSC. This option may be used by the service provider to disable SCCP CgPA-checking for Home SMSC check, if the service provider ensures that only in-network nodes will send SRI_SM and receive the response generated by this feature.
SRISMDN	SCCP	After number coditioning, G-Port uses the SCCP CdPA as the database search key for SRI_SM messages. MNP Circular Routing (MNPCRP) uses the SNAI processing of G-Port to determine if the DN of the incoming SRI_SM message contains an RN concatenated with the DN. If no RN is present, then the entire DN is used as the database search key after number conditioning. If an RN is present, the HomeRN table is searched to determine: - if the RN is a HomeRN to be stripped from the DN before performing the query. - if the RN is not a HomeRN allowing the entire DN to be used as the database search key.
	TCAP	G-Port decodes up to 22 digits in the MSISDN of the SRI_SM message. The 22nd digit can only be a STOP (x0F) digit; in this case, G-Port strips the last digit and uses the remaining digits to perform number conditioning for database lookup. G-Port conditions the decoded MSISDN number to International number based on the NAI value of the MSISDN. If the number of digits is greater than 15 after number conditioning is performed, the MSU falls through to GTT and UIM 1246 is issued. After number coditioning, G-Port uses the MAP MSISDN as the database search key for SRI_SM messages. HomeRN prefix deletion from SRI_SM messages is performed only when MNP Circular Route Prevention (MNPCRP) is turned on. This is similar to SRI message processing when SRIDN=TCAP. If MNPCRP is turned on and a circular route is detected, then MNPCRP processing is applied to the SRI_SM message. If the SRI_SM message is to be relayed after deleting HomeRN lookup results in SP, the TCAP section of the SRI_SM message is reformatted and the HomeRN digits are removed from the MSU. If GSMOPTS parameter SRISMGTTRTG=ON and an MT-Based GSM SMS NP response is not required, then to comply with GTT the SCCP CdPA digits are conditioned to international number (CC+NDC+SN) depending on the SNAI. An SRI_SM Nack is generated if decoding the TCAP MSISDN parameter of the SRI_SM returns an error for any of these reasons: Length field of TCAP MSISDN parameter is invalid. Length of MSISDN is less than the mandatory fixed length. The number of digits is zero or greater than 21. (UIM 1294 is generated.)

2.7.4 MT-Based GSM SMS and MMS NP Call Flows

This section illustrates the sequence of messages that occur in the processing of SMS and MMS messages destined for mobile-terminated subscribers in a number portability environment. Two scenarios exist:

• The called subscriber that is in the same network as the calling subscriber
• The called subscriber that is in a different network from the calling subscriber

MT-Based GSM SMS and MMS NP Call Flow for In-Network Subscriber

Figure 2-8 depicts the message and control flows for a called subscriber that is in the same network as the calling subscriber.

Figure 2-8 MT-Based GSM SMS and MMS NP Call Flow for In-Network Subscriber

Call considerations:

• The TCAP calling party is a wireless GSM subscriber.
• The TCAP called party is a non-ported or ported-in wireless subscriber that belongs to the same carrier.
• The call type is SMS or MMS.
• SMSC has to be reconfigured to generate SRI_SM to the HLR, regardless of called subscriber number being in or out of its own numbering range.
• In case called subscriber is ported-in, it has to be provisioned individually.
• In case called subscriber is TDMA, the EAGLE Migration feature ensures that the message gets delivered in the TDMA network.

MT-Based GSM SMS and MMS NP Call Flow for Other-Network Subscriber

Figure 2-9 depicts the message and control flows for a called subscriber that is a different network from the calling subscriber.

Figure 2-9 MT-Based GSM SMS and MMS NP Call Flow for Other-Network Subscriber

Call considerations:

• The TCAP calling party is a wireless GSM subscriber.
• The TCAP called party is a non-ported or ported-out wireless subscriber that belongs to a different carrier from the TCAP calling party.
• The call type is SMS or MMS.
• The SMSC (Short Message Service Center) has to be configured to associate the RNs to their respective carriers.
• The called subscriber must be provisioned individually.

2.8 MT-Based GSM MMS NP

The Mobile Terminated (MT)-Based GSM MMS NP feature allows wireless operators to route Multimedia Message Service (MMS) messages destined to mobile subscriber within a number portability (NP) environment. If the MT-Based GSM MMS NP feature is not enabled and turned on, then messages are processed by the G-Port feature.

The Mobile Terminated (MT)-Based GSM MMS NP feature allows database lookup to be performed on MMS messages that are routed from a Multimedia Message Service Center (MMSC).

The MT-Based GSM MMS NP feature intercepts SRI_SM messages and sends response messages with routing information for out-of-network destination subscribers using the following process:

1. An SRI_SM message is intercepted by the EAGLE before it reaches the home location register (HLR).
2. The message destination address (SCCP Called Party GTA) is extracted, the digits are conditioned, and lookup is performed in the database.
3. If the destination address/subscribers belongs to a foreign network, then a reply message is sent to the MMSC with routing information. If the destination address/subscribers belongs to a local network, then the SRI_SM message is relayed to the HLR or according to the options set for normal G-Port routing.

2.8.1 Options

The MT-Based GSM MMS NP feature provides the following configurable options for controlling processing of Multimedia Message Service (MMS) routing request messages and the content of the response:

• Selecting the Multimedia Message Service Center (MMSC) response message type and digit format
• Specifying when a database lookup is considered to be successful
• Specifying the format of digits encoded in the response message
• Specifying the number of digits in the SRI_SM ACK response message

2.8.2 Feature Control Requirements

The MT-Based GSM MMS NP feature has the following control requirements:

• The MT-Based GSM MMS NP feature must be enabled and turned on.
• A FAK for part Part number 893-0241-01
• The feature cannot be turned off after it has been turned on.
• A temporary FAK cannot be used to enable the feature.

2.8.3 System Options for MT-Based GSM MMS NP

The system level options that control the MT-Based GSM MMS NP feature are stored in the GSMSMSOPTS database table. The MT-Based GSM MMS NP feature must be enabled before the GSMSMSOPTS table can be provisioned.

The content of the GSMSMSOPTS table is used to help perform number conditioning, response generation, and other feature-specific options. Table 2-9 shows the feature-specific options stored in the GSMSMSOPTS table, their possible values, and the action taken for each value.

Note:

The options described in Table 2-9 are accessible only when the MT-Based GSM MMS NP feature is enabled. Processing of MSUs from MMSCs will also require the use of the GSMSMSOPTS options described for the MT-Based GSM SMS feature in Table 2-8.

Table 2-9 MT-Based GSM MMS NP Options

GSMSMSOPTS	Value	Action in the EAGLE
MTMMSGTA	5-21 hex digits (default is NONE)	This option pertains to Home MMSC check. When an SCCP CgPA GTA is present in the message, this option is used to compare the SCCP CgPA GTA of the incoming SRI_SM message to determine whether the originator is a Home MMSC. If a match is found, the MTMMSTYPE and MTMMSACKN options are used to determine whether SRI_SM ACK or NACK is to be sent, and the conditions when lookup is considered to be successful for MMS. The nature of match is a “Prefix match”. That is, the leading digits must match all the digits provisioned in MTMMSGTA. Note: The digits for compare can have more than the number of digits configured in MTMMSGTA This option can be set to NONE at any time. A value of NONE implies that the special processing of MMS is not required, and MT-Based SMS NP processing will follow. A setting of NONE will not match any SCCP CgPA GTA.
MTSMSTYPE	SP	When the lookup in the RTDB has entitytype=SP, then the lookup is considered successful.
	RN (default)	When the lookup in the RTDB has entitytype=RN, then the lookup is considered successful.
	SPRN	When the lookup in the RTDB has entitytype=SP or RN, then the lookup is considered successful.
	ALL	When the lookup in the RTDB has entitytype=SP or RN or no_entity, then the lookup is considered successful.
	NONSP	When the lookup in the RTDB does not have an entitytype SP, then the lookup is considered successful. This could mean that no entity was found or an entity with type RN was found.
	Note: This option is applied to messages in which the source is considered to be a Home SMSC. Duplicate options are provided for this parameter for MTMMS and MTSMS in order to be able to control processing of messages from the Home MMSC independently from those coming from a Home SMSC.
MTMMSACKN	ACK (default)	This indicates that when the SRI_SM lookup is considered successful, a SRI_SM_ACK (Return Result Last) is returned.
	NACK	This indicates that when SRI_SM lookup is considered successful, a SRI_SM_NACK (Return Error) is returned.
	Note: This option is applied to messages in which the source is considered to be a Home SMSC. Duplicate options are provided for this parameter for MTMMS and MTSMS in order to be able to control processing of messages from the Home MMSC independently from those coming from a Home SMSC.
MTMMSENTYLEN	1 - 15 (default is NONE)	This indicates the maximum number of digits used from the entity value of a returned RN, SP, or SRFIMSI entity for MMS processing. Digits that exceed the configured maximum are concatenated. numbers. The parameter value NONE indicates that all returned digits are used.
MTMMSLEN	1 - 24 (default is NONE)	This indicates the maximum number of digits used in the returned IMSI or NNN fields for MMS processing. Digits that exceed the configured maximum are concatenated. numbers. The parameter value NONE indicates that all digits are used.

2.8.4 MT-Based GMS MMS NP Call Flows

The MT-Based GMS MMS NP feature call flows are identical to those used by the MT-Based GMS SMS NP feature and are described in MT-Based GSM SMS and MMS NP Call Flows.

2.9 G-Port SRI Query for Prepaid

When the G-Port SRI Query for Prepaid feature is enabled and turned on, incoming SRI TT, OPC, and GTA values are compared against the values in the GSERV table. If no match is found, or if no values are provisioned in the GSERV table, normal G-Port SRI processing is performed on the message. If a match is found for one or more of the values, the message is treated as a Prepaid Query. The G-Port SRI Query for Prepaid feature affects only SRI messages. All other messages, including SRI-SM and SRI-GPRS messages, are processed by normal G-Port service.

After an SRI message is identified as requiring G-Port SRI Query for Prepaid service, the EAGLE performs a Mobile Number Portability (MNP) database lookup on the Mobile Station Integrated Services Digital Number (MSISDN). The results of the lookup are returned to the SCP that originated the query.

A TCAP/MAP error specifically related to a decoding error in the SRI MSISDN parameter causes an “Unsupported/Unexpected Data Value” MAP error. All other TCAP/MAP errors cause the message to be relayed to a Home Location Register (HLR), which then returns the appropriate MAP error based on the status of the subscriber (e.g. Unknown, Barred, etc.)

If a TCAP error is detected, then the message relay is based on information in the Real Time Database (RTDB). SCCP level errors cause the return on a UDTS message to the Prepaid SCP.

The G-Port SRI Query for Prepaid feature requires a Feature Access Key and cannot be turned off after it is turned on.

Service Portability support for G-Port SRI Query for Prepaid

Service Portability support for the G-Port SRI Query for Prepaid feature allows the RTDB GRN Entity digits to be used in digits formats for own-network GSM and IS41 subscribers in place of the SP entity digits or RN/PT=0 entity digits, where RN or SP is Network Entity Type and PT is Portability Type.

The Service Portability support for the G-Port SRI Query for Prepaid feature requires a Feature Access Key. The Service Portability feature can be turned off after it is turned on.

The SPORTTYPE configuration option indicates whether Service Portability will apply to SRI Query for Prepaid messages for own-network subscribers (IS41, GSM, or all). When Service Portability is applicable, GRN digits are used in place of RN digits during construction of the MSRN.

The Default RN configuration option is applicable in general to Number Portability, and can be used whether Service Portability feature is on or off. When the Service Portability feature is on, the Default RN is applicable in cases where Service Portability usage of GRN does not apply. Refer to Table 2-10 and Table 2-11. When the Service Portability feature is off, Default RN digits can be used for own-network subscribers during construction of the MSRN. Refer to Table 2-12.

G-Port SRI Query for Prepaid must be enabled to provision the GSMOPTS:DFLTRN option. Both G-Port SRI Query for Prepaid and Service Portability must be enabled to provision the GSMOPTS:SPORTTYPE option. RTDB DN data must be provisioned with RN or SP entity for Service Portability support for the G-Port SRI Query for Prepaid feature. Other EPAP-related features that use the GRN field are mutually exclusive with the Service Portability feature.

Table 2-10 RN Digits for Subscriber Type = RN/0 (Own Subscriber - IS41) with Service Portability On

GSMOPTS:SPORTTYPE Value	GSMOPTS:DFLTRN = NONE	GSMOPTS:DFLTRN = DIGITS
NONE	RN=RTDB RN Entity ID	RN=DFLTRN
GSM	RN=RTDB RN Entity ID	RN=DFLTRN
IS41	RN=GRN If GRN is not provisioned, DFLTRN is not used. MSISDN digits are sent. The subscriber is incorrectly provisioned and needs to have a GRN assigned.
ALL	RN=GRN If GRN is not provisioned, DFLTRN is not used. MSISDN digits are sent. The subscriber is incorrectly provisioned and needs to have a GRN assigned.

Table 2-11 RN Digits for Subscriber Type = SP (Own Subscriber - GSM) with Service Portability On

GSMOPTS:SPORTTYPE Value	GSMOPTS:DFLTRN = NONE	GSMOPTS:DFLTRN = DIGITS
NONE	RN=RTDB SP Entity ID	RN=DFLTRN
GSM	RN=GRN If GRN is not provisioned, DFLTRN is not used. MSISDN digits are sent. The subscriber is incorrectly provisioned and needs to have a GRN assigned.
IS41	RN=RTDB SP Entity ID	RN=DFLTRN
ALL	RN=GRN If GRN is not provisioned, DFLTRN is not used. MSISDN digits are sent. The subscriber is incorrectly provisioned and needs to have a GRN assigned.

Table 2-12 RN Digits with Service Portability Off

Subscriber Type returned from RTDB	GSMOPTS:DFLTRN = NONE	GSMOPTS:DFLTRN = DIGITS
RN/PT = 0	IGM feature ON or OFF: RN=RTDB RN Entity ID	IGM feature ON: RN=DFLTRN IGM feature OFF: RN=RTDB RN Entity ID
SP (own GSM)	IGM feature ON or OFF: RN=RTDB SP Entity ID	IGM feature ON or OFF: RN=DFLTRN
RN/PT ≠ 0 (Other Licensed Operator)	IGM feature ON or OFF: RN = RTDB RN Entity ID
No Entity Found	IGM feature ON or OFF: RN=EMPTY (Only B-Party Number)

Figure 2-10 Message Processing - Service Portability Support for SRI Query for Prepaid

2.10 GSM MAP SRI Redirect to Serving HLR

The GSM MAP SRI Redirect to Serving HLR feature provides the capability to resolve network problems introduced by maintaining equipment from multiple manufacturers with vendor-specific proprietary implementations. Normally. the G-Port feature relays an SRI message to an operator's own HLR for a ported-in number. This feature allows the operator to route those messages based on the type of equipment at the source MSC and destination HLR. Vendor Type, Vendor Number, and Vendor Prefix are used to provision this information.

If the originating Mobile Switching Center (MSC) of the Send Route Information (SRI) message and the destination Home Location Register (HLR) are the same vendor type, the message is relayed to the HLR associated in the RTDB to the service provider. If the originating MSC of the SRI message and the destination HLR are not the same vendor type, G-Port checks whether the vendor type is deployed in more than one network; each network has its own vendor/network prefixes.MSC SRI message Home Location Register (HLR)

If the vendor types of the originating MSC and destination HLR are different and the destination HLR vendor type is deployed in more than one network, the vendor/network prefix that points to the network where the hosting HLR resides is appended. If the vendor types of the originating MSC and destination HLR are different and the vendor type of destination HLR is deployed in only one network, the vendor/network prefix that is assigned to the network is appended.

The GSM MAP SRI Redirect to Serving HLR feature supports provisioning of a Vendor Prefix List of up to 128 entries, a Vendor Type List of up to 32 entries, and a Vendor ID List of up to 500 entries. Each Vendor Prefix List entry (up to 128 entries) contains the Vendor Number and associated Vendor Prefix (maximum of six digits). Each Vendor ID List entry contains the Vendor ID, Vendor Type, and Vendor (network) Number. All Vendor IDs must be the same length which is provisionable for 1 to 15 digits using the ent-vendid command. A Vendor ID cannot be entered into the database until the associated Vendor Prefix is defined.

Table 2-13 Vendor Prefix List example

Vendor Number	Vendor Prefix
1	1004
2	1003
3	1004

Table 2-14 Vendor ID List example

Vendor/Network Type	Vendor Number	Vendor ID
1	1	886932
1	1	886935
1	3	886938
2	2	886936

Intra Network Number Portability

With the introduction of the Intra Network Number Portability feature and the new GSMOPTS:SRIRDCTENT option, the Generic Routing Number (GRN) can be used to identify intra-circle and inter-circle calls. Before the Intra Network Number Portability feature, the GSM MAP SRI Redirect to Serving HLR feature identified the serving HLR based on only the Circle Type and Circle Number for operators. With the Intra Network Number Portability feature, each Circle has a unique GRN, a unique Vendor Type, and a unique Vendor Number. The new GSMOPTS:SRIRDCTENT option has two possible values: GRN and SP. Intra Network Number Portability customers use the GSMOPTS:SRIRDCTENT option set to GRN. The GSM MAP SRI Redirect to Serving HLR feature must be enabled before the GSMOPTS:SRIRDCTENT option can be configured.

Table 2-15 Example: EPAP Provisioning for Intra Network Number Portability

DNs	GRN
All DNs of Circle1	GRN1
All DNs of Circle2	GRN2
All DNs of Circle3	GRN3

Table 2-16 Example: EAGLE Vendor ID Table for Intra Network Number Portability

Vendor ID	Vendor Type	Vendor Number
MSCGT1	T1	V1
MSCGT2	T2	V2
MSCGT3	T3	V3
GRN1	T1	V1
GRN2	T2	V2
GRN3	T3	V3

Table 2-17 Example: EAGLE Vendor PrefixTable for Intra Network Number Portability

Vendor Number	Vendor Prefix
V1	GRN1
V2	GRN2
V3	GRN3

If after RTDB lookup, SP and GRN are found corresponding to the DN, EAGLE uses GRN for lookup in the Vendor ID table. If the GRN is found in the Vendor ID table, EAGLE checks whether the CgPA has a valid length GTA. Then EAGLE uses the CgPA GTA to lookup in the Vendor ID table. If the CgPA GTA is found in the Vendor ID table, EAGLE compares the two vendor types associated with the CgPA GTA and the GRN.

Scenario 1 : If both Vendor Types are same, the CdPA and the originating MSC belong to the same circle. EAGLE relays the SRI message to the HLR as determined by the SP.

Scenario 2 : If the two vendor types are different, that means the CdPA and the originating MSC belongs to different circles. EAGLE generates an SRI_ACK using the Vendor Prefix (GRN of destination circle) as the RN. The SRI_ACK is then sent to the originating GMSC.

If after RTDB lookup, the RN is found corresponding to the DN then normal G-Port processing is continued.

Calling party / Operator	Called Party /Operator	Called Party Ported Status	Result
Circle 1 / Operator A	Circle 1 / Operator A	Not Ported	Relay
Circle 1 / Operator A	Circle 2 / Operator A	Ported to Circle 1 / Operator A	Relay
Circle 1 / Operator A	Circle 2 / Operator A	Ported to Circle 3 / Operator A	SRI_ACK with GRN3A
Circle 1 / Operator A	Circle 1 / Operator B	Not Ported	SRI_ACK with RN 1B
Circle 1 / Operator A	Circle 1 / Operator B	Ported to Circle 1 / Operator A	Relay
Circle 1 / Operator A	Circle 2 / Operator B	Ported to Circle 3 / Operator B	SRI_ACK with RN 3B
Circle 1 / Operator A	Circle 2 / Operator B	Ported to Circle 3 / Operator C	SRI_ACK with RN 3C
Circle 1 / Operator A	Circle 2 / Operator B	Ported to Circle 1 / Operator B	SRI_ACK with RN 1B
Circle 1 / Operator A	Circle 2 / Operator B	Ported to Circle 2 / Operator C	SRI_ACK with RN 2C

GSM MAP SRI Redirect to Serving HLR Call Flows

Refer to Figure 2-11 for a graphical representation of the GSM MAP SRI Redirect to Serving HLR call flow. This call flows assumes that GSMOPTS:SRIRDCTENT=SP.

Figure 2-11 GSM MAP SRI Redirect to Serving HLR Call Flows

For a ported-in number, Gateway Mobile Switching Center (GSMC) Vendor 2 receives an Initial Address Message (IAM) with CdPN.

1. The receiving GMSC interrogates the Home Location Register (HLR) for the current location of the subscriber by issuing a Send Route Information (SRI) message.

2. When an SRI message is received that meets the G-Port service selector criteria, HomeRN deletion and number conditioning are performed on the DN. The DN database is searched. If the DN is found in the database with a service provider (HLR entity address) associated with the called party MSISDN, the Vendor ID list is searched for the service provider. If the service provider is found in the Vendor ID list, the CgPA is checked for a valid length GTA. The Vendor ID list is searched for the CgPA GTA. If the CgPA GTA is found in the Vendor ID list, the two vendor numbers associated with the CgPA GTA and the service provider are compared. If the GMSC and the HLR are the same vendor type, go to step #7. If the GMSC and the HLR are different vendor types, go to step #3.

3. If the destination network belongs to a vendor type that is deployed in more than one network, an SRI_ACK is generated using the Vendor Prefix of the destination network as the RN. The MSRN is filled using various options provisioned in the GSMOPTS table for the G-Port SRI_ACK. The SRI_ACK is sent to the originating GMSC.

4. Based on the Vendor Prefix, the originating GMSC routes the call to the GMSC of the network associated with the vendor by the IAM.

5. The subscription network GMSC formulates and sends an SRI message to the EAGLE to interrogate the current location of the subscriber.

6. G-Port performs a database lookup based on the MSISDN in the SRI and determines that the number belongs to its network. The service provider (HLR entity address) associated with the MSISDN and the CgPA GTA (GMSC/MSC) are confirmed to be the same vendor type. .

7. The SRI is relayed to the HLR asociated to the service provider.

8. The HLR returns an SRI_ACK to the GMSC through the EAGLE.

2.11 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.

2.12 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.