Description

This feature provides for LNP query/response in a PCS wireless environment using the LRN method in order to support Service Provider Number Portability, thus extending EAGLE's LNP capability.

PLNP addresses the following capability in the network:

Call Completion to Ported Number (CCPN)

This network facility allows completion of a call to a ported directory number, when an MSC trigger is used (i.e. the MSC must be an LNP-capable switch). For PLNP, the MSC sends a query containing a DN, which is a 10-digit NANP called party number for a wire-line subscriber. The DN is used to perform an LNP database lookup in order to find the associated LRN.

Feature Functions

In order to support this new capability, PLNP utilizes the following, currently existing, LNP functions:

1. LNP Query processing: This function services LRN queries in real-time and generates associated LRN values. Multiple query types (AIN, IN, IS-41) are supported.

2. LNP Database: The database supports LNP Query and Message Relay processing, though Message Relay functionality is not supported in the industry.

3. SCCP Subsystem Management: SCCP supports local subsystems. This includes routing to a local subsystem, and performing network management when a local subsystem goes online or offline.

4. Database Audit: This periodically audits the LNP Database to ensure that it has not been altered by unapproved mechanisms, and to ensure that all cards have an identical copy of the LNP Database.

5. LNP related Administration: Support is in place to provision the existing LNP services. Support for provisioning the PLNP service has been added to the existing commands.

6. LNP-related Maintenance: Maintenance supports LNP. This includes reporting the status on the LNP subsystem, and generating alarms, measurements, and UIMs. Minor enhancements have been made to the REPT-STAT-LNP command.

   No new alarms are introduced for this feature. Although no new measurements or UIMs have been defined, measurements for PLNP will be maintained and reported separately from other LNP query services.

7. LSMS and the LSMS↔EAGLE interface: No impact on these functions.

PLNPQS Details

All the LNP query messages for call completion to ported number received by EAGLE are processed by PLNPQS. PLNPQS receives queries from the subsystem management task, and implements the processing to parse the query, perform the lookup, and generate the response.

LNP Query is performed as follows:

1. The message arrives at EAGLE.

2. If global title is required, and the translation type is PLNP, the data is routed to the local LNP query subsystem and Site ID True Point Code (SID and SS_APPL tables). Only one LNP subsystem exists for all LNP query processing. If SID/SS_APPL data has not been administered, a UIM is generated and the message is discarded.

3. If global title is not required, the message is routed to the appropriate destination, local subsystem if the EAGLE DPC and SSN are the destination, MTP routed for others.

PLNPQS Query Verification

This section shows the process used by EAGLE, as part of PLNPQS, to verify a PLNP query.

A summary of the verification follows.

PLNP will verify the following values in the MTP and SCCP part:

1. MSU is ANSI national, and point codes are national

2. MSU is SCCP UDT message

3. MSU is SCCP Class 0

4. GTI is 0010 when rt-on-gt, or 0000 when rt-on-ssn

5. TT is the provisioned PLNP TT value

6. PC of originating SSP is in route table, extract PC and SSN for use in the response

7. Length of user part sufficient to hold minimum TCAP part

PLNP will verify the following values in the TCAP part:

1. TCAP package is Query with Permission

2. TCAP package length fits within SCCP user part

3. TCAP transaction ID present, and length = 4, extract value for use in the response

4. Component sequence ID present, and length valid

5. Invoke Last component present, and length valid, extract Invoke ID for use in the response

6. PCS ProvideInstructions:Start operation code present

7. Digit ID parameter, Called Party Number present

8. Calling Party Number, LATA, and ORG station are present

PLNPQS Query Decoding

This section shows the process used by EAGLE to decode a PLNP query. The process is identical to the existing EAGLE implementation to decode IN queries, except that:

• the numbering plan for this query is E.164, rather than E.163

• the dialed number must be exactly 10 digits, rather than at least 10

PLNP will verify the following values in the TCAP part:

1. TCAP length valid

2. Parameter Set present, and length valid

3. Service Key present, and length valid

4. Digit ID parameter, Called Party Number is present, length is valid, and the following applies:

   • Type is National

   • Encoding is BCD

   • Numbering Plan is ISDN (E.164)

   • 10 digits present

   • Each digit is correctly encoded (BCD value is 0 to 9, inclusive)

PLNPQS Query Response Generation

PLNPQS response messages can be of the following types: normal messages and error messages.

Normal Responses

This section shows the fields filled in by EAGLE for a "normal" response to a PLNP query. The normal response is sent when the query passes verification and decode, and an LNP database lookup is performed.

Normal responses are identical to the existing EAGLE LNP implementation for IN query/response, except that the numbering plan used for the query and response will be E.164 (ISDN), rather than E.163 (Telephony).

The Routing Number in the normal response is filled in as follows:

• if the database lookup succeeds and returns an LRN, the Routing Number in the response is set to the LRN value (i.e. the DN refers to a ported number).

• if the database lookup fails (i.e. the number is not ported), the DN value from the query is used as the Routing Number in the response.

The normal PLNP response is required to include the Digits(Carrier), and Billing Indicators parameters. These parameters are not essential for number portability, but are mandatory parameters for the response. Each will be set to a benign filler value, as shown in the template.

Error Responses

MTP and SCCP level error responses are unchanged from the existing EAGLE implementation.

The general rule for error responses are as follows:

• Protocol errors in the component portion (incorrect package or component) are reported with a Reject component in a Response package

• Command errors (where the query completed with an error, though the command was received correctly) are reported with a Return Error component in a Response package

Error handling for PLNP will come into play once a message is routed to the PLNPQS for handling as a PLNP request.

Upgrade Considerations

Adding additional measurements to support the feature will result in the SCCP maintenance block being modified. During upgrade, OAM must support the old and new version at the same time. During an upgrade back out, the SCCP card must support polling for the old version.

Since this feature does not change any DMS tables, no table conversion will be required.

All SCCP cards must be upgraded to the release that contains PLNP prior to provisioning the PLNP service.

Limitations

1. When the PLNP feature is enabled, and the PLNP service is provisioned, it is not possible to route PLNP queries arriving as Route on GT to an external node. All Route-on-GT PLNP queries will be processed locally under these conditions. This means that customers will not be able to split processing of PLNP queries across multiple network elements.

   The product is implemented in this manner in order to retain backward compatibility with the current LSMS product. Rather than utilizing the LSMS to provision PLNP service on a per NPA-NXX basis, the PCS query service is enabled/disabled for all messages.

2. Due to limitation 1, when the LNP database is unavailable, EAGLE will return an error response without performing LNP. Network management for these LNP queries will be used to divert future traffic. A summary of the network management response is shown in Table 5-1.

   Table 5-1 Response When PLNP Is Unavailable

   Query MSU Routing Indicator	DPC	Message Handling	Network Management
   Rt-on-gt	True point code	generate UDTS	Send UPU
   	Capability point code	generate UDTS	Send TFP concerning EAGLE’s CPC
   Rt-on-ssn	True point code	generate UDTS	Send SSP to OPC concerning DPC
   	Capability point code	generate UDTS	None

3. PLNP only supports ANSI messages.

4. There is no Automatic Code Gapping (ACG) for PLNP. Excessive PCS query messages can cause ACG to be initiated for AIN and IN queries, potentially starving out those services if the excessive PCS query messages continue to be sent to EAGLE.

5. Message Relay is not supported for messages which use the PLNP Translation Type.

Description

The EPAP PDBA Proxy feature provides a more reliable connection to the EPAP PDBA in the event of a failure of the active PDBA. Connection redundancy is accomplished by allowing the customer’s provisioning system to still use a single IP address, even though the connection may logically be to the previously standby PDB.

During normal provisioning operations, one PDBA is active and the other PDBA is in standby. However, from the customer's provisioning system perspective, the active and standby PDBAs are accessible through a single IP address. If the active PDBA fails, the local EPAP B box will forward provisioning updates to the mated PDB.

When the previously active PDBA recovers, it is aware that the standby PDBA has become active and now both active PDBAs need to be reconciled.

The advantages this feature provides are:

1. The customer's G-Flex network can absorb a single EPAP failure and automatically transfer provisioning to the standby PDBA using the same IP address.

2. A means of reconciling both active PDBAs when the failed PDBA becomes available again.

Limitations

1. The EPAP PDBA Proxy feature cannot be installed on a non-provisionable site.

2. This feature does not require the ADR feature.

3. This feature only provides Virtual IP functionality when the EPAP-A fails.

4. Failure of the network connection to both EPAP A and B, or similar failures that take down both devices require the customer’s provisioning system to manually connect to the standby PDB’s IP address.

Primary Aspects

The following items can be considered primary aspects of the Performance Enhancements feature:

• Maximum application capacity per DCM is increased to 3000 MSUs per second, with limitations.

• DCM communications processor MSU throughput capacity is increased to 5000 per second.

• The software-imposed limit to maximum TVG request rate is increased to 5000, which requires a limit on active cards present in the system.

• Application performance is enhanced through the use of Nagle’s algorithm on all sockets. For more information on Nagle’s algorithm, see Nagle’s Algorithm.

• Application performance is enhanced through optimizations in the use of shared memory.

• The msucount pass-through maintenance command, used with the pass command, is enhanced to provide values for average MSUs per second transmitted and received over a period of time.

Secondary Aspects

The following items can be considered secondary aspects of the Performance Enhancements feature:

• The TCP/IP stack is modified such that the timer used for Nagle’s algorithm has a much lower time-out, such as 25 milli-seconds rather than 200 milli-seconds.

• Socket message flow control is modified for the higher capacity.

• TCP re-transmissions at the higher capacity is addressed by increasing socket buffer size from 8 kilo-bytes to 16kilo-bytes.

• The card-level congestion control algorithm is modified for the higher capacity.

• The change-over/change-back control algorithm is modified for the higher capacity.

Limitations Summary

Achievement of the maximum application capacity of traffic requires the following:

• No more than 150 active cards may be present in the system.

• Average MSU size of application traffic must be no greater than 120 octets.

• STPLAN copy on outbound messages is not supported at the capacity rate of traffic, but is still supported at rates up to 2000 MSUs per second.

• Nagle’s algorithm must be enabled for all traffic-carrying sockets.

Description

The Per-Linkset Random SLS (Signaling Link Selection) feature is an enhancement of the existing Random SLS Generation feature, to allow the user to apply Random SLS generation on selected linksets instead of system-wide to all linksets. The Per-Linkset Random SLS feature provides an STP option that can help to resolve load balancing problems on specific linksets without affecting the entire routing scheme of the EAGLE 5 ISS.

The EAGLE 5 ISS uses the Random SLS option to decide if it has to generate a new SLS value. This randomly generated SLS value is used to select an outgoing linkset and a link to achieve load balancing. Linkset provisioning is enhanced to allow configuring of specific linksets for Random SLS generation.

To use the feature in an upgraded system that has the Random SLS option set to CLASS0 or ALL, the operator must provision the individual linksets and per-linkset options appropriately before changing the STP option to function per linkset.

The Per-Linkset Random SLS feature can operate on both ITU SCCP Class 0 and ITU SCCP Class 1 traffic. The Per-Linkset Random SLS feature allows each linkset to inherit all the options related to SCCP Class 0 and Class 1 traffic that are currently available for the Random SLS Generation feature.

Hardware Requirements

None

Limitations

Different Per-Linkset Random SLS configurations on two linksets that are part of a combined linkset for the routes defined for a destination node might result in undesired SLS distribution. The EAGLE 5 ISS does not prompt or reject the linkset provisioning command if provisioning will result in an undesired SLS distribution.

Description

This feature provides persistent states for supported EAGLE card, terminal, signal link and TCP/IP link devices. This capability makes it unnecessary to manually log device states prior to an init-sys, and retains the OOS-MT-DSBLD device state during an OAM switchover. Supported devices are cards, terminals, SS7 signaling links and TCP/IP data links.

During the init-sys process, the OAM will restore supported devices to their maintenance states, resulting in an initialized and configured EAGLE. Non-supported devices continue to be processed using the current method.

This feature presents a very efficient mechanism to restore an EAGLE to its pre-init-sys state. This init-sys aspect of the feature is controlled by a system wide "restore device" option administered by the craftsperson with the chg-stpopt command. Turning off this option causes the current init-sys processing to occur.

