INAPGW Configuration Examples

Overview

This section is designed to help plan and setup the INAP Gateway (INAPGW) configuration, including all related SS7 applications to facilitate the deployment of the INAPGW feature. This section describes the specific scenarios that will be addressed by the INAPGW feature.

System Requirements

The INAPGW application must be deployed in conjunction with specific STP applications in order to handle the proper routing functions of the messages.  This configuration is done through proper licensing of the applications on the DSC Platform at the time of the system purchase.

DSC Platform licensing must include

• SCCP:  Handles message segmentation and reassembly as required.
• GTT: Handles the global title (GT) routing of the messages. The DSC Platform can be licensed up to 500K GT Search records; the customer must license the number of records which will enable their deployment requirements. The DSC Platform can also optionally be licensed for cross-network and advanced GTT for an enhanced routing and GT translation feature set.
• Gateway Screening and MSU Tracing (GWST): Handles the screening of messages with specific parameters to be intercepted for redirection.  Required by the Gateway Redirection (GWR) license.
• Gateway Redirection (GWR): Handles message interception and redirection to the INAPGW application based on the screening criteria.
• INAP Gateway: The INAPGW application is enabled via licensing on the system.

INAPGW Provisioning Requirements

The following provisioning requirements must be provided by the customer prior to the configuration of the INAPGW application.  These parameters are vital to the proper functioning of the feature.

• The INAPGW application must be provisioned with an E.164 number to allow GT-based routing.  This attribute is used to uniquely identify the STP feature in a mated pair deployment.
• The INAPGW application must be provisioned with one or up to 20 external Number Portability (NP) partners which are uniquely identified by an Application ID for traffic interception.
• Each external NP partner must be provisioned with an E.164 number to uniquely identify the external NP system via global title routing.  External NP partners must also configure the following parameters in the INAP Initial-DP for message acceptance: SCCP Called and Calling Party Address (PA) Subsystem Number (SSN), Dialogue Application Context, Service Key, Calling Party E.164 number, and the EDP support.
• The INAPGW application must be provisioned with a default hexadecimal digit prefix to insert in the intercepted MSU’s SCCP Called PA digits for INAP Continue responses on a per external NP partner basis.

Traffic Handling and Application Configuration

The INAPGW application works in conjunction with GWST, SCCP, and GTT to handle the different traffic scenarios.

This section will give a more detailed overview of how the DSC Platform applications process the traffic for a successful SRI-for-SM interception based on an INAP Connect and Continue response. The example configurations for each application will cover the initial interception of the SRI-for-SM, the INAP Connect response, and the INAP Continue response.

The example in this section will use the ITU variant in the configuration but the ANSI variant is also supported.

In the following figure, the traffic is intercepted on NA 9 while the associated external NP partner is on NA 8.

System Setup Example

The following sections describe the configurations needed to set up the example depicted in the previous figure for the DSC Platform.  These sections will consist of a brief description of the required data and associated screen captures.

1. MTP3 and SCCP Configuration

This section only contains a high-level overview of the configuration needed for MTP3 and SCCP. A sufficient knowledge of logistics to configure route traffic in SS7 is required for this section.

The MTP3 data does not contain any special configurations for INAPGW. The traffic will be routed correctly as long as the Network Appearance (NA) is configured with the correct SS7 variant and Local Point Code (LPC) along with the required linksets, links, and routesets.

In reference to the example system setup in Figure System Setup Example, there are two ITU NAs with point codes 2.3.4 (NA 8) and 3.4.5 (NA 9), which are shown in the following figure.

NA Selection Screen in MTP3

There is also a corresponding linkset to an Adjacent Point Code (APC) to the DSC. Each linkset contains the links that directly connect to the APC in question. The following figure displays the linkset built for NA 8 to an STP with LPC 5.6.7.

The 5.6.7 STP is part of the SS7 network diagram in the example setup (Figure System Setup Example).

Linkset Screen NA 8 in MTP3

Routesets are also needed to do typical STP routing of the traffic to the correct destination nodes. The following figure displays the routesets configured for this example setup on NA 9.

Routesets Screen NA 9 in MTP3

Finally, SCCP equivalent NAs are also required (see the following figure).

NA Selection Screen in SCCP

 

