In this section:
The following section is only applicable to the DSC Platform.
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.
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
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 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
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.
The following sections describe the configurations needed to set up the example depicted in the previous figure for the
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.
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.
Linksets to all relevant adjacent point codes must be defined in each NA.
The 5.6.7 STP is part of the SS7 network diagram in the example setup (Figure System Setup Example).
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.
Similar routesets were also configured on the NA 8.
Finally, SCCP equivalent NAs are also required (see the following figure).
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.
Right-click Configuring the INAP Gateway and open it in a separate window as you will need to refer to it several times.
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).
To configure the following screen, refer to Configuring the INAP Gateway: To configure INAPGW system-wide attributes.
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.
To create an External NP Partners, refer to Configuring the INAP Gateway: To create an External NP Partner.
The following figure shows an example of the initial configuration for an external NP partner.
The attribute descriptions for the Create External NP Partner screen are as follows:
After a new object is created, it appears under the External NP Partner Selection screen (see the following figure).
If you select the new object, you can verify that the data was entered correctly (see the following figure).
Notice three additional attributes appear on the configuration screen. These default attributes are
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.
The corresponding MTP3 NA and SCCP NA must be created prior to this step in the MTP3 and SCCP application, respectively.
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.
After the NA is activated, the SCCP NA Connection is updated with the connections for each Routing CPU (see the following figure).
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).
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.
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
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.
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.
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.
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.
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.
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.
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.
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:
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:
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.
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.
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.
The PC List (see the following figure) is used to route the message to the external NP partner configured in INAPGW.
The INAP responses are received via the PC-SSN registration.
If the external NP partner responds with a GT routed message, additional provisioning is required at GTT.
The following figure shows an overview of the applications processing logic for an INAP Connect response.
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
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.
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.
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:
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.
For a more flexible routing criteria, the
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.
If the GTT NA is not present, refer to Configuring the GTT NA Manager: To create a GTT NA.
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.
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.
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).
The Command List, in this example, deletes 6 digits from the left (see the following figure).
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).
The INAP responses are received via the PC-SSN registration.
If the external NP partner responds with a GT routed message, additional provisioning will be required at GTT.
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:
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).
The INAPGW application has reserved Application IDs. For more information, refer to Reserved Application IDs for SS7 Applications.
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:
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.
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.
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).
The Command List (see the following figure) deletes the first digit from the left.
The PC List (see the following figure) routes the message to an invalid destination.
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.
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.