With this feature, faster standby-to-active recovery during a switchover operation are possible, since device states are maintained on the standby MASP, and do not require craftsperson intervention following initialization. Disabled or inhibited devices retain their state, provided the PDS data is valid. Otherwise, current switchover processing occurs, and devices may be driven to their default state.

Hardware Requirements

No new hardware is needed to support this feature.

Limitations

Persistent state data will not be maintained on the standby MASP, in the case of different version numbers for the PDS tables in the active and standby MASPs. The PDS table version changes only if there are new devices supported by the PDS, or more information is added to the table for the supported devices.

Description

The iplimi application provides the same functions for International Telecommunications Union (ITU) point codes as the iplim application provides for American National Standards Institute (ANSI) point codes, with the exception of any functions that are supported only by ANSI protocols. (Full Restart, Partial Restart, Adjacent Restart, False Link Congestion, and Circular Routing Detection are ANSI-only features.)

Each iplimi link provides one point-to-point connection either to an international ITU network node (ITU-I) or to a national ITU network node (ITU-N) for the purpose of carrying SS7 traffic over a TCP/IP network. These links:

• Can be added to a multiple-link linkset in which the other links can be either iplimi links or links of another type, such as css7itu.

• Fully support SS7 changeover and changeback procedures, including retrieval.

• Have the standard SS7 restriction of 16 links per linkset.

Mixed Networks Using the ANSI/ITU Gateway Feature

If you have also installed the ANSI/ITU Gateway feature (previously available for SS7 networks only), the addition of the iplimi application enables the IP⁷ Secure Gateway to use the ANSI/ITU Gateway feature for IP networks as well. Using these features enables IP⁷ Secure Gateway to act as an interface between nodes that support ANSI, ITU-I, and ITU-N protocols. Figure 5-1 shows an example of a complex network that includes all these types of nodes. Table 5-2 provides more detail about the nodes, network types, and point codes used in this example.

The following SS7 protocol constraints determine how the network must be configured:

• A linkset is a group of links that terminate into the same adjacent point code. All links in the linkset can transport compatible MSU formats. The network type of the linkset is the same as the network type of the adjacent point code assigned to the linkset.

• When nodes in different networks need to communicate, each node must have either a true point code or an alias point code for each of the network types. For example, if Node 1 (in an ANSI network) needs to communicate to Node 7 (in an ITU-N network), Node 1 must have an ANSI true point code and an ITU-N alias point code, while Node 7 must have an ITU-N true point code and an ANSI alias point code.

• STPs are usually deployed as mated pairs. The links connecting the STP to its mate are C links. Each STP must have a C linkset for each network type that the STP connects to. Therefore, in Figure 5-1, Nodes 5 and 6 are connected with three linksets, one each for ANSI traffic, ITU-I traffic, and ITU-N traffic.

• To perform routing, the IP⁷ Secure Gateway must convert the routing labels in MSUs. To perform this conversion, every destination point code (DPC), originating point code (OPC), and concerned point code must be defined in the routing table. Even if the IP⁷ Secure Gateway does not route MSUs to these nodes, they must be provisioned in the routing table to provision the alias point codes required in the conversion process.

  Figure 5-1 Complex Network with ANSI, ITU-I, and ITU-N Nodes

  

  Table 5-2 Nodes and Point Codes in Complex Network Example

  Node	Node Type	Network Types Supported	True Point Codes1	Alias Point Codes2
  1	SSP	ANSI	A1	N1, I1
  2	SSP	ANSI	A2	I2
  3	SSP	ANSI	A3	N3, I3
  4	SSP	ANSI	A4	N4
  5	STP (with IP7)	ANSI, ITU-N, ITU-I	A5, N5, I5
  6	STP (with IP7)	ANSI, ITU-N, ITU-I	A6, N6, I6
  7	STP (with IP7)	ITU-N, ITU-I	N7, I7	A7
  8	STP (with IP7)	ITU-N, ITU-I	N8, I8	A8
  9	STP (with IP7)	ITU-N, ITU-I	N9, I9	A9
  10	STP (with IP7)	ITU-N, ITU-I	N10, I10	A10
  11	SSP	ITU-N	N11	I11, A11
  12	SSP	ITU-I	I12	N12, A12
  13	SSP	ITU-I	I13	N13, A13
  14	SSP	ITU-N	N14	I14, A14
  15	SSP	ITU-I	I15	N15, A15
  16	SSP	ITU-I	I16	N16, A16
  Notes: A true point code(TPC) defines a destination in the IP7 Secure Gateway’s destination point code table.ATPC is a unique identifier of anode in a network. Each Signal Transfer Point(STP) must have a TPC for each network type that the STP connects to. Each Service Switching Point(SSP) connects to only one type of network, so it has only one TPC. An alias point code is used to allow nodes in other networks to send traffic to and from an STP or SSP when the STP or SSP does not have a TPC for the same network type.

The many configured links and point codes in the complex network shown in Figure 5-1 allows most nodes to communicate with other nodes. However, note that Node 2 cannot communicate with Node 13 or Node 16 because Nodes 13 and 16 do not have ANSI alias point codes.

Routing and Conversion Within a Single Network Type

The following steps demonstrate how an IP⁷ Secure Gateway routes and converts MSUs that one ITU-N node sends to another ITU-N node. For example, assume that Node 11 in Figure 5-1 sends an MSU to Node 14. The MSU is routed from Node 11 to Node 7 to Node 5 to Node 9 to Node 14. The following steps describe the actions performed at Node 5 (an IP⁷ Secure Gateway):

1. An ITU-N formatted MSU (which has a network identifier (NI)=10b and a 14-bit destination point code/originating point code) is received on an iplimi card (for this example at location 1103).

2. MSU discrimination is performed with the following substeps:

   1. Compare the received network identifier (NI) to the list of valid NIs. (Each configured linkset for a receiving link has a defined list of valid NIs.) If the comparison fails, the MSU is discarded and an STP measurement is logged. In this example, the received NI (10b) is valid for an iplimi card.

   2. Extract the NI and destination point code (DPC) from the received MSU.

   3. Determine whether the destination of the received MSU is this STP. If not (as is the case in this example), the MSU is passed to the STP’s routing function.

3. The routing function selects which outgoing link to use by searching a routing table for an entry for the DPC (N14 in this example). The routing table identifies another iplimi card (for this example at location 1107) to be used for the outgoing link.

4. Determine whether MSU conversion is required (required when the source network type is not the same as the destination network type). In this example, both Node 11 and Node 14 are ITU-N nodes, so conversion is not required.

5. Forward the MSU across the Interprocessor Message Transport (IMT) bus from location 1103 to location 1107, where the MSU is transmitted out the link towards Node 14.

Routing and Conversion Between Different Network Types

The routing and conversion steps performed by an IP⁷ Secure Gateway when an ITU-N node sends an MSU to an ITU-I node are the same as the steps shown in “Routing and Conversion Within a Single Network Type”, except for the conversion step.

For example, assume that Node 11 in Figure 5-1 sends an MSU to Node 16. The MSU is routed from Node 11 to Node 7 to Node 5 to Node 9 to Node 16. The following steps describe the actions performed at Node 5 (an IP⁷ Secure Gateway):

1. Perform steps 1 through 3 as shown in “Routing and Conversion Within a Single Network Type”. In this example, assume that the routing function determines that the outgoing link is configured on the DCM card at location 1203.

2. Determine whether MSU conversion is required (required when the source network type is not the same as the destination network type). In this example, Node 11 is an ITU-N node and Node 16 is an ITU-I node, so conversion is required. Conversion consists of two phases: Message Transfer Part (MTP) conversion and user part conversion.

3. Perform MTP conversion (also known as routing label conversion). The following parts of the MSU can be affected by MTP conversion:

   • Length indicator—for ITU-N to ITU-I conversion, the length of the MSU does not change

   • Service Information Octet (SIO), Priority—for conversion to ITU, the priority is set to 0. For conversion to ANSI, the priority is set to a default of 0, which can later be changed based on user part conversion.

   • Service Information Octet (SIO), Network Indicator—the NI bits are set to the NI value for the destination node. In this example, NI is set to 00b.

   • Routing Label, Destination Point Code (DPC)—the DPC is replaced with the destination’s true point code. In this example, N16 is replaced by I16.

   • Routing Label, Originating Point Code (OPC)— the OPC is replaced with the appropriate network type’s alias point code for the originating node. In this example, N11 is replaced with I11.

   • Routing Label, Signaling Link Selector (SLS)—no SLS conversion is required between ITU-I and ITU-N nodes. However, if one of the nodes were an ANSI node, conversion would be required between a 5-bit or 8-bit SLS for ANSI nodes and a 4-bit SLS for ITU nodes.

4. Perform user part conversion, if necessary. Currently, only SCCP traffic and network management messages have additional conversion. All other user parts have their data passed through unchanged.

5. Forward the MSU across the Interprocessor Message Transport (IMT) bus from location 1103 to location 1203, where the MSU is transmitted out the link towards Node 16.

Description

In GSM networks, when a mobile subscriber sends a short message, or Mobile Originated Short Message Service message (MO SMS), using his or her handset, the message is first deposited in a Short Message Service Center (SMSC). This SMSC is then responsible for determining where the intended recipient, who is also a mobile subscriber, is located. The SMSC accomplishes this by querying the Home Location Register (HLR) of the recipient to determine which Mobile Switching Center (MSC) the subscriber is currently on. Once the location is determined, the SMSC sends the SMS to the recipient.

In a portability environment, this could lead to problems. The SMSC address to which a message is routed is programmed into the GSM mobile handset. When a subscriber ports to another network, the handset is reprogrammed with the SMSC address for the new network. However, the subscriber could then change this address back to the address from his old network. This would cause SMS to be incorrectly sent to the subscriber's old network SMSC, rather than to the new network SMSC. Since the old network would not have billing records for the ported-out subscriber, the subscriber essentially would receive free SMS service.

The Portability Check for Mobile Originated SMS (MNP SMS) feature is designed to prevent such a possibility from occurring. With this feature, the EAGLE filters incoming messages based on MAP Operation Code. If the message is a MO Forward Short Message (MO FSM), the originating subscriber's Mobile Subscriber Integrated Services Digital Network (MSISDN) number (i.e. phone number) is used to search the G-Port Mobile Number Portability database.

If a match is found, indicating the subscriber has been ported-out, the EAGLE uses the destination SMSC address obtained from the SCCP CdPA to search a list of “home network” SMSC addresses. If a match is found, indicating the ported-out subscriber is attempting to send a short message using the old network's SMSC, the message is discarded. An error message is then generated and returned to the originating MSC.

When the MNP SMS feature is on, the EAGLE performs the following functions:

1. EAGLE receives a UDT message.

2. Checks if the service selector matches G-Port. If so, continues to Step 3; else goes to step 16.

3. Checks if the CdPA SSN matches one of the SSNs provisioned with object type as MSC. If so, continues with Step 4. If the CdPA SSN matches one of the SSNs provisioned with object type as HLR, then proceeds to step 17; else goes to Step 11.

4. Checks if the message is a MO Forward Short Message (MO FSM). If so, it continues to step 5; else go to step 11.

5. Checks if PPSMS feature is ON. If so, goes to step 12; else continues with Step 6.

6. Checks if MNPSMS feature is ON. If so, continues to step 7; else goes to step 11.

7. The originating subscriber's Mobile Subscriber Integrated Services Digital Network (MSISDN) number (i.e. phone number) is used to search the G-Port Mobile Number Portability database. If MSISDN Number is found in the PDB/DN table, continue to step 8; else goes to step 11.

8. Checks the portability type of the subscriber. If it matches "Ported-out/ Not Known/ FNPTFN" then continues to step 9. If portability type is "Prepaid-1/Prepaid-2," goes to step 11.

9. Uses SCCP CdPA Address to search the list of "home network" SMSC addresses. If a match is found, indicating the ported-out subscriber is fraudulently attempting to send SMS using the old network's SMSC, then continues to step 10; else goes to step 11.

10. The message will be discarded, UIM #1129 is printed, and an error message generated and returned to the originating MSC. Go to Step 19.

11. It's a fall-through case. Continue with Normal GTT processing: go to step 19.