2. INAPGW Configuration

The INAPGW has several objects that must be configured in order to set up the feature. For instructions to configure the INAPGW, refer to Configuring the INAP Gateway.

INAPGW General Configuration

The E164 INAPGW attribute contains the number that identifies the INAPGW service in the network. You assign this unique number. The generated INAP Initial-DP request includes these digits in the SCCP Calling Party Address parameter of the message. The E.164 number is a configuration requirement in order to use the Activate Traffic feature to enable the application to start processing traffic.

The Transaction Timeout attribute is the number in seconds for the pending transaction timeout of the INAP queries. The default for this timeout value is two seconds but can be configured up to ten seconds (see the following figure).

INAPGW General Configuration Screen

 

INAPGW External NP Partners

The External NP Partner object represents the Number Portability (NP) database information for a given partner. Each partner must be uniquely identified by its E.164 number and assigned a unique Application ID. The Application ID value is used by GWST to redirect traffic to the INAPGW.

The following figure shows an example of the initial configuration for an external NP partner.

External NP Partner Create Screen Example

The attribute descriptions for the Create External NP Partner screen are as follows:

• Application ID: The External NP Partner associated Application ID must be an alphanumeric (including underscore and dash) name with a maximum of 16 characters including the NULL terminating character.
• NA: The Network Appearance the External NP Partner is connected to via SS7 links.
• External NP E164: The E.164 number representing the External NP Partner. This must be provided by the customer ahead of configuration and reachable via GTT provisioning.
• InitialDP SSN: The SSN present in the INAP Initial-DP request SCCP Called & Calling Party Address parameters. The LPC-SSN combination is registered on the associated NA to receive the INAP responses.
• InitialDP E164 Calling: The generated INAP Initial-DP query will include this E.164 number with the International nature of address in the INAP Calling Party Number parameter. This number must be a hex/digit string that does not match the external NP partner E.164 number.
• INAP Continue Prefix: The prefix is added to the SCCP Called Party Address digits for GT routing of the intercepted message based on an INAP Continue response. Maximum size is six hex/digits.

After a new object is created, it appears under the External NP Partner Selection screen (see the following figure).

External NP Partner Selection Screen

If you select the new object, you can verify that the data was entered correctly (see the following figure).

External NP Partner Screen

Notice three additional attributes appear on the configuration screen. These default attributes are

• InitialDP Application Context: The INAP Initial-DP Dialogue Portion Application Context is displayed as an Object Identifier (OID) formatted string. The default is 0.3.144.12.1.1.0 but can be changed if needed. For more information on OID formats and their encoding, please refer to enforced ITU-T Recommendation X.209 specification. For example, the default OID value defined above is encoded in hexadecimal (OID tag 0x06 of length 7) as 06 07 03 81 10 0C 01 01 00.
• InitialDP Service Key: The Service Key parameter is mandatory for the INAP Initial-DP request. The default value is 15 but can be changed if needed.
• Initial EDP Support: Enable or disable the Event Type BCSM parameter from the INAP Initial-DP request. If the attribute is enabled, the GSM parameter is added with length indication 1 and a value of 0x03. The default value is DISABLED but can be changed if needed.

INAPGW SCCP NAs

The SCCP NA tab in the INAPGW screen is used to configure the SCCP NAs that send SS7 messages via SCCP to and from the INAPGW application.

To create an SCCP NA, refer to Configuring the INAP Gateway: To create an SCCP NA.

Once the addition is complete, the new NA appears under the SCCP NA Selection screen (see the following figure). However, the status for the newly added NA is INACTIVE. To activate the NA, refer to Configuring the INAP Gateway: To activate or deactivate traffic on an SCCP NA.

SCCP NA Selection Screen

After the NA is activated, the SCCP NA Connection is updated with the connections for each Routing CPU (see the following figure).

SCCP NA Screen - Activated

SCCP Registrations

The SCCP Registrations object is automatically populated when an SCCP NA is activated in INAPGW. The SCCP Registrations screen shows the new PC-SSN and Application ID registrations for each NA where applicable. Some NA have both PC-SSN and Application ID registrations and some do not. These objects are non-creatable and non-deletable and are present for informational purposes only. The objects are automatically created based on the associated Local Point Code (LPC) and the INAP subsystem number (SSN) from the External NP Partner objects on their associated SCCP NA (see the following figure).