12. Checks if message is from one of the IN Platforms (PPSMS Servers). If so, goes to step 18; else continues with step 13.

13. The originating subscriber's Mobile Subscriber Integrated Services Digital Network (MSISDN) number (i.e. phone number) is used to search the G-Port Mobile Number Portability database. If MSISDN Number is found in the PDB/DN table, continue to step 14; else go to step 11.

14. Checks the portability type of the subscriber. If it matches "Prepaid1/Prepaid2," go to step 18; else continue with step 15.

15. If the subscriber portability type is "Ported out / FNPTFN/ Not Known" and MNP SMS feature is also ON, goes to step 9; else goes to step 11.

16. Exits from MNP SMS feature functionality and continues with existing processing for other services or GTT.

17. Exits from MNP SMS feature functionality and continues with existing processing for GPORT.

18. Exits from MNP SMS feature functionality and continues with existing processing for PPSMS.

19. Exits MNP SMS feature functionality.

The following figure illustrates these functions.

Figure 5-2 Flowchart of MNP SMS Functions

Hardware Requirements

No new hardware is needed to support this feature.

SPFILL and RNSPFILL

The SPFILL and RNSPFILL configuration options are introduced for the IDP Relay feature.

The SPFILL option controls the behavior of the CDPNNP and CGPNNP Numbering Plan Processor (NPP) Service Action Handlers in the use of RTDB SP digits. The option indicates whether SP digits are used if Default RN or GRN is used for local subscribers. This option allows use of these Service Action Handlers in NPP rules containing a Formatting Action set that includes both RN and SP.

The RNSPFILL option controls the behavior of the CDPNNP and CGPNNP Service Action Handlers in the use of RTDB RN or SP digits. The option indicates whether SP digits are set to the value of the RN entity digits or the RN digits are set to the value of the SP entity digits, according to the NPTYPE and Default RN option values.

Description

The purpose of the Prepaid Initial Detection Point (IDP) Query Relay feature is to provide a mechanism to insure that prepaid subscribers are accurately charged for their calls in a portability environment.

This feature allows the EAGLE 5 ISS to intercept the SCP number portability database query from the MSC, perform the portability check on the called number, insert the portability information (i.e. Routing Number or HLR Address), and forward the IDP query to a prepaid SCP for processing. When the SCP receives the IDP query, it will have all of the information it needs to accurately charge for and process the call.

For message discrimination on DSM cards, the IDP Relay feature uses the service selector (SRVSEL) framework already present in the EAGLE 5 ISS..

Not all messages for the IDP Relay service will have their outgoing TCAP DN conditioned.

The IDP Relay feature performs the following filters and checks on the intercepted messages to verify that the:

• Service selected is the IDP Relay (:srvsel=idpr) service.

• MSU has the ITU TCAP package

• MSU opcode = IDP

• SCCP/TCAP/INAP are successfully decoded

• SK and event BCSM parameters are present and decoded correctly

• CDPN or CDPN (BCD) parameter is present and decoded correctly

• SCCP CDPA exists in the common screening GTA list for the IDP Relay feature

• SK+BCSM exists in the common screening SKBCSM list for the IDP Relay feature

• Number condition of the TCAP is successful based on Table ID Relay Number Conditioning..

• Conditioned TCAP DN prefix match exists in the common screening CCNDC list for the IDP Relay feature.

• Prefixnum=4 in the Prefix table and , the SCCP CGPA is checked for a default country code (DEFCC) match.

• Conditioned TCAP DN is found in the RTDB single/ Range table with either an SP or RN entity type.

• Based on the Prefixnum=1, 2, 3, the outgoing TCAP DN is conditioned. See for more details.

• The message is forwarded to the GTT handling based on the original incoming SCCP CDPA.

Table IDP Relay Number Conditioning shows the number conditioning performed on the incoming TCAP DN for the IDP Relay feature.

Common Screening List

Common Screening Lists are used for screening messages in various features. The IDP Relay feature can screen up to 4 Common Screening Lists.

The Common Screening List lists supported by this command are not considered part of Gateway Screening or GSM MAP Screening.

One or more Common Screening Lists may be associated with a particular feature. Table Sumary of CSL-supported Features. lists each supported feature, the associated screening list names, and other details about the entries that are supported.

Hardware Requirements

The IDP Relay feature cannot be enabled if Application Services Module (ASM) cards or TSM cards are in the system, or if SCCP gpls are entered in the system.

The IDP Relay feature runs on the VSCCP gpl with DSM cards connected to the EPAP. VSCCP GPLs can also be entered once the feature is enabled.

Limitations

The GTT feature must be on before the IDP RELAY feature can be enabled.

The IDP RELAY feature and the LNP feature cannot be enabled at the same time in the system.

The IDP RELAY feature cannot be enabled if ASM or TSM cards running the SCCP application are present in the system.

Hardware Requirements

No new hardware is needed to support this feature.

Normal Retransmission

The following rules apply to normal PCR:

1. If new MSUs are available, the new signal units are sent.

2. If new MSUs are available and retransmission is occurring, retransmission stops, and the new signal units are sent.

3. If no new MSUs are available to be transmitted, MSUs in the retransmission buffer are retransmitted cyclically.

For this example, assume the following:

1. There are only 3 new MSUs to be transmitted from STP A to STP B.

2. The transmission buffer is empty.

3. Both STPs are using PCR for error correction.

Figure 5-3 illustrates how normal PCR works.

Figure 5-3 Example of Normal Retransmission with PCR

MSUs 1 through 3 are sent from STP A to STP B and are copied to the retransmission buffer. During transmission, packets 1 and 3 are corrupted before reaching the remote STP B.

STP A knows to retransmit the MSUs in the retransmission buffer since no new MSUs are available. Figure 5-3 shows several more copies of packets 1 through 3 are retransmitted.

On the receiving side, STP B receives the corrupt MSUs and discards them. Since PCR is used, STP B does not send a negative acknowledgment to STP A. STP B knows that more copies of the packets are arriving.

Under normal conditions, when no message signal units are to be transmitted or cyclically retransmitted, FISUs are sent. In some particular cases, LSSUs, continuous FISUs or flags may be sent.

Example of Basic Error Correction vs. PCR

Figure 5-4 illustrates how PCR outperforms basic error correction when a link experiences a long transmission delay. Assume the delay between the EAGLE and the SSP is 1 second for both basic error correction and PCR. The MSU size is 50 octets, and the transmission speed is 64 Kbps.

Examine the Basic Error Correction side of the figure. An MSU is sent from the EAGLE to the SSP.

During transmission, the MSU is corrupted. The EAGLE is notified two seconds later that it needs to retransmit the signal unit. Another second later, the valid MSU is received by the SSP. The total amount of time is 3 seconds.

Examine the PCR side of Figure 5-4. An MSU is sent from the EAGLE to the SSP. During transmission, the MSU is corrupted. Since PCR error correction is used, a negative acknowledgment is not sent. The receiving end knows that another copy is coming. The corrupted MSU arrives at the SSP in 1 second, and the valid MSU arrives 0.00625 seconds later. The total time is 1.00625 seconds. This formula is used to calculate the time interval between the first MSU’s arrival and the second MSU’s arrival.

Figure 5-4 Basic Error Correction vs. PCR

Forced Retransmission

To complement preventive cyclic retransmission, the message signal units available for retransmission are retransmitted with priority when a threshold of outstanding MSUs or a threshold of the number of message signal unit octets available for retransmission has been reached. This is forced retransmission.

With PCR, two thresholds are continuously monitored. These thresholds are the number of message signal units available for retransmission, N₁, and the number of message signal unit octets available for retransmission, N₂.

If the N₁ or N₂ value reaches its threshold, no new message signal units or fill-in signal units are sent, and forced retransmission begins. MSUs in the retransmission buffer are sent in the same order that they were originally transmitted. Retransmission continues until all of MSUs have been retransmitted.

If both the N₁ and N₂ values are below the their respective thresholds, the normal PCR procedure can be resumed.

However, if the N₁ or N₂ value is still at its threshold, forced retransmission continues.

Example of Forced Retransmission

The following example shows how forced retransmission occurs. For this example, 5 MSUs are transmitted. Assume the N₁ threshold is 3, and N₂ is 3800 octets. The average MSU size is 50 octets.

Figure 5-5 shows that the EAGLE begins transmitting MSUs to the SSP and copying MSUs to the retransmission buffer.

Figure 5-5 Example of Forced Retransmission

At this point, the threshold for unacknowledged MSUs in the retransmission buffer, N₁ has been reached.

Figure 5-6 shows forced retransmission beginning and continuing until all MSUs in the retransmission buffer have been retransmitted.

Figure 5-6 Example of Forced Retransmission – All MSUs Retransmitted

An acknowledgment for MSUs 1 and 2 comes in before 2 is retransmitted. This does not affect the retransmission of MSU 2. Forced retransmission dictates that all signal units in the retransmission buffer are retransmitted.

After all MSUs have been retransmitted, N₁ and N₂ are re-evaluated. In this case, acknowledgments for MSUs 1 and 2 have been received; thus, N₁ has been reduced and normal PCR resumes. Figure 5-7 shows the new MSUs in the transmission buffer being sent.

Figure 5-7 Example of Forced Retransmission – New MSUs Sent

Derivations for N₁ and N₂

The user is responsible for setting the values for N₁ and N₂. The following rules serve as a guide for determining these thresholds.

• N₁ is limited by the maximum numbering capacity of the forward sequence number range which dictates that not more than 127 MSUs can be available for retransmission on 56 Kbps or 64 Kbps signaling links.

• N₂, in the absence of errors, is limited by the signaling link loop delay, T_L. The value of N₂ must ensure that not more than T_L/T_eb + 1 MSU octets are available for retransmission.

• T_L is the signaling loop delay, that is, the time between the sending of a message signal unit and the reception of the acknowledgment for this message signal unit in undisturbed operation (see Figure 5-8).

  Figure 5-8 Determining Value of Signaling Link Loop Delay Timer (T_L)

  

Assume that T_L = 480 milliseconds or 0.480 seconds. This value is based on a satellite located 22,300 miles above the earth and the signal propagating at a rate of 186,000 miles per second. A minimum of 120 milliseconds are required for a signal to reach a satellite from earth.

• T_eb is the emission time of one octet

• Default value for N₁ = 76 outstanding MSUS

• Default value for N₂ = 3800 octets

The calculations for the default values assume an average MSU of 50 octets.

Default N₁ calculation:

N₁ = 3800 octets from table above / 50 octets from average MSU = 76 outstanding MSUs

Default N₂ calculation:

N₂ = T_L/T_eb +1 = 3800 octets from table above for 64Kbps signaling link.

Limitations

1. This feature does not allow the EAGLE to MTP convert between National and National Spare Point Codes. Likewise, this feature does not allow the EAGLE to MTP convert between International and International Spare Point Codes.

2. In the destination table, an ITU-I alias and an ITU-I Spare alias cannot be defined for the same Point Code, likewise an ITU-N alias and an ITU-N Spare alias cannot be defined for the same point code

3. The feature is not supported on the SEAS interface. Spare point codes are only supported for ITU point codes, and SEAS only supports ANSI point codes. Any Private ANSI point code provisioned using the standard EAGLE command line interface is not displayed by the SEAS VFY- command.

4. ITU National and ITU National Spare Point Code are implemented as separate network domains that can co-exist within the same STP.

5. Spare point codes are not supported for IPGWI sockets using TALI protocols. The spare point code feature may not be enabled if any application sockets have been provisioned on IPGWI cards.

6. The existing implementation of Gateway Screening does not support Group Code (Duplicate Point Codes). Gateway Screening will also not support PPCs.

7. The Spare Point Code and PPC prefix value, s- and p- do not apply to domain type point codes for ANSI and ITU-N24.

8. ITU-N and ITU-N24 Point Codes cannot co-exist as SID Destination True Point Codes and therefore ITU-N Spare and ITU-N24 Point Codes cannot coexist as SID Destination True Point Codes.

9. A single STPOPTS value (cnvcgdi) will be used to control message handling for ITU-I and ITU-I Spare messages when the CgPA PC does not have a required alias

10. A single STPOPTS value (cnvcgdn) will be used to control message handling for ITU-N and ITU-N Spare messages when the CgPA PC does not have a required alias

11. The existing implementation of the SRVSEL command interface to the SRVSEL table does not provide a way to separate MSU traffic for different ITU National Group Code networks. Therefore no provision is made for the SRVSEL command to control the separation of ITU spare and non-spare traffic. The SRVSEL table applies to the EPAP based features G-FLEX, INP, G-PORT, SMS Prepaid, and IS-41 to GSM Migration. Likewise, no provision is made for the GTTSEL command interface to the GTTSEL table to allow separation of ITU spare and non-spare traffic for EGTT, VGTT and MGTT.

User Interface (EPAP GUI)

PDBI Statistics Report

This feature will provide a new menu option “PDBA--> PDBI Statistics Reports” to enable EPAP GUI users to view available statistics reports.

Clicking this menu item will display a new screen in a browser’s right frame to view a statistics report. Select the report generation type and identify the time period for the report.

Click on the “Generate Report” button to display the report.

List PDBI Connections

This feature provides a new menu option “PDBA--> List PDBI Connections” to enable EPAP GUI users to view all provisioning connections to the PDBA. This GUI provides non-persistent data about PDBI and SOG connections along with some performance data based on the totals for the entire lifetime of each connection.

Upgrade Considerations

A new MySql database must be created to house PDBI statistical data on MPS-A servers during an upgrade or fresh install.

Limitations

PDBI statistical-data reports will be generated on-demand and are only available if the PDBI Command Statistics feature is ON. This feature is OFF by default, except on T1200 AS where it is ON by default.

This feature is not intended to provide the customer with an instantaneous (less than 1 second) performance rate. Dedicating too much processing power to keeping and calculating rates could be detrimental to performance. Additionally, performance rates calculated on too small of a time period could provide misleading information.

Peak CPS values in the PSR or listPDBIConns.pl output shall be displayed as whole number values (no fractional values or anything less than 1 CPS) since these are calculated with the reported number of commands that completed processing in a one-second time frame. A majority of commands under normal processing will take fractions of a second to perform. The average CPS values for larger time periods (minutes) will provide a much more accurate indication of system PDBI performance.

Due to current implementations, data in the EPAP pdba.cmd log, PDBI Statistics Report and List PDBI Connections may not match due to slight differences in the timestamps used to record a PDBI command. This discrepancy between a PDBI Statistics Report and List PDBI Connections might be most noticeable for a peak CPS on a system with a single provisioning stream.

This feature is not supported on non-provisionable EPAP systems. This feature is also not supported on B servers of a provisionable EPAP pair.

TOS

The 8-bit TOS socket option is used to control the quality of service for network traffic. The intent of QoS is to route packets differently according to the TOS value. TOS is set on outgoing packets. The following sections describe the TOS bit field and give an example of a QoS model.

TOS Bit Field

Figure 5-10 describes the TOS bit field structure. The 8-bit TOS field resides in the IP header (Figure 5-9) and is used to identify different priorities/levels/interactions of service used by network routers, such as low-delay service. The TOS field within the outgoing datagram is set from values in the application socket’s protocol control block (PCB). The TOS value defaults to 0 (normal service), since the PCB is initialized to zero. The TOS bits may be set to other values and read using the setsockopt and getsockopt system calls, which provide access to the TOS byte within the PCB.

Figure 5-9 IP Header Fields

Figure 5-10 TOS Field

DS Bit Field

The first network QoS decoding scheme used the TOS bit field description (Figure 5-10). Another QoS decoding scheme is the IETF Differentiated Services (DiffServ) model. DiffServ renamed the TOS field to the DS field. Figure 5-11 describes the DS bit field structure. DS bits 0-5 are reserved for code points (DSCP). The upper two bits (CU) are currently unused. DiffServ code points are broken down into three pools, each pool representing the number of bits used within the DSCP field. Code pool 1, which provides 32 code points, is available for general use, while pools 2 and 3, providing 16 code points, are designated for experimental use only.

Figure 5-11 DS Field

Figure 5-12 DiffServ Code Point Pool Table

This feature allows the customer to modify the full 8-bit TOS socket option to control QoS. The customer is free to implement any QoS model that uses the 8-bit structure within the IP header TOS/DS bit fields.

Nagle’s Algorithm

Nagle’s algorithm is currently disabled for all IP⁷ Secure Gateway sockets. So every message is transmitted via Ethernet as soon as possible. This means there is a one-TCP-packet-per-MSU relationship. This minimizes message latency, which is very important to Secure Gateway deployment in networks. While minimizing message latency, this mode of operation results in more packets, and therefore more CPU utilization processing packet headers, and also results in less efficient LAN utilization. When Nagle’s algorithm is enabled, it allows the TCP/IP stack to hold onto messages for a period of time in an effort to pack multiple messages into a single TCP packet. At the expense of higher message latency, fewer packets are generated and processed, resulting in lower CPU utilization, and the fewer and larger packets result in more efficient LAN utilization. At high rates of traffic through a socket, message latency is minimal, since the threshold packet size is reached (messages fill the packet) very quickly, causing the stack to transmit the packet. At low rates of traffic, a stack timer governs how long a packet will be held prior to transmission. The application of Nagle’s Algorithm only affects packet transmission and has no effect on the processing of received packets.

This feature allows the customer to enable or disable Nagle’s algorithm. The socket option is defined as a 1-bit Boolean socket option; 1=Enable, 0=Disable.

Feature Implementation

Figure 5-13 illustrates the overall design for implementing the QoS feature. The example shows how an application socket’s TOS value can be changed using commands. The example also could be extended to cover modifying other socket options, including enabling/disabling of Nagle’s algorithm. When an application socket is created, it is always assigned to DCMPS parameter set #10, containing the default socket options. Socket options may then be changed using one of the following commands:

chg-appl-sock

In Figure 5-13, example 3, an application socket is changed to a different DCMPS parameter set. In this example the new DCMPS parameter set contains a different TOS value. This is accomplished by issuing the following admin command:

CHG-APPL-SOCK:SNAME=sockname:DCMPS=new_param_set

Changing an open socket to a different DCMPS set forces the socket to use the new DCMPS set’s TOS value. This change occurs “on-the-fly.” The socket does not need to be closed or inhibited. System call setsockopt() is invoked with the new DCMPS set TOS, thereby updating the affected socket’s PCB.

chg-dcmps

In Figure 5-13, example 4, the DCMPS parameter set’s TOS parameter is changed to a different value. This causes all sockets using the modified DCMPS parameter set to use the new TOS value. This is accomplished by issuing the following admin command:

CHG-DCMPS:SET=setnum:PARM=1:PVALUE=new_tos_value

Changing the TOS parameter within a DCMPS set forces all existing sockets using that DCMPS set to use the new TOS value. For all open sockets, this change occurs “on-the-fly.” System call setsockopt() is invoked for all sockets using the modified DCMPS set, updating the socket’s PCB with the new TOS.

Only sockets affected using the above administration commands allow their socket options to be updated/changed.

Figure 5-13 ToS Setup

Description

This feature implements the following enhancements:

• New "mode=full" parameter and report. This report prints out a list of cards that are presenting with a clock failure.

  Note:

  HS clock information is included in the new report when a card capable of supporting HS links is provisioned (regardless of link provisioning).

Hardware Requirements

No new hardware is needed to support this feature.

Hardware Requirements

No new hardware is needed to support this feature.

Description

The RTDB Retrieve feature allows the user to query (from the web GUI) data that resides in the RTDB (Real-Time Database). This feature enables the user to compare data in the PDB (Provisioning Database) with data in the RTDB to verify that they are consistent.

In previous releases of EPAP, queries on EPAP have been supported only by the PDB. The ability to retrieve RTDB data assists in troubleshooting cases where data is absent on EAGLE 5 ISS, but present in the PDB.

Data returned from RTDB is presented on the EPAP GUI in a format that is similar to data from the PDB. This similarity makes it easier to compare data between the two databases when a discrepancy is suspected.

New menu items been added to the EPAP menu:

• Single DNs
• DN Blocks
• Network Entities
• Single IMSIs
• IMEIs
• IMEI Blocks

RTDB retrieval screens are selectively revocable to users and groups by User Interface administrators.

Data can be retrieved while application software is running. Input screens look like the PDBA (Provisioning Database Application) input screen sections for single retrieval of the same data type. Output screens look like the PDBA output screen for the same data type.

A failure message will identify an item as not found if this is the cause of lookup failure.

Hardware Requirements

None.

Limitations

None.

Description

The RTRV-RTE/RTRV-DSTN Support of PC Wildcards feature enhances the rtrv-rte command to retrieve destinations by specifying the ** (double asterisk) or *** (triple asterisk) value for the nc and ncm subfields of the ANSI point code as follows:

• rtrv-rte:dpc=ni-nc-**
• rtrv-rte:dpc=ni-nc-***
• rtrv-rte:dpc=ni-**-ni
• rtrv-rte:dpc=ni-***-***
• rtrv-rte:dpcn=*-aa
• rtrv-rte:dpcn=nnnnn-*
• rtrv-rte:dpcn=m1-m2-m3-m4-*

  Note:

  If *, **, or *** is used for the nc subfield, then *, **, or *** must be also be used for the ncm field.

A double asterisk in the nc subfield of a network routing point code produces a summary report that shows all point code destinations that are members of the given network (21-**-*). This does not include the specified network routing point code. The following example shows a report generated using two asterisks in the This is the same function that currently exists for the rtrv-dstn command.

Hardware Requirements

The RTRV-RTE/RTRV-DSTN Support of PC Wildcards feature has no hardware requirements.

Limitations

The RTRV-RTE/RTRV-DSTN Support of PC Wildcards feature has no limitations.

Description

The RTRV-STP Command feature provides the new rtrv-stp command, which provides the functionality of the rtrv-bip, rtrv-gpl, rtrv-card, and rept-stat-card commands in a single command. The rtrv-stp command displays the current power consumption and power thresholds for all frames or for a specified frame, allowing users to retrieve the card location, board part number, revision, assembly serial number, DB Size, card type, GPL type, and GPL version for all card locations.

Hardware Requirements

The RTRV-RTE/RTRV-DSTN Support of PC Wildcards feature has no hardware requirements.

Limitations

The RTRV-STP Command feature has the following limitations:

• Since the Frame Power Consumption value is updated periodically at SCM from the FPBA task, the power consumption value displayed by rtrv-stp may not be the latest value but the last updated value.
• The rtrv-stp command may produce 850 Board Part Numbers instead of 870 Board Part Numbers.

Description

The RTRV-STP on FTRA feature allows a user to retrieve rtrv-stp command information in a CSVGEN comma-delimited format, using FTRA Release 4.0. Refer to the FTP-Based Table Retrieve Application (FTRA) User Guide in your Release 35.1 Customer Documentation for more information on FTRA.

Hardware Requirements

The RTRV-STP on FTRA feature has no hardware requirements.

Limitations

The RTRV-STP on FTRA feature has no limitations.

Hardware Requirements

No new hardware is needed to support this feature.

Description

The SCCP Service Re-Route Capability feature is designed to re-route G-Flex and G-Port traffic from a node that is unable to process traffic to alternate nodes within an operator network. This feature allows the user to mark the G-Flex or G-Port services OFFLINE, which causes messages to be re-routed to provisioned destinations, either alternate point codes (PCs) or a GTT option. When the user returns either or both services to ONLINE, the services resume processing traffic. The SCCP Service Re-Route Capability feature is optional and doesn't affect normal G-Flex or G-Port functionality.

The G-Flex and G-Port services normally run in tandem with the SCCP service, with no way to halt G-Flex or G-Port without bringing down the entire SCCP service. The SCCP Service Re-Route Capability feature allows the user to mark the G-Flex and/or G-Port services OFFLINE, which re-routes traffic for those services to alternate nodes. The user can mark either or both services ONLINE to cause the service to resume processing traffic.

For example, in Figure 5-14, G-Flex and G-Port traffic originating from SSP_A, SSP_B, and SSP_C is distributed between STP_1 and STP_2. G-Flex and G-Port traffic is addressed to the relevant service Capability Point Code (CPC) of STP_S1 and STP_S2. GTT traffic is addressed to STP_1 and STP_2.