SCCP Registration Selection Screen

3. GWST and GTT Configuration to Intercept a SRI-for-SM Request

The INAPGW is used in conjunction with GWST to intercept the SRI-for-SM requests.

The following figure shows an overview of the application processing logic for a successful SRI-for-SM Interception. The example in this figure shows the traffic being intercepted on NA 9 while the associated external NP partner is configured on NA 8.

STP Traffic Handling: Interception of SRI-for-SM

GWST Configuration to Redirect MSU to INAPGW

In the preceding example, the GWST is configured to start the search on the Incoming Linkset of NA 9 and then redirect to Application ID NP_CC1.

The configuration example uses the GWST tables in this order:

Incoming Linksets -> Allowed SIOs -> Allowed SCCP CLD Digits PAs-> Allowed TCAP Op Codes -> Redirect to App IDs

Incoming Linksets Table

The Incoming Linksets Table starts the gateway screening on NA 9 targeting the linkset with the APC of 5.6.7 (see the following figure). In the attributes, the Next Table is set to ALLOWED SIOS and the Next EPR to 88. The EPR of 88 designates the ALLOWED SIOS records that this linkset will use when it goes to the Allowed SIOs table.

Incoming Linkset Screen for NA 9 and APC 5.6.7

Allowed SIOs Table

In the Allowed SIOs table, there are two records that narrow down the screening criteria to find the MSU you want to intercept.

The first record (see the following figure) contains the SI Range of 3 (SCCP) and the Next Table of ALLOWED SCCP CLD DIGITS. This means any messaged coming in from that linkset with an SI of 3 moves on to that table.

Allowed SIO Screen for SI Range = 3

 

The second record (see the following figure) contains the attribute with SI Range of 0&&2 and Next EPR of STOP. This means that any MSU that arrives with an SI of 0, or 1, or 2 does not continue with the screening and is routed normally via MTP3.

Allowed SIO Screen for SI Range = [0..2]

Allowed SCCP CLD Digits PAs Table

In the Allowed SCCP CLD Digits PAs table, there are records created to look at the SCCP Called Party Address (PA) digit prefix of the incoming MSU.

In the example, the SCCP Called Party Address contains the following digits, +16132874344.

The following figure shows a record that contains a prefix digit of 1. This record goes to the next table of ALLOWED TCAP OP CODES where the MSU is screened even further.

Allowed SCCP CLD Digits PA Screen for Digits Prefix = 1

The other record (see the following figure) leaves the Digits Prefix attribute blank (default record) and the Next EPR is set to STOP. This means that if the SCCP Called PA digits do not match any of the other records on that EPR, the MSU is routed as expected through MTP3.

Allowed SCCP CLD Digits PA Screen for Default Record

Allowed TCAP Op Codes Table

The Allowed TCAP Op Codes table contains two records for this example.

The first record (see the following figure) verifies that the TCAP message type matches ITU BEGIN, the TCAP component type matches ITU INVOKE, and the MSU contains an operation code of 45 (GSM SRI-for-SM). MSUs matching that criteria complete the gateway screening and continue to the REDIRECT TO APPIDS table for redirection.

Allowed TCAP Op Code Screen for SRI-for-SM Request

The second record (see the following figure) allows all other MSUs with any other TCAP message type, Component Type and Operation Code to be routed normally through MTP3.

Allowed TCAP Op Code Screen for Default Record

Redirect to App IDs Table

The Redirect to App IDs table (see the following figure) contains the record that redirects the intercepted SRI-for-SM request to the INAPGW Application ID configured for the associated external NP partner.

In the example Figure STP Traffic Handling: Interception of SRI-for-SM, the external NP partner is configured with a unique App ID of NP_CC1. The selected App ID is included in the MSU as the Outgoing App ID.

In the example, the MSU being redirected to INAPGW is as follows:

• SRI-for-SM
• SCCP CLD +16132874344
• TCAP Begin
• OTID = X
• Outgoing App ID = NP_CC1

GWST Redirect to AppID Screen for Application ID = NP_CC1