When the G-Flex/G-Port service is unavailable on STP_1, STP_1 sends a response method TFP message regarding STP_S1. This causes SSP_A to stop using Link_A1 for G-Flex/G-Port traffic. STP_1 can re-route all in-transit G-Flex/G-Port traffic to STPs STP_S2, STP_S3, and STP_S4 if provisioned. SSP_A now sends all of its G-Flex/G-Port traffic on link_A2. GTT traffic and MTP routed traffic is not impacted. Other SSPs perform similar rerouting.

When G-Flex/G-Port service is available on STP_1, STP_1 responds with a TFA message (when route-set-test message is received) regarding STP_S1. This causes SSP_A to start sending the G-Flex/G-Port traffic through link_A1. Other SSPs perform similar rerouting.

New Concepts

The SCCP Service Re-Route Capability feature introduces the following new concepts:

• “Service State”

• “Service Re-routing”

• “Service Capability Point Code”

Service State

Service State is an administered state of a RTDB-based service and indicates whether a service is ONLINE or OFFLINE. The SCCP Service Re-Route Capability feature supports Service State for the G-Flex and G-Port services only.

Service State allows a user to mark the G-Flex and G-Port services OFFLINE or ONLINE. If a user identifies a problem with G-Flex or G-Port, they can mark the service OFFLINE to initiate re-routing.

Once the service is returned to ONLINE, the G-Flex or G-Port service starts processing messages if at least one SCCP card is IS-NR.

Service Re-routing

Service Re-routing is an optional function that allows a user to determine the destination of a re-routed message by use of a list of up to seven alternate PCs per domain or the GTT option. The SCCP Service Re-Route Capability feature supports Service Re-routing for the G-Flex and G-Port services only.

Re-routing is activated by marking a service OFFLINE. When a service is OFFLINE, any messages destined to that service are re-routed to available alternate PCs that have been defined for that service. If alternate PCs are not defined, or if none of the PCs are available, then the GTT option is invoked. If the GTT option is YES, then messages destined to that service go to GTT.

Service Capability Point Code

The SCCP Service Re-Route Capability feature provides CPC support for G-Flex and G-Port services. For messages destined to a service, the use of CPCs aids the adjacent nodes in knowing about service outage. When a service is brought down though administrative commands, all traffic destined to this service node performs the following actions:

• Generate response method TFP message to the adjacent node about service CPC. The TFP response to the adjacent node causes the traffic originating nodes to stop sending service traffic to this node. All service traffic coming into this node is sent to the alternate service nodes. Adjacent nodes initiate route-set-test procedures after receipt of the TFP.

• If the messages are destined to EAGLE 5 SAS TPC, then TFP messages are not generated when a service is OFFLINE. Therefore, the originator is not aware of the outage.

• Once the service is back in service on the EAGLE 5 SAS, a TFA is sent to the traffic adjacent nodes in response to route-set-test message. The traffic originating nodes then start sending service traffic to this node.

Hardware Requirements

The SCCP Service Re-Route Capability feature runs on DSM cards.

Description

Shortly after the introduction of the Stream Control Transmission Protocol (IETFRFC 2960), a fundamental weakness was detected in the Adler-32 checksum^Foot 1 algorithm currently used in the RFC. One requirement of an effective checksum is that it evenly and smoothly spreads its input packets over the available check bits. For small packets, Adler-32 provides weak detection of errors.

After much debate and research, the IETF has produced an improved checksum algorithm, CRC-32c, to be used with RFC 2960. The SCTPChecksum Update feature implements this improved algorithm. The SCTPChecksum Update feature provides a choice of SCTP checksum algorithms, and a user interface to both change and display the type of algorithm used.

The IPGWx and IPLIMx support both SCTP checksum algorithms; the current Adler 32 checksum algorithm and the new CRC-32c checksum algorithm. The CRC-32c Checksum algorithm is implemented on all SCTP-based cards in the IP7 or EAGLE node.

Background

Checksums provide protection against data corruption in the network. The sender of an SCTP packet computes a checksum according to an algorithm. The checksum is placed in the Checksum field residing in the SCTP Common Header (see Table 5-11). The receiver then re-computes the checksum, using the same algorithm. The SCTP packet is accepted if the checksum is valid; otherwise, the packet is discarded.

Adler-32

Adler-32 was the only SCTP checksum algorithm supported and used by the SG prior to this feature. The IETF has determined that the Adler-32 checksum does not provide strong protection against error detection when applied to small packets. Because SCTP protocol signaling messages are typically less than 128 bytes, a better-suited checksum algorithm is needed. This algorithm continues to be supported by the SG.

CRC-32c

Now supported by the SG, the CRC-32c SCTP checksum algorithm solves the limitations of Adler-32. CRC-32c provides better error detection for small packets than does Adler-32.

Hardware Requirements

This feature requires the SSEDCM (P/N 870-2372-01).

For M2PA associations, the chg/rtrv-uaps commands are updated to indicate the byte format for the SCTP Payload Protocol Indicator (PPI) value that is received and transmitted in MSUs. The uaps parameter 4, bit 0 indicates whether the SCTP PPI value is received and transmitted in Network Byte Order (Big Endian) or Host Byte Order (Little Endian).

    eagle10213 10-01-07 14:01:00 EST  EAGLE 42.0.0
    SET  TIMER      TVALUE  PARM      PVALUE
      1      1           0     1           3
      1      2        3000     2           0
      1      3       10000     3           0
      1      4        5000     4           0
      1      5           0     5           0
      1      6           0     6           0
      1      7           0     7           0
      1      8           0     8           0
      1      9           0     9           0
      1     10           0    10           0

    TIMER 2: False IP Connection Congestion Timer, max time an
             association can be congested before failing due to false
             congestion. SS7IPGW and IPGWI applications enforce
             0-30000(ms). Not supported on IPSG application.
    TVALUE : Valid range = 32-bits

    TIMER 3: UA HeartBeat Period Timer T(beat), time (ms) between sending
             of BEAT msgs by NE. IPSG, SS7IPGW and IPGWI applications
             enforce 100(ms)-60000(ms).
    TVALUE : Valid range = 32-bits

    TIMER 4: UA HeartBeat Received Timer T(beat ack), timeout period for
             response BEAT ACK msgs by NE. IPSG, SS7IPGW and IPGWI
             applications enforce 100(ms)-10000(ms).
    TVALUE : Valid range = 32-bits

    PARM  1: ASP SNM options.  Each bit is used as an enabled/disabled
             flag for a particular ASP SNM option. Not supported on IPSG
             application.
    PVALUE : Valid range = 32-bits
             BIT                                  BIT VALUE
             0=Broadcast                          0=Disabled , 1=Enabled
             1=Response Method                    0=Disabled , 1=Enabled
             2-5=Reserved
             6=Broadcast Congestion Status Change 0=Disabled , 1=Enabled
             7-31=Reserved

    PARM  2: ASP/AS Notification options.  Each bit is used as an
             enabled/disabled flag for a particular ASP/AS
             Notification option.  Not supported on IPSG application.
    PVALUE : Valid range = 32-bits
             BIT                                  BIT VALUE
             0=ASP Active Notifications           0=Disabled , 1=Enabled
             1=ASP Inactive Notifications         0=Disabled , 1=Enabled
             2=ASP AS State Query                 0=Disabled , 1=Enabled
             3-31=Reserved

    PARM  3: UA Serviceability Options.  Each bit is used as an
             enabled/disabled flag for a particular UA Serviceability
             option. Supported on IPSG, SS7IPGW, and IPGWI applications.
             UA Graceful Shutdown supported on IPSG for M3UA only.
    PVALUE : Valid range = 32-bits
             BIT                                  BIT VALUE
             0=UA Heartbeats                      0=Disabled , 1=Enabled
             1=UA Graceful Shutdown               0=Disabled , 1=Enabled 
             2-31=Reserved

    PARM  4: SCTP Payload Protocol Indicator byte order option. Bit indicates 
             PPI value is RCV/TX in Big Endian or Little Endian byte format.  
             Supported on IPSG-M2PA associations only.
    PVALUE : Valid range = 32-bits
             BIT                               BIT VALUE
             0=Payload Protocol Indicator      0=Big Endian , 1=Little Endian
             1-31=Reserved

The chg-assoc command is updated to support M2PA associations for the uaps parameter. The rtrv-assoc command is updated to display the uaps value for M2PA associations. The output is also updated to increase readability.

Example 1 retrieves all assocations.

                    CARD  IPLNK
    ANAME           LOC   PORT  LINK ADAPTER LPORT RPORT OPEN ALW
    a23456789012345 1305  A     A    M3UA    20000 30000 YES  YES
    b23456789012345 1305  B     A    M3UA    20001 30001 NO   NO
    c23456789012345 1307  A     A    SUA     20002 30002 YES  YES
    d23456789012345 1307  B     A    M3UA    20003 30003 NO   NO
    e23456789012345 1315  A     A    SUA     20004 30004 YES  YES
    f23456789012345 1315  A,B   A    M3UA    20005 30005 YES  YES
    g23456789012345 1317  B,A   A    SUA     20006 30006 YES  YES
    m2pa1105b3      1105  A     B3   M2PA    31105 31105 YES  YES   
    m2pa1107a0      1107  A     --   M2PA    1107  1107  NO   NO    
    m2pa1107a1      1107  A     --   M2PA    11107 11107 NO   NO    
    m3ua1211a0      1211  A     A    M3UA    1211  1213  YES  YES   
    m3ua1211a1      1211  A     **   M3UA    11211 11213 YES  YES   
    m3ua1211a2      1211  A     B1   M3UA    21211 21213 YES  YES   
    m3ua1211a3      1211  A     A3   M3UA    31211 31213 YES  YES   
    m3ua1213a0      1213  A     A    M3UA    1213  1211  YES  YES   
    m3ua1213a1      1213  A     A1   M3UA    11213 11211 YES  YES   
    m3ua1213a2      1213  A     A2   M3UA    21213 21211 YES  YES   
    m3ua1213a3      1213  A     A3   M3UA    31213 31211 YES  YES   
    ipg1215a01      1215  A     **   M3UA    11215 1111  YES  YES   
    ipg1215a02      1215  A     **   M3UA    11215 1112  YES  YES   
    ipg1215a03      1215  A     --   M3UA    11215 1113  NO   NO    
    ipg1215a04      1215  A     --   M3UA    11215 1114  NO   NO    
    ipg1215a05      1215  A     --   M3UA    11215 1115  NO   NO    
    ipg1215a06      1215  A     --   M3UA    11215 1116  NO   NO    

    IP Appl Sock/Assoc table is (24 of 4000) 1% full
     
;

Example 2 retrieves a specified M2PA association.

    ANAME m2pa1
          LOC      1305          IPLNK PORT A           LINK     B1
          ADAPTER  M2PA          VER        M2PA RFC
          LHOST    e1011001.1305a
          ALHOST   ---
          RHOST    e1011501.1305a
          ARHOST   ---
          LPORT    2005          RPORT      2005
          ISTRMS   2             OSTRMS     2           BUFSIZE  200
          RMODE    LIN           RMIN       120         RMAX     800
          RTIMES   10            CWMIN      3000        UAPS     7
          OPEN     NO            ALW        YES         RTXTHR   0
          RHOSTVAL RELAXED       M2PATSET   1

          LSN
          lsm2pa05

Hardware Requirements

This feature requires a SSEDCM (Single Slot Enhanced DCM).

Affected Commands

The parameters in Table 5-12 are not currently supported by the SEAS definition of the ADD-LS command:

In order to allow users of the SEAS interface the ability to set values for EAGLE- specific parameters, the unshaded parameters in Table 5-12 are allowed to be specified using the SEAS supplier specific parameter block. The GWS- specific parameters are not allowed in the supplier-specific parameter block because they are implemented as part of the supplier-specific parameter block of the GTWYLS entity; see add-gtwyls.

The syntax for supplier-specific parameter “Z” of the SEASADD-LS command is as follows:

Syntax

 "[BEI],L3TSET,[SLSCI],[ASL8],[SLTSET],[NIS],[MTPRSE]"

The following example is provided to help customers understanding the new capability of specifying supplier-specific parameter blocks via SEAS commands on the EAGLE.

Suppose the user wants to add a linkset where all of the Supplier Specific parameters get set to the default value. This can be done in four different ways:

Input Example

1. ADD-LS::LS1201:000003:50,RCH::LNSCLLI1201-012001001:A::,G63D45G25-001-07

2. ADD-LS::LS1201:000003:50,RCH::LNSCLLI1201-012001001:A:",,,,,,":,G63D45G25-001-07

3. ADD-LS::LS1201:000003:50,RCH::LNSCLLI1201-012001001:A:"0,1,0,0,1,0,0":,G63D45G25-001-07

4. ADD-LS::LS1201:000003:50,RCH::LNSCLLI1201-012001001:A:",,0,0,1,0,0":,G63D45G25-001-07

The first method simply leaves out parameter "Z" and the appropriate default values are assigned.

The second method specifies parameter "Z" enclosed in quotes. All the members of the supplier-specific parameter block are optional, and can be omitted (the colons must always be specified if parameter "Z" is specified).

The third method specifies the appropriate default values for each supplier-specific parameter within the block.

The fourth method specifies default values for SLSCI, ASL8, SLTSET, NIS, and MTPRSE. All four commands will result in the same entry created in the EAGLE database.

The following parameters are not currently supported by the SEAS definition of the CHG-LS command.

In order to allow users of the SEAS interface the ability to set values for EAGLE specific parameters the highlighted parameters above are allowed to be specified using the SEAS supplier specific parameter block. The GWS-specific parameters are not allowed in the supplier specific parameter block because they are implemented as part of the supplier-specific parameter block of the GTWYLS entity; see add-gtwyls.

The syntax for supplier-specific parameter "Z" of the SEASADD-LS command is as follows:

Syntax

 "[TFATCABMLQ]:[BEI]:L3TSET:[SLSCI]:[ASL8]:[SLTSET]:[NIS]:[MTPRSE]"

dlt-ls

There are no supplier specific parameters available for the SEASDLT-LS command.

vfy-ls

There are no supplier-specific parameters available for the SEASVFY-LS command on input. However, the output of the VFY-LS command includes the following output for the supplier specific parameter block:

Syntax

 "TFATCABMLQ:BEI:L3TSET:SLSCI:ASL8:SLTSET:NIS:MTPRSE"

add-gtwyls (Gateway Linkset)

In order to allow users of the SEAS interface the ability to set values for EAGLE-specific parameters the unshaded parameters in Table 5-14 are allowed to be specified using the SEAS supplier-specific parameter block.

Only GWS-specific parameters are allowed in the supplier specific parameter block. The shaded parameters (with exception to the SCRN parameter) are supported in the Linkset supplier-specific parameter block.

dlt-gtwyls

There are no supplier-specific parameters associated with the DLT-GTWYLS command.

chg-gtwyls

The supplier-specific parameter block for the CHG-GTWYLS command is equivalent to the supplier-specific parameter block for the ADD-GTWYLS command (see add-gtwyls).

vfy-gtwyls

There are no supplier specific parameters available for the SEASVFY-GTWYLS command on input. However the output of the VFY-GTWYLS command will include the following output for the supplier-specific parameter block:

Syntax

 "[GWSA],[GWSM],[GWSD],[ACTNAME],[DESTFLD],[SCRN]"

asgn-slk (Signaling Link)

In order to allow users of the SEAS interface the ability to set values for EAGLE specific-parameters, the EAGLE supports a supplier-specific parameter block for the SEAS command ASGN-SLK. The supplier-specific parameter block consists of all the parameters from Table 5-15.

The syntax for supplier-specific parameter "Z" , of the SEASASGN-SLK command, is as follows:

Syntax

 "[L2TSET]:[L Adresse 1MODE]:[TSET]:[ECM]:[PCRN1]:[PCRN2]:[LPSET]:[ATMTSEL]:[VCI]:[VPI]:[LL]"

dlt-slk

No supplier-specific parameter support is required for the SEASASGN-SLK command.

chg-slk

No supplier-specific parameter support is required for the SEASCHG-SLK command.

vfy-slk

There are no supplier-specific parameters available for the SEASVFY-SLK command on input. However, the output of the VFY-SLK command includes the following output for the supplier-specific parameter block:

Syntax

 "[L2TSET]:[L1MODE]:[TSET]:[ECM]:[PCRN1]:[PCRN2]:[LPSET]:[ATMTSEL] :[VCI]:[VPI]:[LL]"

After the SEAS Over IP feature is enabled and turned on, the EAGLE 5 ISS acts as a client and connects to the CCS MR, which acts as the server. Data is passed between the EAGLE 5 ISS and the CCS MR using the SR-5129 protocol.

The SEAS Over IP feature can be used to replace the current EOAP in the EAGLE 5 ISS and will be used as the sole solution for future SEAS interface installations. However, the EOAP feature is still supported. If the EOAP is correctly provisioned, then EOAP functionality resumes automatically when the SEAS Over IP feature is turned off. The EOAP and SEAS Over IP features cannot operate at the same time.

The SEAS Over IP feature is integrated into the ipshc GPL on the E5-IPSM card. The E5-IPSM card allows one of eight IP terminals to be configured as the SEAS terminal to provide connectivity between the CCS MR and the EAGLE 5 ISS. The E5-IPSM card provides the EAGLE 5 ISS with generic IP-based services, such as Telnet and FTP, on the remaining 7 IP terminals.

The SEAS Over IP feature must be configured on both the EAGLE 5 ISS and the CCS MR. EAGLE 5 ISS commands are used to configure CCS MR information on the EAGLE 5 ISS. The CCS MR is configured directly. Refer to Telcordia Configuration Specification "Telcordia Technologies System Documentation", BD-SNAM-ADMIN-4 Issue 14, November 2006 for information on configuring the CCS MR.

The SEAS Over IP feature supports the configurations shown in the following table:

Rebase to TPD 4.0 or higher

EPAP is rebased to TPD 4.0 to pick up security improvements and better password restrictions.

Change of kernel parameters to prevent network attacks

Kernel parameters are modified to reduce the possibility of network attacks and other security breaches.

Removal of .rhosts

The /home/epapall/.rhosts file is removed from EPAP to prevent unauthorized access to the servers.

Restrict root account access

A new allowRoot script is introduced to modify Access Restriction for root account.

usage:

* [ allowRoot OFF] -
Comment all the entries in /etc/securetty
- PermitRootLogin Yes|No in /etc/ssh/sshd_config
- UnComment|Comment the line:
"#auth required /lib/security/$ISA/pam_wheel.so use_uid"in file
/etc/pam.d/su

* [ allowRoot ON] -
Uncomment all entries in /etc/securetty except ttyS0
- PermitRootLogin Yes|No in /etc/ssh/sshd_config
- UnComment|Comment the line:
"#auth required /lib/security/$ISA/pam_wheel.so use_uid"in file
/etc/pam.d/su

* [ allowRoot tty ON|OFF] -
Uncomment|Comment all ttyN in /etc/securetty

* [ allowRoot ttyN ON|OFF]

- Uncomment|Comment only ttyN specified by user

* [ allowRoot ttyS0 ON|OFF]

- Uncomment|Comment only ttyS0

* [ allowRoot ssh ON|OFF] -

PermitRootLogin Yes|No in /etc/ssh/sshd_config
* [ allowRoot allowSU
ON|OFF] - UnComment|Comment the line:
"#auth required /lib/security/$ISA/pam_wheel.so use_uid"in file
/etc/pam.d/su

TCP Wrappers

A new script manageEPAPAuthIp is introduced. This script is used to list, add, or delete Authorized IPs. If the value of Restrict server access to authorized IPs is set to no, then the server can be accessed from any IP address. If the value is set to yes, then the server can be accessed only from the IP addresses that are added in file /etc/hosts.allow.

Increasing the FTA (File Transfer Area)

The FTA is used to store the security logs and the hourly and daily measurements (weeks worth of measurements data [5]). The FTA is designed to contain four security logs, each of size 2.5 MB (10K entries * 256 record size). Since the size of the security log has been increased from 10K to 50K, the FTA has been increased by at least 40MB. Hence the FTA has been increased to 100MB to accommodate this feature.

Upgrade Considerations

Before the upgrade, entire security log must be uploaded. The procedure to upload the security log follows:

1. Issue the REPT-STAT-SECULOG command to determine which security log should be uploaded. Under normal operating conditions, the standby OAM's security log should always contain 0 in the ENTRIES column, and thus should never need uploading. However, if the standby OAM's log contains one or more un-uploaded entries, it should be uploaded as well.

2. Issue the COPY-SECULOG command with appropriate parameters to cause the log to be copied to the FTA area. Note the name of the file that is created in the FTA area, and also the location 1114/1116 of the FTA area which received the copy. This information will be displayed in the scroll area at the successful conclusion of the COPY-SECULOG command.

   If the security log has to be ported onto a PC, the following two steps need to be performed as well

3. On an EAGLE terminal that is being emulated on a suitably-equipped PC (e.g. a PC running ProComm), issue the ACT-FILE-TRNS:LOC=xxxx command, specifying xxxx as the location 1114 or 1116 of the FTA area containing the log to be uploaded.

4. Start a Kermit download session on the PC. If using ProComm, this is accomplished by selecting the "Online" menu item, then "Kermit command", then "Get file". At this point a dialog box will be presented asking for the name of the file to be transferred. Enter the name of the file noted during the COPY-SECULOG command in step 3, and press the OK button to transfer the file from the EAGLE to the PC.

Limitations

Due to the circular nature of the security logs, if the security log is not uploaded when it is full, it will start to overwrite the contents. Hence the security log should be uploaded when "log full" alarm is raised. This feature does not affect any other GPL's running on other cards.

Rules for the Self Healing DN Range in EPAP Database feature

Error Codes

Error Codes Introduced by the Self Healing DN Range in EPAP Database feature:

• PDBI_MULTI_DNB_CONFLICT: More than one conflicting DN Block exists in the EPAP database.
• PDBI_DNB_SAME_PROPERTIES: A DN Block with the same properties exists in the EPAP database and is a superset of the requested DN Block. Splitting eligibility of a DN Block is not a property for this error.
• PDBI_DNB_SPLIT_NOT_ALLOWED: an existing DN Block that was specified at the time of its creation or update is ineligible for splitting.
• PDBI_DNB_DLT_NOT_ALLOWED: A fragment of a master range cannot be deleted while its subranges are present.
• PDBI_DNB_PARENT_PROPERTY_MISMATCH: A fragment of a master range with differing attributes cannot be deleted. Splitting eligibility of a DN Block is a property for this error.

Hardware Requirements

No new hardware is required to support this feature.

Enhancements to the User Interface

A new section will be added to the RTDB Status screen of the EPAP UI to display the RTDB Homing policy for both RTDBs on the MPS.

The PDBA Status sections of both the RTDB Status and PDBA status screens will be enhanced to display the current RTDB clients.

Upgrade Considerations

This feature does not impact the EPAP 1.x/2.x to 3.0 upgrade. New EAGLEs may not be included for provisioning until all affected sites have been upgraded to EPAP 3.0. RTDB homing policy may not be changed until all affected sites have been upgraded to EPAP 3.0. Interaction with EAGLE is not affected by this feature.

Limitations

The limitations include:

• This use case is only supported on SLIC cards.
• The stateful screening of messages may add up to 300 ms latency on average.
• The stateful security solution is only applied on Gateway STP nodes.
• SFAPP UC3 and SS7 firewall SFLOG features cannot coexist on same node.
• The following features are not compatible with SFAPP:
  • GSM MAP screening - SFAPP card does not support EGMS.
  • HLR Routing feature (GFLEX) on the same node. GFLEX interaction may be required for the ATI messages that need to be routed to the correct HLR for messages that do not have HLR address in the CdPA. This can be done by routing the message using the EAGLE mate using the C-Links.

For complete Use Case information, see the Stateful Applications User's Guide.

Limitations

The limitations include:

• This use case is only supported on SLIC cards.
• The stateful screening of messages may add up to 300 ms latency on average.
• The stateful security solution is only applied on Gateway STP nodes.
• SFAPP UC3 and SS7 firewall SFLOG features cannot coexist on same node.
• Exist on same node. The following features are not compatible with SFAPP:
  • GSM MAP screening - SFAPP card does not support EGMS.
  • HLR Routing feature (GFLEX) on the same node. GFLEX interaction may be required for the ATI messages that need to be routed to the correct HLR for messages that do not have HLR address in the CdPA. This can be done by routing the message using the EAGLE mate using the C-Links.