GTT Configuration to Route the INAP Initial-DP Request to the External NP Partner

The GTT configuration allows the new INAP Initial-DP request sent by INAPGW to be routed to the correct external NP partner.

In the example Figure STP Traffic Handling: Interception of SRI-for-SM, the message being sent from the INAPGW to GTT via SCCP is as follows:

• INAP Initial-DP
• NA/DPC = 8/LPC
• SCCP CLD External NP E.164 (123456789012 as per Figure System Setup Example) 
• TCAP Begin
• OTID = Y
• INAP Called Party Number +16132874344

The GTT configuration needs to search on the SCCP Called PA and send the MSU to a Point Code (PC) List that contains the destination point code of the external NP partner or the next hop.

GTT DB Def Configuration

To separate the INAPGW GTT searches from other standard GTT searches done on the STP, a new DB Definition object needs to be created. For more information, refer to Configuring the GTT DB Def Manager.

The following figure shows the new DB Def object created for the INAPGW GT searches.

GTT DB Def Screen for INAPGW

GT Called Searches Table

The GT Called Search record (see the following figure) configures the SCCP Called Party Address Minimum and Maximum Digits attributes to 1234. If the MSU is a match, it uses the PC List named NORMAL-I to route the message to the destination point code.

GT Called Search Screen for Digits 1234

PC Lists Table

The PC List (see the following figure) is used to route the message to the external NP partner configured in INAPGW.

PC List Screen for NORMAL-I

4. GWST and GTT Configuration to Receive an INAP Connect Response

The INAP responses are received via the PC-SSN registration.

The following figure shows an overview of the applications processing logic for an INAP Connect response. 

STP Traffic Handling: INAP Connect Response

GWST Configuration to Route the Updated SRI-for-SM to GTT (optional)

Once the INAPGW updates the SRI-for-SM request, it sends the message on to GWST to trigger the routing through the App ID to GTT for an INAPGW specific DB Def.

The example uses the GWST tables in this order:

Incoming App IDs -> Redirect to App IDs

Incoming App IDs Table

The Incoming App IDs Table (see the following figure) starts the gateway screening on NA 9 targeting any messages with the Application ID of NP_CC1. GWST then forwards any MSUs with the App ID of NP_CC1 to the REDIRECT TO APPIDS table with the EPR of 98.

Incoming AppID Screen for Application ID = NP_CC1

Redirect to App IDs Table

If the preceding message (Figure Incoming App ID Screen for Application ID = NP_CC1) by App ID is linked to this table, it uses the record (see the following figure) to send it directly to GTT via the App ID that is registered on the GTT DB, which was created earlier.

Redirect to App ID Screen for Application ID = GTT_INAPGW

GTT Configuration to Route the SRI-for-SM to its Final Destination

The GTT configuration allows the intercepted SRI-for-SM request to be routed to its optimal destination.

In the example Figure STP Traffic Handling: INAP Connect Response, the message being sent from the INAPGW to GTT after GWST redirection is as follows:

• SRI-for-SM
• NA/DPC = 9/LPC
• SCCP CLD +10141216132874344
• TCAP Begin
• OTID = X
• Outgoing App ID GTT_INAPGW

The GTT configuration needs to search on the digits above and associate the search to a Point Code (PC) List that contains the optimal destination point code.

GTT NA App ID Registration

Since the new SRI-for-SM is redirected from GWST to GTT via App ID, the App ID needs to be added to the NA and associated to the GTT DB Def created earlier.

In this example, the NA is 9 and the App ID Registration defines GTT_INAPGW (see the following figure). The App ID Registration object also shows the correct DB Def name being used, INAPGW-ITU.

GTT NA Screen

GT Called Searches Table

The GT Called Search record (see the following figure) sets the SCCP Called PA Minimum and Maximum digits attributes to 101412. These leading digits were provided by the external NP partner when this partner responded with the INAP Connect.

Notice a modification record (REMFIRST6-I) is added to the GT Called Search record to remove the INAP Connect Prefix and return the Called Party Address to its original value. The PC List used to route the message is CONNECT-I.

GT Called Search Screen for Digits 104121

GT Modifications Table

The GT Modification record removes the leading digits that were added to the message for special routing. This is done via a Command List REMFIRST6-I (see the following figure).