For complete Use Case information, see the Stateful Applications User's Guide.

Hourly Status Message Report

The indicator INHAUDB has been added to the Condition Type field of the Hourly Status Message Report. This indicator shows that the user has manually turned off the alarms for this device. The date and time that the alarm for the device was turned off is displayed in the report. The report also includes the alarm status periodic reminder added to the end of the report to summarize the status of the alarms.

Output Example

    RLGHNCXA03W 97-06-07 15:00:00 EST Rel 22.0.0
    5023.0000 REPT COND CARD
    "CARD 1201:,MTCEINT-0,,97-06-07,14:58:24,,,,"
    "CARD 1202:0013,,SA,97-06-07,14:44:38,,,,**"
    "CARD 1203:0013,,SA,97-06-07,14:44:38,,,,**"
    "CARD 1204:0013,,SA,97-06-07,14:44:38,,,,**"
    "CARD 1206:0013,,SA,97-06-07,14:44:38,,,,**"
    "CARD 1207:0034,,NSA,97-06-07,14:52:56,,,,* "
    "CARD 1208:0013,,SA,97-06-07,14:44:38,,,,**"
    "CARD 1216:0013,INHAUDB,NSA,97-06-07,13:44:38,,,,"
    "CARD 1101:0034,MTCEINT-0,NSA,97-06-07,14:52:56,,,,* "
    "CARD 1115:0143,,NSA,97-06-07,14:57:52,,,,* "
;
    RLGHNCXA03W 97-06-07 15:00:02 EST Rel 22.0.0
    5034.0000 REPT COND ALARM STATUS
    “ALARMS:INHIBITED,0,17,8”
    “ALARMS:ACTIVE,2,0,0”
    “ALARMS:TOTAL,2,17,8”
    “ALARMS:STATUS,AUDIBLE,SILENT,SILENT”

The alarm status periodic reminder contains four fields, ALARMS:INHIBITED, ALARMS:ACTIVE, ALARMS:TOTAL, and ALARMS:STATUS.

The ALARMS:INHIBITED field shows the number of alarms of each type that have been turned off.

The ALARMS:ACTIVE field shows the number of alarms of each type that are active and not turned off.

The ALARMS:TOTAL field shows the total number of alarms of each type that the EAGLE has detected.

Following each of these fields are three numbers separated with commas. These numbers show the number of each alarm type the EAGLE has detected. The first number shows the number of critical alarms. The second number shows the number of major alarms. The third number shows the number of minor alarms.

The ALARMS:STATUS field shows whether the critical, major, and minor alarms are silent or audible.

In this example, the EAGLE has 17 major alarms and 8 minor alarms turned off, 2 critical alarms active for a total alarm count of 2 critical alarms, 17 major alarms, and 8 minor alarms. Only the critical alarms are audible.

Hardware Requirements

This release introduces a new DCM type family board called the Single Slot EDCM (SSEDCM). Just as the name implies, the SSEDCM card occupies only one slot in an EAGLE shelf, as opposed to the dual-slot DCM boards. The provisioning rules for a DCM type board allow provisioning of any slot where a DCM type board can physically be inserted.

Description

The SLAN on E5-ENET Assembly feature supports running the stplan application on the E5-ENET card.

The SLAN on E5-ENET Assembly feature allows the E5-ENET card to support the features currently implemented on the DCM card (SSEDCM, or EDCM-A assembly).

The E5-ENET card running the slanhc GPL and the stplan application is referred to as the E5-SLAN card.

HIPR cards must be installed in each shelf where E5-SLAN cards are installed. At least two cards running the stplan application must be provisioned in the EAGLE 5 ISS to provide “n+1” redundancy. A maximum of 32 STPLAN/E5-SLAN cards can be provisioned.

If a shelf contains HMUX cards, then E5-SLAN cards must be provisioned in shelves adjacent to that shelf. The optimum configuration is to provision half of the E5-SLAN cards in the previous shelf and half in the next shelf.

The SLAN on E5-ENET Assembly feature allows the link speed and duplex configuration to be set either automatically or manually. The auto parameter in the ent-dlk command can be set to yes to enable auto-negotiation, which configures speed and duplex for the link automatically. The duplex and speed parameters in the ent-dlk command can be used to set duplex and speed manually.

If auto-negotiation is enabled, the E5-SLAN card operates at 12,000 TVG grants per second when the IP port operates at 100 Mbps full duplex, and at 1200 TVG grants per second when the IP port operates at 10 Mbps full or half duplex, or 100 Mbps half duplex.

Thermal management and alarming provisions are provided for the E5-SLAN card.

Feature Control Requirements

None.

Hardware Requirements

The SLAN on E5-ENET Assembly feature has the following hardware requirements:

• HIPR cards must be installed at card locations 9 and 10 in the shelf where the E5-SLAN card is installed.
• Backplane cable adaptors

Limitations

• The -m, -p, and -h suboptions of the -d option for the netstat command are not supported for the E5-SLAN card.
• The E5-SLAN card does not preserve memory across boots. The application will not remain intact across card boots.
• The performance of the E5-SLAN card is limited by the data rate of the Ethernet port and the capability of the external LAN/WAN.

Limitations

1. This feature does not allow the EAGLE to MTP convert between National and National Spare Point Codes. Likewise, this feature does not allow the EAGLE to MTP convert between International and International Spare Point Codes.

2. In the destination table, an ITU-I alias and an ITU-I Spare alias cannot be defined for the same Point Code, likewise an ITU-N alias and an ITU-N Spare alias cannot be defined for the same point code

3. The feature is not supported on the SEAS interface. Spare point codes are only supported for ITU point codes, and SEAS only supports ANSI point codes. Any Private ANSI point code provisioned using the standard EAGLE command line interface is not displayed by the SEAS VFY- command.

4. ITU National and ITU National Spare Point Code are implemented as separate network domains that can co-exist within the same STP.

5. Spare point codes are not supported for IPGWI sockets using TALI protocols. The spare point code feature may not be enabled if any application sockets have been provisioned on IPGWI cards.

6. The existing implementation of Gateway Screening does not support Group Code (Duplicate Point Codes). Gateway Screening will also not support PPCs.

7. The Spare Point Code and PPC prefix value, s- and p- do not apply to domain type point codes for ANSI and ITU-N24.

8. ITU-N and ITU-N24 Point Codes cannot co-exist as SID Destination True Point Codes and therefore ITU-N Spare and ITU-N24 Point Codes cannot coexist as SID Destination True Point Codes.

9. A single STPOPTS value (cnvcgdi) will be used to control message handling for ITU-I and ITU-I Spare messages when the CgPA PC does not have a required alias

10. A single STPOPTS value (cnvcgdn) will be used to control message handling for ITU-N and ITU-N Spare messages when the CgPA PC does not have a required alias

11. The existing implementation of the SRVSEL command interface to the SRVSEL table does not provide a way to separate MSU traffic for different ITU National Group Code networks. Therefore no provision is made for the SRVSEL command to control the separation of ITU spare and non-spare traffic. The SRVSEL table applies to the EPAP based features G-FLEX, INP, G-PORT, SMS Prepaid, and IS-41 to GSM Migration. Likewise, no provision is made for the GTTSEL command interface to the GTTSEL table to allow separation of ITU spare and non-spare traffic for EGTT, VGTT and MGTT.

Hardware Requirements

The EDCM (single-slot) P/N 870-2372-01 Rev E is required for SUA RFC.

Limitations

• The version of SUA implemented in this release is NOT backward compatible with the SUA version currently available on EAGLE releases.

• Only the Connections Message transfer part of the SUA protocol is supported for class 0 and class 1 SCCP messages.

• Limited support for Routing Context - up to 4 Routing Contexts per ASP (SUA and M3UA).

• To remove a routing context from a routing key, the routing key must be deleted and re-entered.

Description

The STC on E5-ENET Assembly feature supports the use of the E5-ENET card as an STC card running the eroute application.

The STC on E5-ENET Assembly feature allows the E5-ENET card to support the functions currently implemented on the STC card (SSEDCM, DCM, or EDCM-A assembly) for the EAGLE 5 Integrated Monitoring Support feature.

The E5-ENET card running the erthc GPL and the eroute application is referred to as the E5-STC card.

Because the SSEDCM STC card and the E5-STC card are both provisioned with card type stc and the eroute application, the two cards can be “hot-swapped” without re-provisioning the card information in the system.

A minimum of two cards running the eroute application must be provisioned in the EAGLE 5 ISS to support the EAGLE 5 Integrated Monitoring Support feature (“n+1” to provide redundancy). A maximum of 32 STC/E5-STC cards can be provisioned.

HIPR cards must be installed in each shelf where E5-STC cards are installed.

If a shelf contains HMUX cards, then E5-STC cards must be provisioned in shelves adjacent to the shelf that contains the cards being monitored. The optimum configuration is to provision half of the E5-STC cards in the previous shelf and half in the next shelf.

If IP signalling links are being monitored, then only single-slot STC cards can be provisioned. HIPR cards must be used in the shelves where the IP links are located.

The E5-STC card operates at 12,000 TVG grants per second when the IP port operates at 100 Mbps full duplex, and at 1200 TVG grants per second when the IP port operates at 10 Mbps full or half duplex, or 100 Mbps half duplex. The E5-STC card is preconfigured to use auto-negotiation to set duplex and speed automatically.

Thermal management and alarming provisions are provided for the E5-STC card.

Feature Control Requirements

None.

Hardware Requirements

The STC on E5-ENET Assembly feature has the following hardware requirements:

• Two HIPR cards must be installed in the shelf where the E5-STC card is installed.
• Backplane cable adaptors

Limitations

The STC on E5-ENET Assembly feature has the following limitations:

• The suboptions {-m, -p, -h} of the -d option for the netstat command are not supported for E5-STC card.
• The E5-STC card does not preserve memory across card boots: therefore, the application does not remain intact across card boots.
• The performance of the E5-STC card is limited by the data rate of the Ethernet port and the capability of the external LAN/WAN.

Hardware Requirements

The DCM card currently takes up two slots in the EAGLE shelf card cage due to the large heat sink on the top of the DCM card. Because of this, the DCM cannot be provisioned in any arbitrary slot. Because certain slots in the card cage are adjacent to the cage sides, and/or are adjacent to metal supports welded into the card cage, these slots cannot be used to house a DCM card.

Also, the DCM card requires a substantial amount of power. Due to the way the EAGLE fuses power pairs of card slots, the DCM should always be provisioned into an odd-numbered card slot. For example, fuse 1A provides power to both slots 1101 and 1102. The combined current draw for both of these slots must not exceed 3A or the fuse may blow. Inserting a DCM into slot 1102 when there is another card in 1101 could cause the total current requirements for both of these slots to exceed 3A.

Additionally, the shelf equipped with the DCM card must be equipped with fans in order to keep the card from overheating.

Fan Assembly

The fan assembly is provided with the EOAP and is also a necessary item for the DCM.

Note that the airflow provided by the Fan Assembly is approximately 100 cubic feet per second.

Description

This feature allows the user to select either 10 Mbps or 100 Mbps for the data link speed of the Ethernet connection on the Single Slot Enhanced Database Communication Module (SSEDCM) STPLAN card.

Hardware Requirements

The VXWSLAN card is required for 100 Mbps data links.

Description

The SUA DAUD with SSN Support feature allows the EAGLE 5 ISS to update SCCP cards on the status of remote subsystems connected to the EAGLE 5 ISS and to use destination state audit (DAUD) messages that contain the ssn parameter to query the status of any subsystem.

The SUA DAUD with SSN Support feature enables to the EAGLE 5 ISS to perform the following functions:

• Update the SCCP cards with the status of remote subsystems to indicate whether the subsystems are allowed or prohibited
• Determine the status of any subsystem using destination audit (DAUD) messages that contain the ssn parameter.

When a node for a remote subsystem becomes available or unavailable, then the SUA DAUD with SSN Support feature allows the MAP table, maintained on the EAGLE 5 ISS SCCP cards, to be updated with the new status.

When a DAUD message containing an ssn parameter is sent over an SUA association to the EAGLE 5 ISS, Gateway Screening is performed by a card that contains the SS7IPGW, IPGWI, or IPGHC GPLs. The message is then sent to the SCCP card to query the availability status of the subsystem. The EAGLE 5 ISS sends one of the following responses based on the subsystem status:

• Status is available—Destination Available (DAVA) message
• Status is unavailable—Destination Unavailable (DUNA) message
• Status cannot be determined—Subsystem Status Unknown error message

Feature Control Requirements

None.

Hardware Requirements

None.

Limitations

Hardware Requirements

A T1200 Application Server

Description

The Support CHG-GTT to change the GTA feature enhances the chg-gtt and chg-gta commands to a GTT or EGTT range to be extended or reduced with a single command instead of deleting the original range and entering a new range.

For example, extending the range 5551234-5554567 to 5551234-5559999 can be performed in one command, using the chg-gtt or chg-gta command.

Likewise, reducing the range 5551234-5552999 to 5551234-5554567 can be performed in one command, using the chg-gtt or chg-gta command.

Hardware Requirements

The Support CHG-GTT to change the GTA feature has no hardware requirements.

Limitations

The Support CHG-GTT to Change the GTA feature has the following limitations:

• Range consolidation or 'self-healing' ranges, (5551234-5554567 and 5554668-5559999, for example) remain two entries. A user can delete 5554668-5559999, then enter chg-gtt for 5551234-5554567 to be changed to 5551234-5559999, but this action requires two commands.
• Overlapping ranges are rejected, (5551234-5554567 and 5557000-5559999, for example). The user cannot use chg-gta on the first entry such that the EGTA is greater than 5556999, because it would create overlapping GTT entries. The same applies for single GTT entries.

Description

The Support for 32 Prepaid SMS Intercept Platforms feature enhances the capability of the EAGLE 5 ISS to support routing from 3 to a maximum of 32 Intercept Platforms and increases the number of Prepaid Portability Types by the EPAP to 32 to specifically identify a subscriber with an SCP.

The Support for 32 Prepaid SMS Intercept Platforms feature increases the number of Prepaid Portability Type (PPT) subscribers and Intelligent Network (IN) SCP Point Code + Routing Indicator (PC + RI) translations that can be supported by the Prepaid SMS Intercept Phase 1 (PPSMS) feature to 32. Each translation corresponds to an IN platform and can be either ITU-N, ITU-I or a combination of the two.

Any subscriber that is not one of the 32 PPTs is considered to be a postpaid/contract subscriber.

The Support for 32 Prepaid SMS Intercept Platforms feature allows any Mobile Station Integrated Services Digital Number (MSISDN) in the RTDB to be associated with any of the 32 PPTs. Each PPT can then be associated with any of the IN platforms.

Loadsharing can be performed across 8 of the IN platforms, using the MAP and MRN tables. If the Transaction-Based Weighted GTT feature is turned on, then loadsharing can be performed across all 32 platforms.

If the Flexible GTT Loadsharing (FGTTLS) feature is turned on, then lookup in the MAP or MRN table is performed using the set ID (SETID) obtained from the PPSOPTS table. If the FGTTLS feature is turned off, then lookup is performed on only the default MAP or MRN set.

Feature Control Requirements

The Support for 32 Prepaid SMS Intercept Platforms feature is enabled when the PPSMS feature is enabled. The G-Port feature does not have to be enabled before enabling the PPSMS feature.

Hardware Requirements

None.

Limitations

None.

Description

The Support for 32 Prepaid SMS Intercepts feature increases the number of supported Prepaid SMS Intercepts from 8 to 32.

Supported GTT (Global Title Translation) destinations have been expanded to 32, and IN SCP (Intelligent Network Service Control Point) platforms and EPAP portability types have been expanded to 32 from 8.

The PPSMS (Pre-paid Short Message Service) Phase 1 feature uses a G-Port DN portability type (PT) field to identify the types of prepaid subscribers whose originated short messages (as part of SMS) need to be intercepted and forwarded to a corresponding intelligent network platform for verification.

In EPAP 9.0, the PPSMS Phase 2 feature expands the PT range to support 32 types of prepaid subscribers.

For PPSMS, the PT parameter on the ent_sub, upd_sub, and rtrv_sub commands identifies a DN as one of 32 types needing PPSMS intercept.

Hardware Requirements

None.

Limitations

None.

Description

The Support for 2000 ITU Links per Node feature increases the total capacity of an EAGLE 5 ISS node from 1500 to 2000 links.

This feature requires a Feature Access Key.

Hardware Requirements

The Support for 2000 ITU Links per Node feature has the following hardware requirements:

• HIPR cards installed on every provisioned shelf in the system

• The following link/card counts are supported:

  • Maximum 115 LIM-ATM cards

  • Maximum 100 IPLIM cards

  • Maximum 64 IPGWx cards

  • Maximum 64 SE-HSL links

Limitations

The Support for 2000 ITU Links per Node feature has the following limitations:

• This feature is supported for ITU links only. STP-LAN and ANSI links are not supported.

• The following cards are not supported for ITU configurations above 1500 links/node: MPL, MPL-T, LIM-ATM.

• The following cards are not supported for any configuration above 1500 links/node: LIM-DS0, LIM-OCU, LIM-V.35, LIM-AINF, LIM-ILA, LIM-EILA

Description

EAGLE Release 30.0 supports the feature content of IP⁷ Secure Gateway Release 8.0 (i.e. SCTP Checksum Update, M3UA Protocol Enhancements), as well as all IP⁷ content supported by EAGLE Release 29.x.

Auditing the EAGLE via High-Speed Audit

EAGLE Release 25.0 introduced a new feature, "Enhanced Bulk Download & Audit," which allows the LSMS to audit the subscription component of the EAGLE LNP DB at a very high speed, using an ethernet connection that directly connects the LSMS and EAGLE. This audit proceeds as follows:

1. LSMS tells EAGLE, via the ethernet connection, what range of subscriptions are to be returned. A starting and ending NPANXX is specified, and all subscriptions provisioned within that range are returned.

2. The BLM card on the EAGLE (which has a complete copy of the EAGLE LNP DB resident in its RAM memory) retrieves each subscription in the start/end range from its database, computes a checksum for the subscription, and returns the subscription's TN (i.e. its “key”) and computed checksum to the LSMS, again using the ethernet connection

3. LSMS computes a checksum for each of the requested subscriptions, and then compares them against the checksum returned by the EAGLE:

   • Matching checksums indicate that the subscription information on the EAGLE exactly matches the information on the LSMS.

   • Mismatching checksums indicate that the EAGLE has the subscription in its database, but that one or more attributes of the subscription (e.g. LRN) are different. The LSMS should update the subscription information in the EAGLE to bring the EAGLE into sync with the LSMS.

   • If the EAGLE does not return a TN/checksum pair for a subscription that the LSMS has, this indicates that the EAGLE is missing the subscription. The LSMS should add the subscription to the EAGLE database.

   • If the EAGLE returns a TN/checksum pair for a subscription that the LSMS does not have in its database, this indicates that the EAGLE still has a subscription that should have been deleted. The LSMS should delete the wayward subscription from the EAGLE's database.

The Support LSMS Audit Enhancements feature also allows auditing, via the high-speed ethernet link, of the EAGLE's database components:

• default GTT (NPANXX)

• override GTT (LRN)

• NPA split

The auditing of the default GTT, override GTT, and NPA split database entities takes place in a manner similar to that described above for subscriptions, i.e. LSMS will request checksums for a range of entities, and the EAGLE returns the information (DB entity key/checksum) via the high-speed ethernet connection.

Component Interaction Scenario

As mentioned, the new auditing and provisioning capabilities that these features provide can take place over either the OAP serial channel, or over the high-speed IP channel. The following scenarios describe the sequence of events that occur over each.

New Audit Capabilities via OAP Serial Channel

In the following list, the item numbers correspond to the circled numbers in Figure 5-27.

1. The user at the LSMS terminal decides to audit something via the serial OAP connection: override GTT, default GTT, Split NPA, subscriptions, etc. The user enters auditing parameters (e.g. start/end range, etc.) at LSMS GUI screen.

2. The LSMS sends a request to the OAP requesting the first DB entity to be retrieved for audit. The OAP converts this request into a "SEAS-like" command (e.g., vfy-lnp-6ddt).

3. A SEAS-like retrieval command is forwarded to the EAGLE.

4. The EAGLE retrieves the requested DB entity from the active OAM fixed disk and formats the data into a response using "SEAS-like" syntax.

5. A “SEAS-like” response is sent to the OAP in ASCII format

6. The OAP converts and transmits the ASCII response into a format suitable for the LSMS.

7. The LSMS compares the EAGLE DB entity against its own database, and displays discrepancy information to the user at the LSMS console.

This retrieve/compare/display cycle repeats until all DB entities have been audited, or until the LSMS user cancels the audit.

Should the LSMS user elect to reconcile the problem(s) detected by the audit, the reconcile commands (e.g. upd-split-npa, etc) are sent to the EAGLE using the same OAP serial connection. If the EAGLE database was severely out of sync, the LSMS operator can elect to reconcile the problem using the Enhanced Bulk Download feature.

Note that the LSMS operator has a choice as to how any DB updates are sent to the EAGLE: the LSMS operator can choose to send them either via the serial connection (makes sense if the number of commands to be sent is small), or via the high-speed IP connection (makes sense if the number of commands is very large).

Figure 5-27 LSMS Auditing/Split Provisioning: Sequence of Events

New Audit Capabilities via High-Speed IP Channel

The items in the following lettered list correspond to the circled letters in Figure 5-27:

1. The user at the LSMS terminal decides to audit something via the high-speed LSMS↔EAGLE IP connection: override GTT, default GTT, Split NPA, subscriptions, etc. The user enters auditing parameters (e.g. start/end range, etc.) at LSMS GUI screen.

2. The LSMS sends a request to EAGLE's DCM card (running EBDADCM GPL) via the IP connection, which is forwarded across IMT to EAGLE's BLM card (running EBDABLM GPL).

3. The BLM card retrieves requested DB entities (e.g. Override GTT entries), generates a CRC-32 checksum for each entity, and returns the entity key (e.g. for Override GTT entity, the key would be the LRN) and its corresponding checksum to the DCM, which is then forwarded to the LSMS via the high-speed IP connection.

4. The LSMS retrieves the corresponding DB entity from its own database, computes the CRC-32 checksum, then compares the checksum against what the EAGLE has provided. Any mismatching of the checksums indicates that what the EAGLE has for this entity is different than what the LSMS has. Furthermore, the DB entity keys that are returned from the EAGLE allow the LSMS to detect superfluous entries in, and entries that are missing from, the EAGLE LNP DB. All discrepancies are displayed to the LSMS operator.

This retrieve/checksum/compare/display cycle repeats until all DB entities have been audited, or until the LSMS user cancels the audit.

Should the LSMS user elect to reconcile the problem(s) detected by the audit, the reconcile commands (e.g. upd-split-npa, etc.) would likely be sent to the EAGLE using the OAP serial connection. If the EAGLE database was severely out of sync, the LSMS operator could elect to reconcile the problem using the Enhanced Bulk Download feature.

Limitations

The new verify (vfy-xxxxx) commands mentioned above do not support the retrieval of ranges of database entries. Instead, each command accepts the key of a single database entity to be retrieved. The command output shows the details of the single database entity that was specified, assuming that the entity exists, or error information (if it doesn't).

Over OAP Serial Channel

This feature implements a set of commands that allow the LSMS to provision and query NPA split information at the EAGLE, using the connection that exists between the EAGLE↔LSMS provided by the OAP. These new commands are:

• upd-split-npa

• dlt-split-npa

• vfy-split-npa

See the Commands Manual for more information on these commands.

Via Enhanced Bulk Download

This feature supports downloading of NPA split information to the EAGLE as part of a high-speed bulk download. This existing high-speed bulk download facility has been expanded to allow NPA split information to be downloaded.

Limitations

The new verify (vfy-xxxxx) command mentioned above does not support the retrieval of ranges of database entries. Instead, each command accepts the key of a single database entity to be retrieved. The command output shows the details of the single database entity that was specified, assuming that the entity exists, or error information (if it doesn't).