GT Modification Screen for REMFIRST6-I

Command Lists Table

The Command List, in this example, deletes 6 digits from the left (see the following figure).

Command List Screen for REMFIRST6-I

PC Lists Table

This PC List routes the message to the final destination of the message which in this case is the end node with point code 4.55.7 (see the following figure).

PC List Screen for CONNECT-I

5. GWST and GTT Configuration to Receive an INAP Continue Response

The INAP responses are received via the PC-SSN registration.

The following figure shows an overview of the applications processing logic for an INAP Continue response. 

Intercepted MSUs that are sent to GTT for routing with the designed INAP Continue prefix in their SCCP Called PA digits can be configured to do the following:

1. return a Unit Data Service (UDTS) by setting the PC List in GTT to a reserved unavailable destination.
2. return a MAP Error by setting the PC List in GTT to a reserved unavailable destination and the Incoming App ID to GTT_INAPGW_ME. The MSU is returned to the INAPGW via GWST for processing and an error code of UnexpectedDataValue (36) is used. The MAP Error is returned to GTT for final routing back to the originator.

STP Traffic Handling: INAP Continue Response with MAP Error

GWST Configuration to Route the Updated SRI-for-SM to GTT (optional)

When INAPGW builds the SRI-for-SM message with the INAP Continue Prefix added to the called digits, it sends the message on to GWST to trigger the routing via App ID to GTT. The INAPGW uses the same App ID and GWST tables as the INAP Connect configuration.

In addition to route the MAP Error response to INAPGW, an additional screening is built to redirect the MSU with the Incoming App ID of GTT_INAPGW_ME to the RIBBON_INAPGW_ME App ID via the Redirect to App ID table (see the following figures).

Incoming App ID Screen for Application ID = GTT_INAPGW_ME

Redirect to App ID Screen for Application ID = RIBBON_INAPGW_ME

 

GTT Configuration to Route the Updated SRI-for-SM for MAP Error Handling

The GTT configuration allows the intercepted SRI-for-SM request to be returned with a MAP Error.

In the example Figure STP Traffic Handling: INAP Continue Response with MAP Error, the message being sent from the INAPGW to GTT after GWST redirection is as follows:

• SRI-for-SM
• NA/DPC = 9/LPC
• SCCP CLD +D16132874344
• TCAP Begin
• OTID = X
• Outgoing App ID = GTT_INAPGW

The MSU contains the new prefix in the SCCP Called PA configured for the INAP Continue Prefix in the external NP partner configuration. The GTT configuration screens on that prefix digit and sends it to a Point Code List that contains an unavailable destination.

GT Called Searches Table

The GT Called Search record (see the following figure) sets the SCCP Called PA Minimum and Maximum Digits attributes to D.

Notice the modification record (REMFIRST-I) is added to the GT Called Search record to remove the INAP Continue Prefix and return the Called PA to its original value. The PC List used to route the message is CONTINUE-I.

GT Called Search Screen

GT Modifications Table

The GT Modification record removes the leading digits that were added to the message for special routing. This configuration is done via a Command List REMFIRST-I (see the following figure).

GT Modification Screen for REMFIRST-I

Command Lists Table

The Command List (see the following figure) deletes the first digit from the left.

Command List Screen for REMFIRST-I

 

PC Lists Table

The PC List (see the following figure) routes the message to an invalid destination.

PC List Screen to Undefined 7.7.7

 

GTT Configuration to Route the Updated SRI-for-SM for UDTS Error Handling

The GTT configuration allows the intercepted SRI-for-SM request to return with a UDTS error message if the Return Message on Error bits are set in the Protocol Class parameter.

Similar to the previous section for MAP error return, the PC List is set to an undefined point code (for example 7.7.7) and the Incoming App ID attribute is an empty string as per Figure PC List Screen to Undefined 7.7.7.

6. INAPGW TCAP Error Message Handling

The INAPGW application stores intercepted MSUs and its incoming NA in a transient database pending the associated INAP response.

The INAPGW application is also provisioned with a configurable timeout value to await the associated INAP response. If the INAP timer expires or on receipt of any TCAP error (abort, reject) is received, the intercepted message is sent back unchanged to the GTT for normal routing.