5 Features P - Z

This chapter describes features starting with letters from P to Z.

5.1 Password Aging (Release 21.0)

When a password is changed, either by the user or by a systems administrator, the date that the change took place is entered in the database along with the updated password.

During the login process, after the system has verified that the user has correctly entered the password, the system uses the date the password was changed to compute the number of days that have elapsed since the password was last changed. The password's age is compared against the value of the page parameter (maximum password age) of either the ent-user, chg-user, or chg-secu-dflt commands. If the password's age is greater than the value of the page parameter, then a password expired message appears in the command area. The user is prompted to enter and verify a new password. If the new password is acceptable, it is entered in the database along with the date that the change took place (the current date as shown by the EAGLE time-of-day clock).

The maximum age of a specific password (page) can only be specified with the ent-user command or the chg-user command. If the page parameter is not specified with the ent-user command, then the password’s age is taken from the system default value. The system default value for the password’s age is set with the page parameter in the chg-secu-dflt command. If the page parameter is not specified with the chg-user command, then the existing value for the password’s age does not change.

The system administrator can set a password's maximum age to 0. This indicates that the password aging is not applied to the password and the password remains valid regardless of how many days have elapsed since it was last changed.

When the user attempts to login with a password that is older than its maximum allowable age, the following message is displayed in the command area after the password has been validated and before the login session is established:


Enter new password (password has expired and must be changed) :

The user is then prompted to enter and verify a new password. If the password is acceptable, the user is logged on. Otherwise, one of the invalid password error messages is displayed (see Password Requirements (Release 21.0)) and access to EAGLE is denied.

5.2 Password Encryption (Release 21.0)

To prevent passwords from being disclosed, in Release 21.0, the passwords are stored on the system in an encrypted form. The encryption algorithm that is used is a one-way encryption algorithm, meaning once the passwords are encrypted using the algorithm, the passwords cannot be decoded. Also, any passwords temporarily stored in memory are overwritten with null characters as soon as they are no longer needed.

5.3 Password Requirements (Release 21.0)

Currently, the only requirement for a password used in the EAGLE is that the password must contain from five to eight alphanumeric characters

In Release 21.0, the rules for passwords have changed to meet Bellcore password requirements. The requirements for passwords can now be configured in the database with the chg-secu-dflt command. Passwords on the EAGLE can contain a maximum of 12 characters.

Refer to the Commands Manual for current information on commands.

5.4 PCS 1900 LNP Query (Release 26.0)

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

5.5 PDBA Proxy (EPAP 7.0)

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.

5.6 Performance Enhancements (IP7 Release 3.0)

The Performance Enhancements feature provides a set of rules for specifying DCM throughput under different configurations. This feature touches on a wide variety of IP7 Secure Gateway system and application issues.

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.

5.7 Per-Linkset Random SLS (Release 36.0)

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.

5.8 Persistent Device States (Release 29.0)

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.

Note:

The default value for this option remains OFF.

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.

5.9 Point Code and CIC Translation (Release 43.0)

The Point Code and CIC Translation (PCT) feature allows the EAGLE 5 ISS to change the destination point code (DPC) or originating point code (OPC) of an MTP-routed MSU to previously configured values. This functionality allows external networks to continue using the old point codes by emulating and mapping them to the new real point codes within the networks. The feature can also be used to change the circuit identifier code (CIC) of the MSU.

Note:

ITUN24 point codes, spare point codes, and private point codes are not supported by PCT translations.

A new PCT table is used to define translations between real and emulated point codes.

Network nodes can send and receive traffic to and from the emulated point code (EPC) without 'knowing' the real point code (Real PC) that is being emulated by the EPC. This ability allows the Real PC to be changed transparently from the rest of the network, which can continue using the EPC to route traffic.

If PCT is configured, either system wide or for the incoming linkset, then a DPC lookup is performed on the incoming MSU. If a translation is found during the DPC lookup, then the DPC of the MSU is replaced by the Real PC as the MSU is received by the EAGLE 5 ISS. If a Real CIC was provisioned in the translation, then the CIC of the MSU is changed to the value from the Real CIC range.

If the MSU was not modified by the DPC lookup, then an OPC lookup is performed on the outgoing MSU. If a translation is found during the OPC lookup, then the OPC of the MSU is replaced by the EPC of the matching translation as the MSU leaves the EAGLE 5 ISS. If an Emulated CIC was provisioned in the translation, then the CIC of the MSU is changed to the value from the Emulated CIC range.

Features and functionalities in the EAGLE 5 ISS use the real point code in provisioning.

The PCT feature is a quantity feature. The quantity is used to define the maximum number of allowed translations.

5.9.1 Feature Control Requirements

  • FAK for the Part Number of the desired quantity feature:
    • 893-0372-01—25 translations
    • 893-0372-02—50 translations
    • 893-0372-03—75 translations
    • 893-0372-04—100 translations
    • 893-0372-05—150 translations
    • 893-0372-06—200 translations
    • 893-0372-07—250 translations
    • 893-0372-08—1000 translations
  • After a PCT feature has been enabled, a PCT feature with a lower quantity cannot be enabled.
  • A temporary FAK cannot be used to enable the feature.

5.9.2 Hardware Requirements

The pct pass command is not supported on E1/T1 MIM, E1-ATM, LIM-ATM, and MPL cards.

5.9.3 Limitations

All Network Management may not work fully due to the overlap of CIC across multiple point codes.

5.10 Point-to-Point Connectivity for ITU Point Codes (IP7 Release 2.2)

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 IP7 Secure Gateway to use the ANSI/ITU Gateway feature for IP networks as well. Using these features enables IP7 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 IP7 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 IP7 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

    img/c_point_to_point_connectivity_for_itu_point_codes_ip7_release_2_2_prf-fig1.jpg

    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:
    1. 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.

    2. 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 IP7 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 IP7 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 IP7 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 IP7 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.

5.11 Portability Check for Mobile Originated SMS (Release 29.1)

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

img/c_portability_check_for_mobile_originated_sms_release_29_1_prf-fig1.jpg

Hardware Requirements

No new hardware is needed to support this feature.

5.12 Pre-LNP Query Service GTT processing (Release 43.0)

The Pre-LNP Query Service GTT processing feature allows Global Title Translation (GTT) to be performed on messages before the messages are processed by the LNP local subsystem.

GTT is used to determine whether the originator of the query has an agreement with the LNP service provider to perform LNP database lookup. If an agreement exists, then LNP service processing is performed and an appropriate response is sent to the originator. If an agreement does not exist, then the query is routed as per the GTT result.

This functionality is available for LNP Query Services (AIN, IN, LRNQT, LNPQS, PCS, and WNP).

5.12.1 Feature Control Requirements

The EGTT feature must be turned on before the Pre-LNP Query Service GTT processing functionality can be provisioned.

5.12.2 Hardware Requirements

The Pre-LNP Query Service GTT processing functionality requires an E5-SM4G or higher card.

5.13 Prepaid IDP Query Relay Enhanced

The Prepaid IDP Query Relay feature has been enhanced to support the route on SSN message with GTI=0 for true point code as well as MTP routed messages. For messages with GTI=0, CSL screening has been done on OPC/DPC instead of the screening based on CDPA GTA. A new list type OPCDPC has been defined in the CSL table. The OPC/DPC parameters are supported in the CSL commands (ent/dlt-csl) for new list type OPCDPC for the IDP Relay feature.

The dlt/ent/rtrv-csl and the dlt/ent/rtrv-srvsel commands were updated to support this enhancement.

See Prepaid IDP Query Relay Feature in IDP-Related Features User's Guide for more information.

5.14 Prepaid IDP Query Relay (IDP Relay) Service Portability (Release 41.1)

Service Portability support for the IDP Relay feature allows the CDPNNP Service Action to recognize own network IS41 and GSM subscribers. When Service Portability is applicable, the GRN digits can be used during execution of the Formatting Actions for the NPP rule.

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.

5.15 Prepaid Initial Detection Point Query Relay (Release 34.1)

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.

Table 5-3 IDP Relay Number Conditioning

Incoming Address Number Conditioning Outgoing Address
TCAP DN NAI Perform SCCP CGPA DEFCC Check? TCAP DN Format NAI Format

International

No

<CC><DN>

None

Do RTDB Lookup

If PFX3=unknown

NAI=unknown

Else

NAI=International

<PFX1><CC><RN><DN>

National

If PFX4=On

<DN>

Add DEFCC

Do RTDB Lookup

If PFX3-unknown

NAI-unknown

Else

NAI=National

<PFX2><RN><DN>

Unknown

No

<IEC><CC> <DN>

CSL Delete prefix found,

(P1=International),

remove it

Do RTCB Lookup

NAI=unknown

<IEC><CC><RN><DN>

Unknown

If PFX4=On

<NEC><DN>

CSL delete prefix found,

(P1=International),

remove it

Do RTCB Lookup

NAI=unknown

<NEC><RN><DN>

Unknown

If PFX4=On

<DN>

No CSL delete prefx found,

ADD DEFCC

Do RTDB Lookup

NAI=unknown

<RN><DN>

Note:

See the Glossary for a list of terms and acronyms used throughout this document.

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.

Table 5-4 Summary of CSL Supported Features

Feature Name Screening List Name Card Type Parameter Maximum Number of Entries Range of Values

Prepaid IDP Query Relay

GT

DSM

DS

50

1 to 15 digits

[0-9, a-f, A-F]

or none

Prepaid IDP Query Relay

CCNDC

DSM

DS

20

1 to 6 digits

[0-9, a-f, A-F] or none

Prepaid IDP Query Relay

SKBCSM

DSM

DS

25

4 digits [0-9, a-f, A-F] or none

Prepaid IDP Query Relay

DELPFX

DSM

DS

10

1 to 5 digits [0-9, a-f, A-F] or none

Prepaid IDP Query Relay

DELPFX

DSM

P1 (National / International)

10

1 digit [0-1], where:

0:= National ,

1:= International

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.

5.16 Prepaid SMS Intercept - Phase 1 (Release 28.1)

Mobile operators offering prepaid short message service (SMS) need an efficient way to perform credit checks on the subscriber sending the message, prior to allowing the message to be delivered. Intelligent network (IN) databases are generally used to perform the actual credit check. However, these databases can become overloaded if messages are sent to them for evaluation unnecessarily. An example of such a case is when all short messages, including those from or to contract (postpaid) subscribers, are sent to the IN platform for evaluation. The messages from contract subscribers do not need a credit check; thus this is additional traffic the IN platform must process unnecessarily.

Therefore, additional filtering and screening is needed in the SS7 network to provide a finer granularity in determining which messages actually need to be sent to the IN platform, and which may simply be routed to the SMSC.

The Prepaid SMS Intercept - Phase 1 feature screens incoming messages from MSC based on MAP operation code. If the op-code indicates the message is a MAP_MO_FORWARD_SHORT_MESSAGE (MO_FSM), the sender's MSISDN is retrieved and a database lookup performed. If the MSISDN belongs to a contract subscriber, the message will be routed to the SMSC. If the MSISDN belongs to a prepaid subscriber, the message will be diverted to a third-party IN platform for a credit check before allowing the message to be delivered to the SMSC.

The MAP_FORWARD_SHORT_MESSAGE, referred to as FSM in this document, is a message used to carry a text message (i.e. the "short message") being transmitted from the mobile handset of one subscriber to the mobile handset of another subscriber. In practice, the short message is delivered first to the Short Message Service Center (SMSC) of the sending subscriber. The SMSC is then responsible for sending the short message to the intended recipient. In MAP versions 1 and 2, the FSM message is used for both legs of the delivery. In MAP version 3, a MO_FSM (mobile originated) message is used to deliver the message from the sender to the SMSC, and a MT_FSM (mobile terminated) message is used to deliver the message from the SMSC to the recipient.

Refer to the Feature Manual - G-Port for current details on this feature.

Hardware Requirements

No new hardware is needed to support this feature.

5.17 Prevention of Congestion from Rerouted Traffic (Release 21.0)

When the status of the route is changed to allowed (when the route was restricted) or restricted (when the route was prohibited), a burst of rerouted traffic can occur on that route, thus congesting the route. To help keep this from happening, the EAGLE in Release 21.0 can control the rate that it broadcasts TFR and TFA messages to adjacent signaling points. This can regulate the amount of traffic the adjacent signaling points can send to the EAGLE when the route becomes allowed or restricted.

The rate that the EAGLE sends the TFR and TFA messages, (the pacing rate), can be configured with the tfatfrpr parameter of the chg-stpopts command. The value of the tfatfrpr parameter is from 0 to 1 second and can be set in 0.1 second intervals. The default value for the tfatfrpr parameter is 1 second. A value of 0 for the tfatfrpr parameter indicates that the pacing should stop. The pacing of TFR/TCR is stopped and all remaining TFR/TCR are broadcast at once if the current alternate route used to route traffic to the affected point code is in danger of congestion.

The TFA/TCA and TFR/TCR for each affected point code are sent in groups of 20%. For each time period defined by the pacing rate, 20% of the messages that are to be sent to the adjacent signaling points are broadcast to those signaling points.

This feature is applicable only for ANSI signaling links. The pacing is not done towards ITU networks.

If the destination becomes inaccessible or accessible before all of the TFR/TCR messages are broadcast, then the remaining TFR/TCR messages are not sent.

TFA/TFC messages for multiple affected destinations are sent in parallel.

The pacing of TFR/TCR messages is stopped and all remaining TFR/TCR messages are broadcast at once if the current alternate route used to route traffic to the affected point code is in danger of congestion.

The broadcast of TFA/TFR messages sent about X.25 pseudo point codes is controlled by this feature.

5.18 Prevention of Link Oscillation (Release 21.0)

A variety of network problems can cause signaling links to oscillate in and out of service causing frequent changeovers and changebacks and excessive network management message generation. If many links simultaneously oscillate, congestion can occur. When the EAGLE begins restoring an out of service signaling link, the EAGLE starts the level 3 T32. If the signaling link fails again before the level 3 T32 expires, the EAGLE does not attempt to bring the signaling link into service until the level 3 T32 timer expires. When the level 3 T32 timer expires, the EAGLE attempts to restore the signaling link into service.

The value of the level 3 T32 timer is set with the chg-l3t command. The range of values for the level 3 T32 timer is from 60 seconds to 120 seconds. The default value for the level 3 T32 timer is 60 seconds.

The link alignment procedures are not delayed under the following conditions:

  1. When a signaling link is manually taken out of service using the dact-slk command, the level 3 T32 timer is stopped (if it is running).

  2. When the signaling link is brought back into service using the act-slk command.

  3. When a new signaling link is first aligned.

The level 3 T32 timer can only be assigned to ANSI SS7 linksets and signaling links.

5.19 Preventive Cyclic Retransmission (PCR) (Release 20.0)

Preventive cyclic retransmission is one of the two forms of error correction for the SS7 protocol. Basic error correction is the other. Preventive cyclic retransmission is a forward error correction scheme that uses positive acknowledgments to support the forward error correction. Negative acknowledgments are not used for retransmission. PCR is used when the one-way delay on a link is greater than or equal to 15 milliseconds. A typical example is a satellite link.

Each message signal unit transmitted is retained at the transmitting end of the signaling link. Copies of that MSU are transmitted to the receiving end of the signaling link until the transmitting end of the signaling link receives a positive acknowledgment from the receiving end that it has received a good MSU. When the transmitting end of the signaling link has received the positive acknowledgment, the MSU it has retained is discarded.

The PCR feature should be used in the following circumstances:

  • When the one-way propagation delay on a signaling link is greater than or equal to 15 milliseconds.

  • When the signaling links are established via satellite.

The PCR feature has two modes of operation, normal retransmission and forced retransmission.

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

img/c_preventive_cyclic_retransmission_pcr_release_20_0_prf-fig1.jpg

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.

img/c_preventive_cyclic_retransmission_pcr_release_20_0_prf-eqn1.jpg

Figure 5-4 Basic Error Correction vs. PCR

img/c_preventive_cyclic_retransmission_pcr_release_20_0_prf-fig2.jpg

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, N1, and the number of message signal unit octets available for retransmission, N2.

If the N1 or N2 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.

Note:

All MSUs are sent even if acknowledgments are received during forced retransmission. After all MSUs have been retransmitted, acknowledgments, if any, are processed, and the N1 and N2 thresholds are re-evaluated.

If both the N1 and N2 values are below the their respective thresholds, the normal PCR procedure can be resumed.

However, if the N1 or N2 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 N1 threshold is 3, and N2 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

img/c_preventive_cyclic_retransmission_pcr_release_20_0_prf-fig3.jpg

At this point, the threshold for unacknowledged MSUs in the retransmission buffer, N1 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

img/c_preventive_cyclic_retransmission_pcr_release_20_0_prf-fig4.jpg

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, N1 and N2 are re-evaluated. In this case, acknowledgments for MSUs 1 and 2 have been received; thus, N1 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

img/c_preventive_cyclic_retransmission_pcr_release_20_0_prf-fig5.jpg

Derivations for N1 and N2

The user is responsible for setting the values for N1 and N2. The following rules serve as a guide for determining these thresholds.

  • N1 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.

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

  • TL 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 (TL)

    img/c_preventive_cyclic_retransmission_pcr_release_20_0_prf-fig6.jpg

Assume that TL = 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.

  • Teb is the emission time of one octet

  • Default value for N1 = 76 outstanding MSUS

  • Default value for N2 = 3800 octets

Table 5-5 Limitations for Various Line Speeds

Channel Speed Teb = 1 octet / channel speed (TL / Teb ) + 1 rounded to nearest hundred, TL = .480 seconds

64 Kbps

1.25 x 10 -4 seconds

~3800 octets

56 Kbps

1.43 x 10 -4 seconds

~3400 octets

38.4 Kbps

2.08 x 10 -4 seconds

~2300 octets

19.2 Kbps

4.17 x 10 -4 seconds

~1200 octets

9.6 Kbps

8.33 x 10 -4 seconds

~600 octets

4.8 Kbps

1.67 x 10 -3 seconds

~300 octets

2.4 Kbps

3.33 x 10 -3 seconds

~100 octets

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

Default N1 calculation:

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

Default N2 calculation:

N2 = TL/Teb +1 = 3800 octets from table above for 64Kbps signaling link.

5.20 Priority Processing of Network Management Messages (Release 21.0)

Some of the new protocol features like cluster routing and diversity management have increased the processing complexity of network management functions. Under large failure conditions, it is possible that too many network management functions need to be performed, causing an application processor overload. In the releases prior to release 21.0, if such a condition was encountered, the EAGLE discarded the network management messages regardless of what kind of network management message they were. This method of handling network management messages may have an impact on the network’s recovering capability under large scale failure conditions when several critical network management functions must be performed.

This feature provides the capability to prioritize the network management functions to make sure that critical network management functions receive high processing priority under such overload conditions.

During normal operation, the network management functions are processed with equal priority, but the EAGLE closely monitors for excessive unexpected events which may result in an application processor overload. The prioritizing of network management functions is triggered when the application processor overload is experienced on any LIM.

For this feature, the EAGLE collects one measurement, Network Management Messages Discarded due to Network Management Overloading. This measurement collects the number of network management messages discarded when the network management processor overload condition has been reached. Measurements are collected for discarded network management messages at each priority level. This measurement is collected for each signaling link in the system.

The EAGLE generates the following UAMs:

UAMs

  • UAM 304 - Network Management Task Priority Discard Threshold Reached (REPT-NMTSK-DSCD) — a minor alarm generated when a network management message is discarded because the application processor of a LIM is overloaded.

  • UAM 305 - Recovery from Network Management Task Priority Discard Processing (RECVY-NMTSK-DSCD) — generated when the network management overload condition is cleared.

This feature is applicable only for the ANSI network. Network Management events triggered due to change in status of ITU network elements (links, routes, linksets, destination) are processed on first come first served basis.

5.21 Private Point Code (Releases 31.12, 34.0)

Private point codes (PPCs) are used for internal routing within the EAGLE. PPCs may be used for "internal point codes" which are used for the End Office feature, and adjacent point codes for IPGWx linksets. The principle difference between private point codes and non-private is whether the point code is known outside the EAGLE. Point codes within the EAGLE are useful for routing messages within the EAGLE, but when these point codes are non-private, they consume a point code value in the network. By making these point codes private, it is possible to have a point code value indicated as private and still have the same point code value (as not private) available for network configuration.

PPCs must be supported in every supported domain. ANSI, ITU-I, ITU-N, ITUI-Spare, ITUN-Spare, ITUN24 must all support a private version of a point code.

PPCs will be allowed for IPGWx APCs (adjacent point codes). Currently there are special rules for provisioning IPGWx APCs. A special parameter IPGWAPC=YES on the ent-dstn and ent-ls commands allows point codes with otherwise invalid ranges (e.g., ANSI point code 0-0-1) to be used. This parameter also identifies the linkset as one that may only contain IPGWx links. With the implementation of this feature, PPCs will also be allowed for this purpose. The IPGWAPC parameter will remain, however, since not all PPCs are IPGWx APCs.

PPCs will also be allowed for SAPCs on IPGWx linksets. Like IPGWx APCs, SAPCs on IPGWx linksets are not "real" point code, and the network beyond the EAGLE does not need to be aware of them.

PPCs will also be allowed used for the provisioning the End Office feature. In order to support this, PPCs must be allowed for the Remote Application (RMT-APPL) table, and GTT table, in addition to the Destination and Route tables.

Existing Internal Point Codes and IPGW linkset adjacent point codes will not be modified during upgrade. After upgrade, both private and non-private point codes can be used for these purposes.

Note that static routing keys are never needed for RMT-APPL point codes or IPGWx adjacent point codes. For the End Office feature, a true or secondary point code routing key is needed, while for IPGWs adjacent point codes, no routing key is needed.

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.

5.22 Prohibit Removing the Last Route to a Destination if that Destination is being Referenced by Mated Applications or Concerned Signaling Point Code Groups (Release 22.0)

In previous releases when a route was being removed from the database, the EAGLE checked to make sure other routes to the DPC were defined if the DPC of the route was being used by a global title translation. When this condition was detected, the EAGLE issued a message warning that the condition was present, but allowed the route to be removed from the database.

In release 22.0, a new rule has been added to the EAGLE’s dlt-rte command and the SEASDLT-RTE command function that does not allow the specified route to be removed from the database if this condition is present. If the user attempts to remove a route under this condition, the command is rejected. On an EAGLE terminal, this error message is displayed.


2356 Cmd Rej: Destination referenced by GTT cannot be delete

5.23 Prohibit the Assigning of a Linkset with Linkset Types A or E to a Cluster Route (Release 22.0)

In previous releases, a user could assign a cluster route to a linkset with a linkset type of either A, B, C, D, or E from both the EAGLE terminal and the SEAS interface. In release 22.0, the only linkset types that can be assigned to a cluster route are B, C, or D. The EAGLE’s ent-rte command and SEAS ASGN-RTE command function have been changed to allow only these linkset types to be assigned to cluster routes. If the user attempts to assign a cluster route to a linkset with a linkset type of either A or E, the command is rejected. On an EAGLE terminal, the following error message is displayed.


E2349 Cmd Rej: Link Set Type invalid for Cluster Destination

5.24 Provide 2 HSL and 64 LSL on SLIC (Release 46.5)

This feature provides two (2) High-Speed Links (HSL) and 64 Low-Speed Links (LSL) on the card in order to support TDM links and increase card efficiency. This feature allows SLIC to replace the HC-MIM (same capacity in one card slot instead of two card slots) or to replace the E5-E1T1 (doubles the capacity).

Note:

Channel bridging is not supported on SLIC cards. Channel bridging for the location (if any) should be removed by the operator before hot swapping an HCMIM with a SLIC card.

5.24.1 Hardware

There are sixteen (16) LEDs, two for each E1/T1 port used to indicate port and channel (signaling link) status. One LED per E1/T1 port indicates the E1/T1 port status, and one LED per E1/T1 port indicates the aggregated channel status.

Table 5-6 HCMIM and SLIC-E1T1 LED Configuration

E1/T1 port Status LED Aggregated Channel Status LED
Green (No alarms, port has acquired timing and framing synchronization) Green (if all channels provisioned =ISNR)
Amber (Remote alarm condition) Amber (indicates port is the "reflected" port in Channel Bridging mode of operation. Applies only to "even" numbered ports)
Amber blinking (Loss of Frame Synchronization) Amber blinking (if any channels provisioned = OOS)
Red blinking (all other alarms) Red blinking (if all channels provisioned = OOS)
Red (Port not provisioned) Red (if no channels are provisioned)

5.25 Provisioning Database Interface (PDBI) Command Statistics (EPAP 13.0)

The PDBI Command Statistics feature provides the ability to monitor EPAP provisioning performance using reports. These reports are stated in commands per second. Reported statistics include information on provisioning patterns, degradation of performance, and performance impact due to various activities (maintenance related or not).

This feature generates reports for a period of time containing at least the following information:
  • Average number of PDBI connections for the reported period
  • Peak number of PDBI connections for the reported period
  • Average system PDBI commands per second (CPS) for the reported period
  • Peak system PDBI commands per second (CPS) for the reported period (calculated per second)
  • Percentage of commands with a return code of zero that successfully updated the database for the reported period (ent/upd/dlt commands only).
Statistics related to numbers of PDBI connections are based on the number of PDBI connections at one time.

These reports is accessible via Command Line Interface (CLI) and GUI. PDBI statistics are kept for a specific period called the retention period. During the retention period, reports can be generated on-demand.

Report intervals:
  • 5 minutes interval
  • 1 hour interval
  • 1 day interval - When the daily PSR type is generated, the statistical data for a 24 hour period is displayed in the report. Only daily boundary timings are considered for this purpose.
For this feature to work in the event of a PDBA Switchover, the feature must be ON for both PDBA systems (Active PDBA and Standby PDBA).

On T1200 AS, the PDBI Command Statistics Feature is ON by default. On T1000 AS, the PDBI Command Statistics Feature is OFF by default.

User Interface (EPAP GUI)

The EPAP GUI shall provide the following two new menu options for this feature:
  1. PDBA --> List PDBI Connections
  2. PDBA--> PDBI Statistics Report

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.

Note:

The Peak CPS reported in both the GUI PDBI Statistics Report and List PDBI Connections menus is not sustainable. It is provided for information purposes only. Customers should not expect to get this rate on a regular basis for any sustained period of time.

5.26 Provisioning Range for Gateway Screening (Release 22.0)

The values for certain parameters used to configure gateway screening can be entered as a range of values. Allowing a range of values for these parameters reduces the number of entries in the gateway screening tables required to support a particular configuration. The parameters whose values can be entered as a range of values are:

Parameters

  • ni - the network identifier for an ANSI point code

  • nc - the network cluster for an ANSI point code

  • ncm - the network cluster member for an ANSI point code

  • pri - the message priority in the SIO field of an MSU

  • h0 - the H0 heading code in the SIF field of an MSU

  • h1 - the H1 heading code in the SIF field of an MSU

  • type - the translation type in the called party address field of an MSU

A range of values for these parameters can be specified for gateway screening commands entered on an EAGLE terminal or on the SEAS interface.

The range of values for a parameter is specified by the two values defining the range separated by two ampersands, &&. The value to the left of the ampersands must be less than the value to the right of the ampersands , for example, :ni=002&&100. In this example, the value of the ni parameter is all values from 002 to 100, including the values 002 and 100.

A range of values for an ANSI point code parameter can be specified with wildcards (*) or single values for other point code parameters. Table 5-7 shows the valid combinations of these parameter values.

Table 5-7 Valid Value Combinations for ANSI Point Code Parameters

NI NC NCM

Single Value

Single Value

Single Value

Single Value

Single Value

Range of Values

Single Value

Single Value

Wildcard

Single Value

Range of Values

Wildcard

Single Value

Wildcard

Wildcard

Range of Values

Wildcard

Wildcard

Wildcard

Wildcard

Wildcard

A range of values for the H0 and H1 heading codes can be specified with wildcards (*) or single values for other heading code parameter. Table 5-8 shows the valid combinations of these parameter values.

Table 5-8 Valid Value Combinations for H0 and H1 Parameters

H0 H1

Single Value

Single Value

Single Value

Range of Values

Single Value

Wildcard

Range of Values

Wildcard

Wildcard

Wildcard

When changing or removing an existing gateway screening entry, the ANSI point code values, priority values, H0 and H1 heading code values, or translation type values specified with the command must match the values configured in the database for the specified screening reference. If the specified parameter value in a specific screening reference is part of a range of values for that parameter already configured for that screening reference, the command is rejected.

For example, the database contains a gateway screening entry for the range of allowed OPCs 010-010-010 to 010-010-100 in Allowed OPC screening reference opc1. If an attempt is made to remove or change Allowed OPC screening reference opc1 and the ANSI point code 010-010-025 is specified, the command is rejected because point code 010-010-025 is a part of the point code range configured in the database. To remove or change Allowed OPC screening reference opc1, these point code parameters must be specified with the command, ni=010, nc=010, ncm=010&&100.

If the ANSI point code, priority value, H0 and H1 heading code values, or translation type values specified with an enter command is within the range of values already configured for the specified screening reference, the command is rejected. For example, the ent-scr-opc command is entered with the point code 010-010-050 assigned to screening reference opc1. If the database contains the range of point codes 010-010-010 to 010-010-100, specified as ni=010, nc=010, ncm=010&&100, the command is rejected. If the database contains an entry for all point codes with the network identifier of 010 and network cluster of 010, ni=010, nc=010, ncm=*, the command is rejected.

A range of values can be specified when displaying gateway screening entries. The range of values does not have to match the values configured in the database. The range of values specified with a retrieve command is used to limit the number of entries to search for. There are some restrictions for using ANSI point code values with retrieve commands. Table 5-9 shows the valid combinations of the ANSI point code parameters.

Table 5-9 Valid Parameter Combinations for ANSI Point Code Parameters

NI NC NCM

Single value

Single value

Single value, a range of values, a wildcard, or NCM value not specified

Single value

A range of values, a wildcard, or the NC value is not specified

the NCM value is not specified

A range of NI values, a wildcard, or the NI value is not specified

the NC value is not specified

the NCM value is not specified

5.27 Proxy Point Code (Release 37.5)

The Proxy Point Code (PPC) feature allows the EAGLE 5 ISS to assume the point codes of other nodes. This ability provides seamless migration from direct connection between SS7 networks to connection through an EAGLE 5 ISS STP.

The PPC feature is used when an STP is first brought into a network. If an EAGLE 5 ISS is introduced into a network that directly connects to a separate or 'foreign' SS7 network, and if the PPC feature is enabled and turned on, then a user can specify the point code of the home network as a proxy point code, which is then assumed by the EAGLE 5 ISS.

After the point code is assumed, the SS7 node in the home network is connected to the EAGLE 5 ISS instead of directly connected to the SS7 node in the foreign network. The EAGLE 5 ISS provides routing connectivity in the home network to the foreign node and allows the foreign node to connect to the home network. The node in the foreign network continues to function as if it is connected to the original node in the home network.

The proxy point code is used as the originating point code for all EAGLE 5 ISS generated messages that are routed to the adjacent node of the linkset (referred to as the proxy linkset). The proxy point code can be reached by all nodes in the home network and can access all STP routing functionality in the foreign network. The EAGLE 5 ISS routes SS7 messages coming from the foreign network SS7 node into the home network based on the destination point code. A maximum of 100 point codes can be designated as proxy point codes.

Note:

IPGWx linksets cannot be assigned a proxy point code as an adjacent point code: therefore, M3UA links and SUA links are excluded.
The proxy point code must be a full point code and can be any of the following network types:
  • ANSI
  • ITU-N
  • ITU-I
  • ITU-N Spare
  • ITU-I Spare
  • ITU-N24

5.27.1 Feature Control

The PPC feature has the following feature control requirements:

  • The PPC feature is a quantity feature. The FAK that is used to enable the feature determines the maximum number of point codes that can be specified as proxy point codes. The allowed maximum ranges from 10 to 100, increasing in increments of 10. Each increment has a separate part number as shown:
    • 10: 893-0187-01
    • 20: 893-0187-02
    • 30: 893-0187-03
    • 40: 893-0187-04
    • 50: 893-0187-05
    • 60: 893-0187-06
    • 70: 893-0187-07
    • 80: 893-0187-08
    • 90: 893-0187-09
    • 100: 893-0187-10

    A FAK for the part number corresponding to the desired quantity is required.

  • The PPC feature is both enabled and turned on by the enable-ctrl-feat command. The chg-ctrl-feat command is not used.
  • Once a feature quantity is entered, the quantity value cannot be decreased.
  • After the feature is enabled and on, it cannot be turned off.
  • A temporary FAK cannot be used to enable the feature.
  • The Multiple Point Code (MPC) feature must be turned on at the EAGLE 5 ISS before the PPC feature can be enabled. It is not necessary for the MPC feature to be turned on at the adjacent node.

5.27.2 Hardware Requirements

The PPC feature does not have specific hardware requirements. However, the feature cannot be enabled if any of the following cards are present in the system:

  • LIMDS0
  • LIMV35
  • LIMOCU
  • ILA/EILA
  • LIM-E1
  • Dual-Slot DCM

If one of these cards is inserted after the feature is enabled, then the card will auto-inhibit.

5.27.3 Limitations

The PPC feature has the following limitations:

  • Only ‘A’ link types are supported on a linkset using a proxy point code.
  • Secondary adjacent point codes are not supported on a proxy linkset.
  • M3UA links and SUA links are excluded for proxy point codes.
  • If the routeset from the EAGLE 5 ISS to the proxy node is prohibited, then all links in any proxy linkset using the proxy point code are unavailable for traffic.
  • If more than 50% of the links in the linkset are down, then congestion may occur.
  • Only one linkset to an adjacent point code is supported by the EAGLE 5 ISS unless the Multiple Linksets to Single Adjacent PC feature is enabled and turned on.
  • Configurations where the same proxy point code is a member of both the foreign and home networks are not supported.
  • Global title translation (GTT) to a proxy node is not supported.

5.28 Quality of Service Enhancements (IP7 Release 3.0)

It is becoming necessary for networks to employ Quality of Service (QoS) techniques. QoS is a concept that allows elements of data transmission to be measured, improved, and, to some extent, predicted. As networks evolve, consideration must be given to guarantee acceptable levels of bandwidth, jitter, and latency for IP communication protocols, such as VoIP. The QoS enhancements added in release 3.0 provide the solution for these and other network communications parameters.

Quality of Service enhancements provide the ability to set the Type of Service (TOS) field in the IP packet header for QoS routing. This feature does not implement quality of service on it’s own. It does, however, provides the customer with the ability to set socket options, including the TOS field bits within the outgoing packet. Tekelec does not specify how the TOS bits should be set or interpreted. It is solely up to the customer to implement QoS using scheme best suited for them, by setting the TOS field bits.

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

img/c_quality_of_service_enhancements_ip7_release_3_0_prf-fig1.jpg

Figure 5-10 TOS Field

img/c_quality_of_service_enhancements_ip7_release_3_0_prf-fig2.jpg

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

img/c_quality_of_service_enhancements_ip7_release_3_0_prf-fig3.jpg

Figure 5-12 DiffServ Code Point Pool Table

img/c_quality_of_service_enhancements_ip7_release_3_0_prf-fig4.jpg

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 IP7 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

img/c_quality_of_service_enhancements_ip7_release_3_0_prf-fig5.jpg

5.29 Random SLS Generation (Release 28.0)

The Random SLS Generation feature allows operators to overcome some of the ITU protocol limitations by ignoring the SLS value in the incoming SS7 message when selecting an outgoing link for the message. This is accomplished by generating a new 8-bit SLS value that is used internally by the EAGLE to randomly select an outgoing link to the destination.

This feature does not alter the SLS value in the outgoing message; it is the SLS value received in the message. The newly-generated SLS is used for link selection only.

5.30 Remote Backup (Release 39.2)

The Remote Backup feature allows the database to be saved to and restored from a remote server, using FTP. If the EAGLE OA&M IP Security feature is turned on, then Secure FTP is used for data backup.

For a database backup, the EAGLE 5 ISS packs and compresses all files in a TAR file before transferring to a remote server. For a database restore, the EAGLE 5 ISS unpacks and uncompresses the files and places the files on the active partition group of the TDMs.

5.30.1 Feature Control Requirements

There are no feature control requirements identified for this feature.

5.30.2 Hardware Requirements

The Remote Backup feature requires E5-IPSM cards.

5.30.3 Limitations

No limitations are associated with this feature.

5.31 Remote Upgrade Download (Release 39.2)

The Remote Upgrade Download feature allows new software to be downloaded to the EAGLE 5 ISS from a remote server, using FTP. If the EAGLE OA&M IP Security feature is turned on, then Secure FTP is used for data transfer.

The EAGLE 5 ISS downloads software by downloading a single TAR file that contains compressed files associated with the software release. The EAGLE 5 ISS unpacks and uncompresses all files of a software release and places them on the inactive partition of the TDMs. A remote server must be set up within the customer network to support data transfer to the EAGLE 5 ISS.

5.31.1 Feature Control Requirements

There are no feature control requirements identified for this feature.

5.31.2 Hardware Requirements

The Remote Upgrade Download feature requires E5-IPSM cards.

5.31.3 Limitations

No limitations are associated with this feature.

5.32 REPT-STAT-CLK Enhancements for Clocking (Release 28.2)

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.

5.33 REPT-STAT-TRBL Enhancement (Release 29.0)

This feature is intended to allow users to display only the non-inhibited troubles for captures. This facility allows customers to quickly identify new alarms, versus the old ones they no longer wish to see.

Hardware Requirements

No new hardware is needed to support this feature.

5.34 Response to Commands Issued Prior to Login (Release 21.0)

Currently, if a command is entered prior to logging in to the EAGLE that contains a syntax error, the EAGLE responds with a syntax error message. When the user corrects the command and re-enters it, the EAGLE then responds with an authority violation error message. This is annoying to the user. The command would not have been accepted prior to being logged into the EAGLE, regardless of whether it’s syntax was correct.

If a command is entered before the user is logged in to the EAGLE, the EAGLE responds with the

Command Rejected : Authority violation
message regardless of whether the command’s syntax is correct.

5.35 Revoking a User ID (Release 21.0)

In Release 21.0, the system administrator can prevent the use of a user ID without having to remove it from the database. When a user ID is revoked, any future login attempts with the suspended user ID is rejected with the following message:


E2751 Cmd Rej: UserID has been revoked

The check for user ID revocation is made during the login process after the user has entered a valid user ID and password combination, and before any checks are made to see if the user's password must be changed.

A user ID is revoked by using the revoke=yes parameter of the chg-user command. The rtrv-user command output report shows which user IDs are revoked.

Revoking a user ID while the user is currently logged on to the system is allowed. In this case, the login session for the user immediately ends and the user is not allowed to enter any other commands.

The EAGLE does not allow user IDs assigned to the security administration command class to be revoked. If this is attempted, the chg-user command is rejected with the following error message:


E2759 Cmd Rej: Revocation of security admin userID not allowed

This prevents the system from becoming un-administrable because all user IDs have been revoked.

A revoked user ID can be put back into service using the revoke=no parameter with the chg-user command.

5.36 Route SRI_SM for non-local or ported out subscribers using GTT (Release 42.0)

The Route SRI_SM for non-local or ported-out subscribers using GTT functionality allows SRI_SM messages to be modified so that the message can be routed to an alternate network using Global Title Translation (GTT). This functionality allows processing to occur when the DN in the database is associated with both the Service Point (SP) and Generic Routing Number (GRN) network elements and the GRN is not present in the EAGLE 5 ISS HomeRN table, or when the subscriber is ported out and associated with the RN.

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

This conversion is performed only on ITU TCAP Begin SRI_SM MSUs.

If the MT-Based GSM SMS NP or the IS41 GSM Migration feature generates a response for the SRI_SM message then this functionality is not applicable.

5.36.1 Feature Control Requirements

The G-Port (Part Number 893-0172-01) or IS41 GSM Migration (Part Number 893-0173-01) feature must be enabled before the SRI_SM message routing functionality can be provisioned. One of the features must be turned on before processing can occur.

5.37 Routing Key Enhancements (IP7 Release 3.0)

The Routing Key Enhancements feature provides routing to IP devices with an ITU National or International Point code. In addition, routing for TUP messages is also provided.

Routing Key Enhancements, including the following features:

  • Multiple Routing Key Registration allows for the registration of up to three routing keys in a single TALI message.

  • Q.BICC Routing provides routing to TCP/IP sockets for BICC messages. BICC messages are very similar to ISUP messages, except the CIC has been expanded to 32 bits. Routing for ANSI or ITU BICC messages is based on SI=13, OPC, DPC, and CIC. The point codes within the routing key must be ANSI, ITU National or ITU International.

  • ITU Routing Key Enhancements provide the following additional routing capabilities for international users:

    • ITU ISUP CIC Routing provides OPC/DPC/CIC routing to IP devices for ITU ISUP messages. Routing for ITU ISUP messages to an IP device is based on SI=5, OPC, DPC, and CIC. The point codes within the ITU ISUP routing key must be either ITU National or ITU International.

    • ITU DPC-SSN Routing provides DPC/SSN routing to IP devices for ITU SCCP messages. Routing for SCCP messages to an IP device is be based on SI=3, DPC, and Subsystem. The point codes within the ITU SCCP routing key must be either ITU National or ITU International.

    • ITU DPC-SI Routing provides DPC/SI routing to IP devices for non-ISUP and non-SCCP ITU messages. Routing to ITU point codes on the IP network for non-ISUP and non-SCCP messages is be based on the Destination Point Code and SI indicator, where SI is not 3, 4 (ITU), 5, or 13. A message with SI=4 bound for an ITU National or International point code is assumed to be a TUP message, and is routed as such. The point codes with the ITU DPC-SI routing key must be either ITU National or ITU International.

    • Telephone User Part (TUP) Routing provides OPC/DPC/CIC routing to IP devices for TUP messages. Routing TUP messages to an IP device with an ITU point code is be based on SI=4, OPC, DPC, and CIC. The point codes within the routing key must be ITU National. An MSU with SI=4 bound for an ANSI point code will continue to be routed on DPC-SI.

5.38 RTDB Download Enhancement (Release 46.0)

With EAGLE 46.0 and EPAP 16.0, the RTDB download time from EPAP to EAGLE is improved, which results in a reduced delay for the EAGLE Service Module cards to achieve In-Service status.

5.39 RTDB Reload from Remote Time Interval (EPAP 16.0)

Reloading the Real-Time Database (RTDB) from the remote EPAP server and reloading the Service Module cards completes within one hour.

5.40 RTDB Retrieve (EPAP 9.0)

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.

5.41 RTRV-RTE/RTRV-DSTN: Support of PC Wildcards (Release 35.0)

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.

5.42 RTRV-STP Command (Release 35.0)

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.

5.43 RTRV-STP on FTRA

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.

5.44 RTRV-TBL-CAPACITY Enhancement (Release 29.0)

This enhancement introduces the new command rtrv-tbl-capacity, which retrieves table use summary information.

Hardware Requirements

No new hardware is needed to support this feature.

5.45 EAGLE 5 SCCP Capacity Increase (Release 41.1)

The E5-SM4G Throughput Capacity feature is enhanced to support a 6800 TPS transaction rate per E5-SM4G card.

As part of this enhancement, the E5-SM4G Throughput Capacity feature is now a quantity feature. Part Number 893-0191-01 continues to support a maximum capacity of 5000 TPS per E5-SM4G card. Part Number 893-0191-02 supports 6800 TPS per E5-SM4G card.

Table 5-10 shows the TPS capacities that are supported.

Table 5-10 TPS Capacities

Part Number Maximum TPS Capacity per E5-SM4G Card Maximum System Capacity
893-0191-01 3125

75,000 TPS with one or more EPAP-related features enabled and 24+1 cards

5000

150,000 TPS with no EPAP-related or ELAP-related feature traffic and 31+1 cards

120,000 TPS with G-Flex and the ANSIGFLEX STP option enabled and 24+1 cards

40,000 TPS with ELAP and 8+1 cards

893-0191-02 6800

210,800 TPS with no EPAP-related or ELAP-related feature traffic and 31+1 cards

163,200 TPS with one or more EPAP-related features enabled and 24+1 cards

54,400 TPS with ELAP and 8+1 cards

5.45.1 Feature Control Requirements

The E5-SM4G Throughput Capacity feature requires a FAK for the desired quantity Part Number:

  • 893-0191-01—5000 TPS Capacity
  • 893-0191-02—6800 TPS Capacity

If the 6800 TPS Capacity quantity is enabled, then the 5000 TPS Capacity quantity cannot be enabled.

5.45.2 Hardware Requirements

E5-SM4G cards must be installed in the system before either E5-SM4G Throughput Capacity quantity can be used.

5.46 SCCP Loop Detection (Releases 35.6, 37.5)

The SCCP Loop Detection feature allows the EAGLE 5 ISS to detect SCCP looping of UDT/XUDT and UDTS/XUDTS messages for all concerned signaling transfer points (STPs).

An STP sends GTT messages to the capability point codes (CPCs) of mated nodes for load sharing; however, SCCP looping can result if the destination point code (DPC) is the same as either the originating point code (OPC) or the point code of any intermediate in the network. The CPC cannot be omitted because it is used in other functionality.

The SCCP Loop Detection feature allows a correlation to be made between true/secondary point codes and CPCs for all concerned STPs. This correlation allows the EAGLE 5 ISS to compare the OPC of an incoming MSU to the post-GTT DPC to determine the possibility of looping.

A Loopset table is provisioned to define the correlation between the true/secondary point codes and the CPCs.

The SCCP Loop Detection feature operates in the Notify and Discard modes. In the Notify (default) mode, the SCCP Loop Detection feature generates a UIM when it detects SCCP looping and does not discard the MSU. This UIM allows the user to capture and verify MSUs throughout the system for SCCP looping. In the Discard mode, the SCCP Loop Detection feature generates the same UIM when it detects SCCP looping and discards the MSU.

5.46.1 Feature Control Requirements

The SCCP Loop Detection feature has the following feature control requirements:

  • A FAK for part number 893-0165-01
  • The feature cannot be turned off after it has been turned on.
  • A temporary FAK cannot be used to enable the feature.

5.46.2 Hardware Requirements

The SCCP Loop Detection feature requires DSM (4 GB) or higher cards. TSM cards are not supported.

5.46.3 Limitations

When this feature is implemented, the capacity limits for combinations of DN/IMSI will be less than what is supported today.

  • Existing limit: {DN, IMSI} = {36M, 60M}, {12M, 82M} and {6M, 90M}
  • New limit for EPAP 10.0: {DN, IMSI} = {36M, 52M}, {12M, 75M} and {6M, 82M}

This decrease in capacity is based on high-level engineering design for the feature. Since these combinations are not used in the field, this limitation does not affect any customers.

5.47 SCCP Message Type Screening (Release 22.0)

The allowed calling party address (CGPA) screen can screen messages for these SCCP message types: UDT, UDTS, XUDT, and XUDTS. A new parameter, sccpmt, has been added to the ent-scr-cgpa, dlt-scr-cgpa, and chg-scr-cgpa commands to configure the allowed CGPA screen to screen for these messages. A new field, SCCPMT, has been added to the output of the rtrv-scr-cgpa command to show the SCCP message type in the allowed CGPA screen.

5.48 SCCP on SLIC TPS Increase [13.6k] (Release 46.6)

With this feature, the max SCCP throughput supported on a SLIC card is increased to 13.6K TPS under certain conditions, and the nodal max SCCP throughput increases to 544K TPS.

An SCCP64 card will support 13,600 TPS if all of the following conditions are true:

  • The card is a SLIC card
  • If the card is provisioned as data=EPAP, the EPAP240MB option in STPOPTS must be OFF
  • GSM Map Screening is not enabled for any linkset in the EAGLE

5.48.1 Hardware

The new 13,600 TPS rate is applicable only to cards running the SCCP64 application on SLIC cards.

5.49 SCCP Service Re-Route Capability (Release 34.3)

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.

Figure 5-14 G-Flex and G-Port Network Diagram

img/c_sccp_service_re_route_capability_release_34_3_prf-fig1.jpg

New Concepts

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

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.

Note:

When the SCCP Service Re-Route Capability feature is first turned ON, the G-Flex and G-Port Service States are automatically set to OFFLINE. The user must change the relevant state to ONLINE before any traffic is processed by G-Flex or G-Port.

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.

5.50 SCCP/TCAP Over IP Gateway for Point-to-Multipoint Connectivity (IP7 Release 1.0)

The SCCP/TCAP-over-IP feature allows SS7 nodes to exchange SCCP/TCAP Query/Responses with an IP-SCP. The IP7 Secure Gateway manages the point codes and subsystem numbers for the IP-SCP. From the SS7 network perspective, the TCAP queries are routed using these Point Code/SSNs. The signaling gateway maps the Point Code/SSN to one or more TCP sessions, converts the SS7 MSUs to TCP/IP packets by embedding the SCCP/TCAP data inside a TCP/IP packet, and routes it over an IP network. The gateway also manages the application subsystem status from the IP network's perspective and the SS7 network's perspective.

Figure 5-15 SCP Connectivity via TCAP over IP

img/c_sccp_tcap_over_ip_gateway_for_point_to_multipoint_connectivity_ip7_release_1_0_prf-fig1.jpg

This feature provides TCP/IP point-to-multipoint connectivity by way of a new GPL, SS7IPGW, running on the DCM which, together with the hardware, provides connectivity to databases (or other switching equipment) for SS7 devices that reside on ethernet TCP/IP networks.

A single DCM card running the SS7IPGW application provides connections to multiple IP devices (IP-SCPs, class 4 switches, class 5 switches, VoIP gateways, media gateway controllers, or remote access servers.) Multiple DCM cards running the SS7IPGW application are required, with similar configuration, to provide redundancy. The following is a common sequence of events that illustrates the use of point-to-multipoint connectivity:

  1. Traditional SS7 devices route MSUs (such as TCAP Queries) to the STP.

  2. The gateway performs a global title translation and forwards the translated MSU to the correct TCP/IP device based on point code and SCCP subsystem information in the MSU.

  3. The TCAP query is processed at the IP-SCP, and the IP-SCP sends a TCAP reply back to the STP.

  4. The STP forwards the TCAP reply back to the sender of the original query.

To provide point-to-multipoint connections, a number of administration steps must first be performed, as follows:

  • Links, link sets, destinations and routes to the destinations must be configured.

  • The socket connections at each DCM card running the SS7IPGW application must be configured.

  • The SS7 routing keys that are transported over each defined socket at each card must be configured. SS7 routing keys are filters consisting of values representing the DPC, SI and SSN fields from a incoming MSU message. All MSUs that match the filter are sent to the corresponding socket. The sockets represent TCP sessions. These keys allow for distribution of MSUs on the IP network.

5.51 SCCS Interface Support (Release 21.0)

This feature allows the EAGLE to interface to the SCCS terminals using existing EAGLE message input and output formats. The SCCS type is used for some network monitoring and surveillance appliations. The SCCS terminals are the same as KSR terminals, except that a predefined “start-of-message” character is added to indicate the beginning of a new command response or unsolicited message.

Use the Change Terminal (chg-trm) command to configure the operational characteristics of the SCCS terminal. Refer to the Commands Manual of your current Documentation Suite.

The following error message is new to this feature:


E2149 Cmd Rej: TYPE = SCCS and PRTY=NONE combination is not allowed

Refer to the Commands Error Recovery Manual of your current Documentation Suite.

5.52 SCTP Checksum for Support for ADLER-32 and CRC-32 on per-card basis (Release 37.11)

The SCTP Checksum for Support for ADLER-32 and CRC-32 on per-card basis enhancement allows an SCTP checksum algorithm to be selected per IPLIMx or IPGWx card. Both the Adler-32 and CRC-32c checksum algorithms are supported for the specified card.

The selected SCTP checksum type is used by all the SCTP associations on the card, after all the SCTP associations for a specific IPLIMx/IPGWx card are closed and re-opened, or after the IPLIMx or IPGWx card is reloaded.

Note:

The system-wide SCTP checksum algorithm has precedence over the per card SCTP checksum algorithm setting.

5.52.1 Feature Control Requirements

There are no feature control requirements identified for this feature.

5.53 SCTP Checksum Update (EAGLE Release 30.0/IP7 Secure Gateway Release 8.0)

Description

Shortly after the introduction of the Stream Control Transmission Protocol (IETFRFC 2960), a fundamental weakness was detected in the Adler-32 checksumFoot 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.

Note:

This feature is a SSEDCM-based feature only (P/N 870-2372-01).

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.

Table 5-11 SCTP Common Header Format

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

6

7

8

9

0

1

Source Port Number

Destination Port Number

Verification Tag

Checksum

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

5.54 SCTP Payload Protocol Identifier needs to handle Big Endian or Little Endian byte order (Release 42.0)

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

rtrv-uaps:set=1
    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.

rtrv-assoc
                    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.

rtrv-assoc:aname=m2pa1
    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

5.55 SCTP Retransmission Control (Release 28.1) (IP7 Release 6.0)

This feature offers users a choice of two retransmission policies and enhanced control over the behavior of data retransmissions of SCTP associations in the IP7 SG. This functionality allows users to tailor retransmissions to their networks, on an individual association basis, to address these time-critical protocol constraints.

Note:

This is a non-orderable feature required for the three IETF Connectivity features and the IPLIM Protocol Support Enhancement feature.

Hardware Requirements

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

5.56 SEAS Enhancements (Release 26.0)

These enhancements are part of Tekelec’s ongoing effort to become SEAS-compliant.

  • The EAGLE now supports High Speed Links (ATM-1.536 Mbps) through the SEAS Interface]. (CHG-slk is not required to be supported.)

  • The EAGLE now supports provisioning of supplier-specific parameters for the following SEAS commands:

    • ADD/CHG/VFY-LS (Linkset)

    • ASGN/CHG/VFY-SLK (Link)

    • add/chg/vfy-gtwyls (Gateway Linkset)

    • ADD/CHG/VFY-DSTN for the NCAI parameter

      Note:

      There is no functionally equivalent EAGLE command for the SEAS commands ADD/CHG/VFY-GTWYLS. Parameters for the link and screen set on the EAGLE will be used to provide the supplier-specific parameter for the ADD/CHG/VFY GTWYLS commands. Supporting screen set names as a supplier-specific parameter is not required.

Affected Commands

add-ls (Linkset)

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

Table 5-12 Supplier-Specific Parameters

Supplier-Specific Parameters Description Allowed Values

BEI

Broadcast Exception Indicator

YES, NO

GWSA

Gateway Screening Allowed Mode

ON, OFF

GWSM

Gateway Screening Messaging Mode

ON, OFF

GWSD

Gateway Screening Discard Mode

ON, OFF

SCRN

GWSScreen Set Name

AYYY

SLSCI

SLS Conversion Indicator

ON, OFF

ASL8

Adjacent SLS

YES, NO

SLTSET

SLTM Set ID

1 –20

NIS

Network Indicator Spare

ON, OFF

MTPRSE

MTP Restart Equipped

YES, NO

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.

chg-ls

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

Table 5-13 Supplier-Specific Parameters for chg-ls

Supplier Specific Parameters Description Allowed Values

TFATCABMLQ

TFA/TCA Broadcast Min. Link

Quantity

0 –16

BEI

Broadcast Exception Indicator

YES, NO

GWSA

Gateway Screening Allowed Mode

ON, OFF

GWSM

Gateway Screening Messaging Mode

ON, OFF

GWSD

Gateway Screening Discard Mode

ON, OFF

SCRN

GWSScreen Set Name

AYYY

SLSCI

SLS Conversion Indicator

ON, OFF

ASL8

Adjacent SLS

YES, NO

SLTSET

SLTM Set ID

1 –20

NIS

Network Indicator Spare

ON, OFF

MTPRSE

MTP Restart Equipped

YES, NO

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.

Table 5-14 Supplier-Specific Parameters for add-gtwyls

Supplier Specific Parameters Description Allowed Values

BEI

Broadcast Exception Indicator

YES, NO

GWSA

Gateway Screening Allowed Mode

ON, OFF

GWSM

Gateway Screening Messaging Mode

ON, OFF

GWSD

Gateway Screening Discard Mode

ON, OFF

L3TSET

Level 3 Timer Set

1

SCRN

GWSScreen Set Name

AYYY

SLSCI

SLS Conversion Indicator

ON, OFF

ASL8

Adjacent SLS

YES, NO

SLTSET

SLTM Set ID

1 –20

NIS

Network Indicator Spare

ON, OFF

MTPRSE

MTP Restart Equipped

YES, NO

ACTNAME

Stop Action Set Name

Alphanumeric(6)

DESTFLD

Destfld Screening

YES, NO

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.

Table 5-15 Supplier Specific Parameters of asgn-slk

Supplier Specific Parameters Description Allowed Values

L2TSET

Level 2 Timer Set

1-20

L1MODE

Mode of Operation Used to Select Link Clocking Source

DTE, DCE

TSET

Transmitter Signal Element Timing

ON, OFF

ECM

Error Correction Method

BASIC, PCR

PCRN1

Number of MSUs Available For

Retransmission Threshold

1-127

PCRN2

Number of MSU Octets Available For Retransmission Threshold

300-35500

LPSET

Link Parameter Set Identifier

1-20

ATMTSEL

ATM Timing Selector

LINE, INTERNAL,

EXTERNAL

VCI

Virtual Channel Identifier

0-65535

VPI

Virtual Path Identifier

0-4095

LL

ATM Line Length

0-7

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]"

5.57 SEAS Enhancements, Autonomous Messages (Release 22.0)

The EAGLE in release 22.0 supports these SEAS autonomous messages.

  • REPT-GTWYACT - notification that the gateway threshold has been exceeded

  • REPT-SCRREJ - notification that an MSU has been discarded because of gateway screening.

  • REPT-DBCPY - notification that the EAGLE’s database has been either backed up or restored.

  • REPT-NOTRNS - notification that the EAGLE is unable to perform a global title translation because of problems with the GTT tables and the MSU has been discarded.

  • REPT-MTPERR - notification that the EAGLE cannot perform MTP level routing for a received MSU and that MSU has been discarded.

  • REPT-LKSTO - notification that all signaling links in a linkset are unavailable because of multiple signaling link failures or processor outages.

  • RCVRY-LKSTO - notification that the EAGLE has recovered from a previously reported linkset outage condition.

  • REPT-LINK-CGST - notification that the value occupancy threshold reached/exceeded field in the MSU is set to a fixed value regardless of the congestion level being reported.

  • RCVRY-LINK-CGST - notification that the value occupancy threshold reached field in the MSU is set to a fixed value regardless of the congestion level being reported.

This feature prevents duplicate autonomous messages to be sent to the SEAS ports.

This feature also introduces these new EAGLE commands to configure the thresholds for the REPT-GTWYACT and the REPT-SCRREJ messages.

  • set-gtwy-acthresh - configures the gateway threshold

  • rtrv-gtwy-acthresh - displays the current values of the gateway threshold

  • set-scrrej-prmtrs - configures the quantity of REPT-SCRREJ messages are sent to SEAS

  • rtrv-scrrej-prmtrs - displays the quantity of REPT-SCRREJ messages are sent to SEAS

These actions can also be performed from the SEAS interface with these SEAS command functions, SET-GTWY-ACTHRESH, RTRV-GTWY-ACTHRESH, SET-SCRREJ-PRMTRS and RTRV-SCRREJ-PRMTRS.

5.58 SEAS Gateway Audit Command (CHK-UNREF-ENT) (Release 22.0)

Release 22.0 introduces the chk-unref-ent command on the EAGLE and supports the CHK-UNREF-ENT command function on the SEAS interface.

This feature gives users the ability to identify unreferenced entities in the EAGLE’s gateway screening entity sets. These unreferenced entities can be dealt with by the user as required.

Unreferenced gateway screening entity sets are those entity sets that are not referenced by another entity with the next screening function identifier (NSFI) and next screening reference (NSR) combination or with the link set screening reference (that is, a screen set used by a link set). Any unreferenced gateway screening entities are displayed by the entity set name (screen set name) and screening reference (NSFI).

The EAGLE’s chk-unref-ent command uses these parameters.

Parameters

:aftpc= Is the Affected PC/SSN entity set to be checked?

:blkopc= Is the Blocked OPC entity set to be checked?

:blkdpc= Is the Blocked DPC entity set to be checked?

:cdpa= Is the Allowed CDPA entity set to be checked?

:cgpa= Is the Allowed CGPA entity set to be checked?

:destfld= Is the Affected DESTFLD entity set to be checked?

:dpc= Is the Allowed DPC entity set to be checked?

:opc= Is the Allowed OPC entity set to be checked?

:sio= Is the Allowed SIO entity set to be checked?

:tt= Is the Allowed TT entity set to be checked?

:all= Are all the gateway screening entity sets to be checked?

The values for these parameters are either yes or no, with the default value being no.

5.59 SEAS Interface Support (Release 21.0)

This feature allows the EAGLE to interface with the Signaling Engineering and Administration System (SEAS). The Signaling Engineering and Administration System (SEAS) is an interface defined by Bellcore and used by the Regional Bell Operating Companies (RBOCs), as well as other Bellcore Client Companies (BCCs), to remotely administer and monitor the signaling points in their network from a central location. SEAS provides a single, reliable, machine-to-machine interface by which commands are entered from a Signaling Engineering and Administration Center (SEAC) or a Signaling Network Control Center (SNCC) to various signaling points, such as STPs. These signaling points then provide command responses back to the SEAC. The signaling points also provide automatic alarm and measurement data to the SEAC. Specifically, SEAS is used for the following functions.

  • Memory Administration (Recent Change and Verification)

  • Network Maintenance

  • Network Data Collection (Measurements)

  • Network Traffic Management Surveillance

  • SEAS Application Control

  • Supplier Specific Functions

The SEAS interface has the following capabilities:

  • Flow through messages - This allows any EAGLE command to be entered into the system from a SEAS console.

  • Recent change and verify (immediate activation only) for following data entities:

    1. MTP (routes, route sets, signaling links, linksets, point codes, etc.)

    2. GTT (global title translations, subsystems, and mated applications)

    3. GWS (all gateway screening tables)

  • Data collection (autonomous and on-demand) for existing measurement data

  • On-occurrence output capability for existing reports

  • Supports one active X.25 signaling link and one backup X.25 signaling link. Each X.25 signaling link supports a minimum of 10 PVCs on a LIMV35 card at data rates of 64 kbps, 56 kbps, 19.2 kbps, 9.6 kbps, 4.8 kbps and 2.4 kbps on a per link basis.

The SEAC uses X.25 links to transmit data to and receive data from the signaling points it is monitoring. Terminal inputs to the EAGLE use asynchronous RS-232 ports. An operations system support applications processor (OAP) is used to allow the EAGLE to communicate with the SEAC. The OAP is an adjunct processor that interfaces to a BX.25 link and converts the data stream to an asynchronous serial format. All conversion from SEAS to EAGLE command sets takes place on the EAGLE. Two terminal disk module (TDM) ports (RS-232) running at 19,200 bps connect the OAP to the EAGLE. Two BX.25 links connect the OAP to the SEAC. The OAP is mounted in a frame similar in design to the other frames used in the EAGLE, and is labeled as OAPF.

The OAP is a TEXAS MICRO™ Intelligent Processor Unit Telecommunications Server, model 9605 (Sparc 05, 85 MHz processor) and contains:

  • 32 megabytes of RAM

  • a 1.02 gigabyte hard drive using a SCSI interface

  • a 1.44 megabyte floppy disk drive, a high-speed serial interface (HSI) SBUS card (with 4 synchronous ports)

  • RS-232C-extender SBUS communications board (with 4 asynchronous ports).

The OAP is powered from the OAP frame’s fuse and alarm panel with -48 VDC.

The OAP uses the following software to allow the EAGLE to communicate with the SEAC:

  • SUN™ Solaris version 2.4 operating system

  • SunLink Solaris version 9 for X.25

  • The SEAS application software.

    Note:

    Some of the names of the EAGLE measurement counters have been changed to match the names used by SEAS. Table 5-16 shows the names of the measurement counters that have changed and the measurement reports and entity types that contain these counters.

    Table 5-16 Changed EAGLE Measurement Names

    Measurement Report Measurement Entity Type Current Measurement Name New Measurement Name

    ALL

    STP

    IMSINVDPC

    MSINVDPC

    ALL

    STP

    IMSINVSIO

    MSINVSIO

    COMP

    LINK

    DURLNKUNV

    DRLKOTG

    COMP

    LINKSET

    MSURGTT

    MSUSRGTT

    COMP

    LINKSET

    OCTRQGTT

    OCTRCGTT

    MTCD, MTCDTH

    LINK

    LNKAVALT

    LNKAVAIL

    MTCD, MTCDTH

    LINK

    DRLNKINH

    DRLKINHB

    MTCD, MTCDTH

    LINK

    SURCVERR

    MSURCERR

    MTCD, MTCDTH

    LINK

    NEGACKRCV

    NEGACKS

    MTCD, MTCDTH

    LINK

    NEARMGINH

    NEARMGIH

    MTCD, MTCDTH

    LINK

    NDCLFABN

    NDCFLABN

    MTCD, MTCDTH

    LINK

    NDCLFXDA

    NCDFLXDA

    MTCD, MTCDTH

    LINK

    NDCLFXER

    NDCFLXER

    MTCD, MTCDTH

    LINK

    NDCLFXDC

    NDCFLXDC

5.60 SEAS Over IP (Release 37.5)

The SEAS Over IP (SOIP) feature provides a TCP/IP-based interface for SEAS. The SEAS interface constitutes the path between the EAGLE 5 ISS and the Common Channel Signaling Message Router (CCS MR).

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:

Table 5-17 SEAS Over IP Configurations

SOIP Configuration Description
Dual E5-IPSM with Single CCS MR Consists of two E5-IPSM cards with one SEAS terminal connection to a single CCS MR. Up to 3 E5-IPSM cards can be provisioned per system: however, the SEAS terminal is supported on only two out of the three E5-IPSM cards.

The connection to the CCS MR is dedicated to SEAS; however the E5-IPSM card can be used for other IP-based operations.

The E5-IPSM cards operate redundantly, allowing two active connections to the CCS MR. Different SEAS information can be transmitted and received separately over each connection to the CCS MR.

Dual E5-IPSM with Dual CCS MR (loosely coupled) Consists of two E5-IPSM cards connected to a loosely coupled pair of CCS MRs. The CCS MRs operate in a round robin manner if they each have an active connection to an E5-IPSM card.
Simplex E5-IPSM Consists of one SEAS terminal configured on one E5-IPSM card to create a connection to one CCS MR. This configuration does not provide redundant connections to the CCS MR and is intended to serve as a restricted mode until another E5-IPSM card can be returned to service.

The connection to the CCS MR is dedicated to SEAS: however, the E5-IPSM card can be used for other IP-based operations. All SEAS information is transmitted over the single IP connection to the CCS MR. The SEAS system is in an IS-ANR/Restricted state if the system is in Simplex E5-IPSM SEAS operation, and a Major alarm is present on the SEAS system.

Note:

Simplex SEAS operation is not recommended.

5.60.1 Feature Control Requirements

The SEAS Over IP feature has the following feature control requirements:

  • A FAK for part number 893-0188-01
  • The feature is an On/Off feature.
  • A temporary FAK cannot be used to enable the feature.
  • The IPUI feature must be enabled before the SEAS Over IP feature can be enabled. The IPUI feature must be turned on before the SEAS Over IP feature can be turned on.

5.60.2 Hardware Requirements

At least one E5-IPSM card must must be provisioned in the EAGLE 5 ISS.

Note:

Two E5-IPSM cards are recommended for redundant connectivity to the CCS MR.

5.60.3 Limitations

The SEAS Over IP feature has the following limitations:

  • MMI messages are not supported.
  • The CCS MR node name is not configurable by the EAGLE 5 ISS. The CCS MR must be assigned a name by Telcordia.
  • The only supported Authentication Mode in EAGLE 5 ISS for Client Authentication for communication with the CCS MR with the Security Feature ON is Password Authentication.

5.61 SEAS Verify Signaling Route-Set Status and SCCP Application Status Command (VFY-SRSAPST) (Release 22.0)

Release 22.0 supports the VFY-SRSAPST command function on the SEAS interface which is used to display the status of the current MTP signaling routesets, the status of individual routes, and the status of the SCCP application subsystem for specified destinations and applications that the EAGLE routes traffic to. This feature reduces the need to use non-SEAS EAGLE commands with the SEAS Flow-Through command to display this information.

5.62 Secure GUI Access (EPAP 16.0)

As an enhancement to system security, the default protocol for GUI access to the EPAP is changed from HTTP to HTTPS protocol. EPAP uses TCP port 443 for HTTPS and port 80 for HTTP. The customer must reconfigure the existing installation for HTTPS prior to upgrading the EPAP software to EPAP Release 16.0. During this reconfiguration, if the customer uses a firewall, the firewall must be configured to allow traffic on the HTTPS port 443.

5.63 Security Enhancements (EPAP 14.0)

Security features for EPAP 14.0:

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.

5.64 Security Log Increase (Release 26.05)

Security Logging is used to store the commands that are issued on EAGLE, either using the EAGLE terminal, or via SEAS Port. The Security Logging facility also stores additional information about the command, such as, date/time received, terminal on which received, UserID, and result of the command execution.

The Security Log Increase feature increases the Log size from 10K entries to 50K entries.

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.

5.65 Selective Alarm Inhibiting (Release 22.0)

This feature allows the user to turn off major and minor alarms for specific devices. Critical alarms cannot be turned off. The following are examples of situations where a user may want to turn off alarms.

  • When repeated alarms from malfunctioning equipment could mask valid alarms, for example, a signaling link that is out of service because of a physical break that cannot be repaired for days, the alarm for that signaling link can be turned off.

  • The EAGLE database is being configured. Alarms are generated immediately after entries are entered into the database. If these alarms are ignored and a problem develops that requires immediate attention, that problem may be ignored.

Alarms can only be turned off for these devices or entities.

  • cards in the database

  • signaling links in the database

  • linksets in the database

  • EAGLE terminals

  • system clock

  • TCP/IP data links in the database

  • customer defined troubles

  • SEAS X.25 links

When the system has alarms only for devices that have their alarms turned off, all the alarm indicators (visual and audible) are turned off. If alarms exist for devices that have not been turned off, or for entities whose alarms cannot be turned off, the alarm indicators remain on.

The alarm indicators are turned on only for devices or entities that do not have their alarms turned off, or that cannot be turned off.

When an alarm is turned off, no unsolicited alarm messages (UAMs) are generated for the device when an alarm condition for that device is detected.

When an alarm is turned off, UIM 0004 is displayed to inform the user that the alarm for the specified device has been turned off. In this example, the alarms for card 1201 have been turned off.

UAM


RLGHNCXA03W 97-06-07 14:56:48 EST Rel 22.0.0
5005.0004    CARD 1201 SS7ANSI     Device alarms inhibited

If an alarm is turned off, it remains off even if the MASP is reset.

A count of the alarms that are turned off is shown in the alarm status region of the VT320 display terminal (Figure 5-16). The alarm status region (Figure 5-17) of the terminal display contains four boxes with numbers underneath. The boxes contains the labels for the alarm types and the numbers show the number of each type of alarm that has been detected on the EAGLE.

  • CRIT - critical alarms - Indicates a severe, service-affecting condition has occurred and that immediate corrective action is needed, regardless of the time of day or the day of the week

  • MAJR - major alarms - Indicates a serious disruption of service or the failure of important circuits is taking place. These troubles require attention and response to restore or maintain system capability

  • MINR - minor alarms - Indicates a trouble, but does not have a serious effect on service.

  • INH - inhibited alarms - alarms that have been turned off.

    Figure 5-16 EAGLE Terminal Display

    img/c_selective_alarm_inhibiting_release_22_0_prf-fig1.jpg

    Figure 5-17 Alarm Status Region of the EAGLE Terminal Display

    img/c_selective_alarm_inhibiting_release_22_0_prf-fig2.jpg

5.66 Self Healing DN Range in EPAP Database (EPAP 14.0)

The Self Healing DN Range in EPAP Database feature spports a single DN Block conflict in the EPAP database by allowing the EPAP database to self heal when a command is executed to create a new DN Block that conflicts with existing DN Blocks. This feature allows defragmentation of the DN Blocks, where a DN Block is split into child DN Blocks when conflicting DN Blocks are added and then returned to the parent DN Block upon deletion of particular child DN Blocks.

For typical provisioning configurations, the average provisioning rate is approximately 50 Commands per Second (CPS). With the Self Healing DN Range in EPAP Database feature turned on, the average provisioning rate may decrease below 50 CPS. In worst case conditions, the provisioning rate may decrease to 18 CPS.

By limiting the number of commands in an import file, the provisioning rate can be improved, depending on the provisioning configuration. For example, multiple import files limited to 200,000 commands are more efficient than a single import file of several million commands. Other performance factors related to the Self Healing DN Range in EPAP Database feature are associated with the internal data distribution, which cannot be directly influenced by the user. If provisioning performance falls below expected levels, contact My Oracle Support (MOS).

When a self healing EPAP database encounters a conflict:
  1. Pre-existing/conflicting DN Blocks are automatically deleted from the EPAP database.
  2. New DN Blocks are created successfully with new attributes.
  3. Old DN Blocks are split to create more DN Blocks for the range not covered by the new DN block.

When a new DN Block is deleted, a range of numbers is returned to the original DN Block.

Rules for the Self Healing DN Range in EPAP Database feature

  • If the new DN Block is a subset of an already existing DN Block with different properties, the old DN Block is split into either 2 or 3 new DN Blocks.
  • The new DN Block cannot have the same bdn and edn as an existing DN Block.
  • The new DN Block cannot have a single DN address.
  • The resulting DN Block cannot have a single DN address.
  • More than one conflicting DN Block cannot exist in the EPAP database.
  • If the new DN Block is a subset of an existing block with same properties, then the DN Block cannot be created.
  • If the new DN Block conflicts with an existing block and is not its subset, then the new DN Block cannot be created.
  • A DN Block that conflicts with a DN Block and has a split option of no cannot be inserted.
  • A DN that conflicts with a DN Block and has a split option of no cannot be inserted.
  • If a DN Block that is created by splitting an existing DN Block is deleted, then the complete DN Block that existed before the split is returned to the EPAP database.

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.

5.67 Selective Homing of EPAP RTDBs (Release 29.0)

Currently, the RTDBs on an EPAP (A or B) will look for and receive updates from the local PDBA process on the local EPAP A (PDBA on the same MPS node as the RTDB), regardless of whether it is the active or standby PDB. An RTDB will only receive updates from the remote PDBA process on the mate MPS node if the local PDBA cannot be accessed.

Some customers would prefer to have all RTDBs within an "MPS System" (both nodes of a mated pair, or even multiple nodes within several mated pairs) always receiving updates from the active PDBA process, regardless of whether it is the local or remote PDBA.

The Selective Homing of EPAP RTDBs feature implements an EPAP configuration option that allows the customer to choose whether the RTDBs on a given MPS node will receive updates from a specific PDBA process (which may or may not be active), or from the active PDBA process (which may or may not be local). This option is selectable via the EPAP UI.

The terminology "specific PDBA" is used instead of "local PDBA," because architectures may result in an MPS without a PDB on EPAP A, in which case the RTDBs on that node would not have a "local PDBA." Specific homing would specify the IP addresses of the MPSs with the first and second choices of PDBA. In a two-node MPS system, this maps directly to "local" homing.

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.

5.68 SFAPP Use Case 3 — VLR Validation using IMEI (Release 46.7)

This use case is for Outbound roaming MAP messages: Time, Location Check messages, as defined by GSMA PRD FS.11, SS7 Interconnect Security Monitoring and Firewall Guidelines. This use case challenges the VLR after the Update Location procedure is complete by asking for the IMEI information in the Provide Subscriber Information message.

The four main Time, Location Check messages include:

  • Send Authentication Info - VLR or the SGSN initiates the MAP Send authentication info procedure to retrieve authentication information from the HLR.
  • Provide Subscriber Info - This message is sent by EAGLE to the VLR or SGSN to retrieve the subscriber state, location information, in this case IMEI.
  • Provide Subscriber Info ACK - This message is sent as an acknowledgment to the PSI from EAGLE to the VLR or SGSN.
  • Purge MS - If a roaming subscriber is suspected to be a malicious or fake user, EAGLE generates this message to HLR. On receiving this message, HLR marks the subscriber unreachable.

This use case challenges the visited VLR after the update location procedure has been completed by asking for the subscriber's IMEI information in a PSI message. One of these actions can then be taken:

  1. The IMEI information can then be compared against an external database to validate the IMEI and consequently the VLR by either allowing the original procedure to complete or fail it by initiating in a Purge MS operation, or
  2. The IMEI information can be added to/updated in the external database if the VLR is trusted and the IMEI is validated.

Figure 5-18 shows the call flow.

Figure 5-18 Graylisted VLR Challenge


img/graylisted-vlr-challenge.png

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.

5.69 SFAPP Use Case 4 - Intelligent VLR Whitelist (Release 46.7)

This use case is for Outbound roaming MAP messages, as defined by GSMA PRD FS.11, SS7 Interconnect Security Monitoring and Firewall Guidelines. This use case uses a whitelist that is created as part of learning from the validation attempts defined in Use Cases 1 through 3.

To implement a whitelist 'learning' based validation for the VLR, where the VLR addresses are validated from tables configured/stored on a disk in the STP, the tables are differentiated into two classes: Static and Dynamic VLR tables. Both classes contain VLR Tables.

The two static VLR tables are:

  • Static VLR profile table
  • Static VLR roaming table

The two dynamic VLR tables are:

  • Dynamic VLR profile table
  • Dynamic VLR roaming table

Figure 5-19 shows the VLR challenge flow.

Figure 5-19 Dynamic VLR Learning (VLR Whitelisting)


img/dynamic-vlr-learning-vlr-whitelisting.png

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.

5.70 Sigtran IPSG application on SLIC card (Release 46.3)

This feature allows for porting of the current IPSG application onto the Oracle Communications EAGLE Service and Link Interface Card (SLIC) (P/N 7094646). The SLIC operates with the same functionality as the E5-ENET-B (870-2971-01) card running the IPSG application.

See Hardware Reference for more information on the SLIC.

5.71 SIGTRAN Measurements Phase 1 (Release 38.0)

The SIGTRAN Measurements Phase 1 (SIGTRAN) feature allows measurements for the IPGWx and IPLIMx cards that are currently obtained using the EAGLE 5 ISS pass commands to be obtained through EAGLE 5 ISS measurement collection and reporting mechanisms. The SIGTRAN feature also obtains measurements for the IPSG cards that are introduced in Release 38.0.

Note:

The pass commands continue to be supported as a separate means of displaying the associated data.

On-demand measurement reports can be obtained through the User Interface or the Measurements Platform. Scheduled measurement reports must be obtained through the Measurements Platform.

The SIGTRAN feature provides measurement capabilities for the following protocols.

  • UA

    The UA protocol consists of a combination of the M3UA and SUA protocols. UA measurements are collected for IPGWx and IPSG cards per association (ASSOC) on the application server (AS).

    Note:

    IPSG cards support only M3UA protocols.

    Measurements for UA messages that are received without a routing context or with mutiple routing context values are pegged to the default AS value and the appropriate ASSOC. The RXMLRCMS register is used to indicate the number of messages received with multiple routing context values. This register is always pegged using the default AS value. The AS value can also be set to the default AS for all UA data.

    All UA data for IPSG cards is pegged against the default AS.

  • SCTP

    SCTP measurements are collected for IPGWx, IPLIMx, and IPSG cards per CARD and ASSOC.

  • M2PA

    M2PA measurements are collected on IPLIMx and IPSG cards per LINK.

5.71.1 Feature Control Requirements

There are no feature control requirements identified for this feature.

5.71.2 Hardware Requirements

The SIGTRAN feature requires SSEDCM or E5-ENET cards.

Note:

The iplim and ss7ipgw GPLs run on SSEDCM cards. The iplhc, ipghc, and ipsg GPLs run on E5-ENET cards.

5.71.3 Limitations

The SIGTRAN Measurements Phase 1 feature has the following limitations:
  • No new scheduled reports are available on the EOAM.
  • SCTP measurements are not supported on the SEAS interface.
  • If the active MASP boots during EAOM based measurement collection, then data for that period is lost.
  • 120K LNP NPANxx, and 80K LNP LRN may not have the CPU bandwidth to collect additional measurements.
  • The format of the existing COMP-LINK, MTCD-LINK, and MTCDTH-LINK reports on both the EOAM and the MCP has been modified. If these reports are passed to additional computer systems for automated parsing and analysis, then the software may have to be modified on the target systems to adjust to the changes.
  • If an AS with the name default exists before upgrate, then accurate collection of measurment data for that AS cannot be guaranteed.
  • The ACTIVE period for UI reports is not supported for any reports that are generated for the IPSG card.

5.72 Simplifying BIP (Board ID PROM) for EAGLE STP Boards (Release 23.1)

This feature changes the 7- and 8-digit serial numbers currently used to identify a board in the EAGLE to serial numbers that contain 7, 8, 11, 12, and 14 digits. The serial number is contained in the board ID PROM on each board in the EAGLE.

The 7- and 8-digit serial numbers are used on older systems and require no changes to support. The 11-digit serial number is presently used by Tekelec manufacturing, but was not fully supported by the EAGLE system software. The 12-digit serial number adds a special character to the serial number used by manufacturing. The 14-digit serial number uses four digits to show the year that the board was manufactured. All the serial number formats are compliant with the Year 2000 feature.

Table 5-18 shows the format of each of the five serial number formats.

Table 5-18 Serial Number Formats

Serial Numbers Formats

7-digit serial number

ywwxxxx

8-digit serial number

yywwxxxx

11-digit serial number

nnnyywwxxxx

12-digit serial number

nnnyyww*xxxx

14-digit serial number

nnnyyyyww*xxxx

y = year digit (0 - 9)

w = week digit (0 - 9)

n = product identifier digit (0 - 9)

x = serial number digit (0 - F hexadecimal)

* = special character (0 - 9, a - z, or A - Z, alphanumeric characters)

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.

5.73 Single Slot Enhanced DCM (Release 28.1) (IP7 Release 6.0)

The dual-slot DCM card (870-1945-03) occupies two slots on the EAGLE; the single slot EDCM (SSEDCM, 870-2372-01) card occupies only one slot. Unlike the DCM Card, the single slot EDCM card can be provisioned in any slot. Only IPLIMx and IPGWx applications are allowed to run on the single slot EDCM Card. The DCM card can always be hot-swapped with a single slot EDCM card.

Refer to the NSD Hardware Manual for current details of the SSEDCM.

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.

5.74 SIP Application - FAX and MODEM URI Support and Configurable Thresholds (Release 46.0)

The SIP Application - FAX and MODEM URI Support and Configurable Thresholds feature adds support of FAX and MODEM as allowed schemes in SIP URI to perform Number Portability lookup on SIP INVITE message in the SIP application. The user can configure thresholds for the throughput limits. Alarms are raised based on the limits specified by the user.

5.75 SIP NP Feature SIPOPTS Enhancements

These SIP NP enhancements add new values GRNASD and RNGRNDN for the SIPOPTS Parameters RNFMT and NPRSPFMT to support new format options for the RN parameter and the Contact header URI in the SIP 302 response.

The chg-sipopts command was updated to support these enhancements.

See SIP Number Portability Configuration in Database Administration – Features User's Guide for more information.

5.76 SIP NP on SLIC Network Redundancy Enhancement (Release 46.5)

This feature introduces network communication redundancy on the SLIC card. Four network interfaces will support SIP - two for ExAP communication and two interfaces for signaling. One SLIC card running the SIP application can connect to two ExAPs and two signaling networks at the same time. Interface A/D is used for ExAP connectivity, and interface B/C is used for the signaling network.

Figure 5-20 SIP on SLIC Network Redundancy Model


img/c_slic_network_redundancy_model.jpg

See Database Administration - Features User's Guide for more information.

5.76.1 Hardware

Ethernet Interface A and D are used for ExAP connectivity on SLIC cards.

Ethernet Interface B and C will be used for signaling network connectivity on SLIC cards.

5.77 SIP Number Portability (Release 45.0)

The SIP Number Portability feature provides SIP-based Number Portability using the RxDB (RIDB or RTDB) of the EAGLE. This feature adds a SIP interface to allow SIP NP requests to be received by an EAGLE card and processed by the RxDB. A response is then returned to the requestor. A new SIPHC GPL supporting a SIP stack over TCP is added. The new SIPHC GPL runs on E5-SM8G-B.

The EAGLE supports configuring SIP cards with EPAP, with ELAP, or with EPAP and ELAP on the same system. The SIP Number Portability feature can co-exist with all other EPAP-based and ELAP-based applications. The SIP cards handle only SIP traffic. No other SCCP traffic is handled by the SIP cards.

SIP Performance

  • TCP is the supported protocol.
  • The supported rate is 500 TPS per card. Sending unsupported SIP messages may degrade this rate.
  • The maximum traffic supported per card is 500 TPS. A customer provided load-balancer may be required, in front of the STP SIP cards, in order to load-share the traffic between the cards and the sites. For more information on load sharing, see the "SIP Redundancy" section in Database Administration Manual - Features.
  • Card Protection/Traffic Protection is not guaranteed and may have unpredictable results if the traffic exceeds 500 TPS.
  • Note:

    A UIM 1439 will alarm if SIP card reaches or exceeds 100% of capacity.

5.77.1 Feature Control Requirements

  • FAK for Part Number 893-0406-01
  • The feature cannot be turned off after it has been turned on.

5.77.2 Hardware

The SIPHC GPL allows only E5-SM8G-B cards to be provisioned as Service Module cards. If any card other than an E5-SM8G-B card is plugged into a card slot configured as SIPHC GPL, the card will be auto-inhibited.

5.78 SIP Stack Improvements (Release 46.0)

The SIP Stack Improvements feature replaces the existing SIP stack with a faster and more stable SIP Stack into EAGLE.

5.79 SLAN on E5-ENET Assembly (Release 37.0)

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.

Note:

The DCM, SSEDCM, EDCM-A, and E5-SLAN cards run the stplan application. The vwxslan application is no longer used.
Because the DCM card and the E5-SLAN card are both provisioned with card type dcm and the stplan application, the two cards can be “hot-swapped” without re-provisioning the card information in the system.

Note:

Hot-swapping the DCM and E5-SLAN cards requires cable adaptors.

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.

5.80 SLS Bit Rotation on Incoming Linkset (Release 40.0)

The SLS Bit Rotation on Incoming Linkset (ISLSBR) feature allows the EAGLE 5 ISS to rotate the 4 least significant bits (LSBs) of the signaling link selection (SLS) field, according to the linkset of the incoming message. This ability allows traffic to be fairly distributed across links and linksets. If selected, this rotation applies to all ITU and ANSI messages.

Note:

ANSI messages use a 5 or 8 bit SLS value. This feature allows bit rotation for only 4 of the bits.

This feature modifies only the link selection algorithm. The value of the SLS field is not changed.

SLS Bit rotation is performed only once for an ITU message. If both incoming and outgoing SLS rotation is selected for an ITU message, then incoming SLS rotation takes precedence over outgoing SLS rotation.

5.80.1 Feature Control Requirements

The ISLSBR feature has the following feature control requirements:

  • FAK for part number 893-0265-01
  • A temporary FAK cannot be used to enable the feature.
  • The feature cannot be turned off after being turned on.

5.81 SMSREQ Handling for Migrated or Ported Subscribers (Release 41.1)

The A-Port, IGM, MNP CRP, and MT-based IS41 SMS NP features are enhanced to support MTP-routed SMSREQ messages. If the SMSREQ message cannot be processed by any of these features, then the SMSREQ is MTP routed.

5.82 SMS-MO Blocking SCCP Spoofing (Release 46.3)

The SMS-MO Blocking SCCP Spoofing feature allows a consistency check between the SCA (service center address) in the SCCP part and SMRPDA/SMRPOA in the MAP part in order to manage and prevent SMS fraud. These validations are provisioned using MAP parameter based routing above the existing TCAP based Routing and FLOBR.

5.83 SNMP Interface on EPAP (EPAP 16.0)

With the SNMP Interface on EPAP feature, the EPAP can be managed directly by an Element Management System (EMS) in the standard SNMP interface. The SNMP Interface on EPAP feature supports the following:

  • Configuration of EMS is allowed with various parameters from the epapconfig utility.
  • The EPAP sends SNMPv2c trap messages to the configured EMS on the basis of the configurable parameter SNMP Alarm Feed. If SNMP Alarm Feed is set to on, the traps are sent to the EMS. If SNMP Alarm Feed is set to off, the traps are not sent to the EMS. SNMP trap messages can be sent to a maximum of five EMSs.
  • The EMS can receive and set the value of one MIB element resyncVar.
  • The EMS can resynchronize its alarm database with the active alarms on the EPAP by sending a SET request to the EPAP to set the object value of resyncVar to 1.

All alarms can be reported via this SNMP Northbound Interface. Visual alarms are allowed in the GUI, and also reported via the SNMP Northbound Interface.

5.84 SNMPv3 support for interface towards OCEEMS (Release 16.2)

EPAP supports SNMPv3 security enhancement and user/group management, secure alarm synchronization with SNMPv3 Oracle Communications EAGLE Element Management System (OCEEMS), and traps tailored to SNMPv3. This version of the protocol introduces enhanced encryption and secured authentication mechanisms.

EPAP will interact with OCEEMS or other Network Management Systems (NMS) in the SNMP interface to send traps in SNMPv3 as well as existing the SNMPv2c mode. It also provides security services by User-based Security Model (USM) and View-based Access Control Model (VACM) in SNMPv3 mode.

Enhancement from SNMPv2c to SNMPv3 include:

  1. SNMP global mode - EPAP provides three different modes for SNMP support:
    • SNMPv2c only
    • SNMPv3 only
    • Both SNMPv2c and SNMPv3
  2. SNMP configuration with various parameters from the epapconfig menu
  3. Trap forwarding to OCEEMS in the format of SNMPv3 as well as the existing SNMPv2c
  4. Alarm resynchronization between EPAP and OCEEMS in the format of SNMPv3 as well as the existing SNMPv2c:
    • Supports SNMP GET and SET of the resyncVar MIB element
  5. SNMP v3 security model support:
    • SNMPv3 views (Read/Write for EPAP MIB variables), groups and users management

See Administration Guide for more information.

5.85 Spare Point Code (Release 31.12)

The EAGLE ITU International/National Spare Point Code feature allows a network operator to use the same Point Codes across two networks (either ITU-I or ITU-N). The feature also enables National and National Spare traffic to be routed over the same linkset. The EAGLE uses the MSU Network Indicator (NI) to differentiate the same point code of one network from the other. In accordance with the SS7 standard, unique Network Indicator values are defined for ITU-I, ITU-N, ITU-I Spare, and ITU-N Spare Point Code types.

The EAGLE currently provides full support for four types of point codes:

  • ANSI, ITU-National (NI=10binary )

  • ITU-National 24-bit

  • ITU-International (NI=00 binary )

  • ITU National Spare PCs (NI=11 binary ) can be primarily supported via a combination of the following two items:

  1. Support for ITU-National Spare can be set on a per linkset basis using the linkset NIS parameter. If set, the EAGLE will allow receipt of messages with NI=11binary on the designated linkset and will force all outgoing messages on that linkset to have NI=11binary.

  2. The Duplicate Point Code routing feature, combined with the Multiple Point Code Support feature, can be used to create a separate routing group for a National Spare Point Code network.

While these two functions can be combined to support ITU National Spare Point Code routing, there are limitations described as follows:

  • The EAGLE cannot distinguish between messages with different network indicators received over the same linkset. For example, the EAGLE will route a message with DPC = 1-1-1 (NI=10binary ) the same way as a message with DPC = 1-1-1 (NI=11binary ).

  • Forcing the user to use the Duplicate PC Routing feature requires that all linksets in the system be placed in one of the defined groups.

The Spare Point Code Support feature addresses the above limitations. by The feature provides a new PC sub type named Spare. The spare point code supports the ITU-N Spare and ITU-I Spare Point Code feature.

Additionally, this feature requires a single linkset to support multiple outgoing network indicators (e.g. 11 binary, 00 binary ). In turn, messages are routed according to the Point Code on the outgoing node that corresponds to the associated network indicator.

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.

5.86 Split Allowed CGPA Table (Release 22.0)

The Allowed CGPA screen has been changed in Release 22.0 to allow for different next screening values depending on the value of the routing indicator (ri) parameter. These options are summarized in Table 5-19.

Table 5-19 Next Screening Options for the Allowed CGPA Screen

RI NSFI

GT, *

STOP, TT

DPC, *

STOP, CDPA

The messages can be screened on the routing indicator (RI) field. In previous releases, the routing indicator was included in the Allowed CGPA screening entry, but was not part of the screening process. This allowed only one message routing indicator value, or range of values, for each Allowed CGPA entry with a specific sr/ni/nc/ncm/sccpmt/ssn parameter combination. In Release 22.0, different routing indicator values can be specified for an Allowed SIO entry with a specific sr/ni/nc/ncm/sccpmt/ssn parameter combination, along with different next screening values for each entry. For example, the Allowed SIO screen in Release 22.0 can contain the following entries.

Output Example


RLGHNCXA03W 97-06-07 15:58:16 EST Rel 22.0.0
SCREEN = ALLOWED CGPA
SR    NI       NC       NCM      SSN      RI   SCCPMT   NSFI    NSR/ACT
IEC   240      001      010      012      DPC  017      CDPA    NSR1
IEC   240      001      010      012      GT   017      TT      NSR2

5.87 Split of Allowed SIO Table (Release 22.0)

The Allowed SIO screen has been changed in Release 22.0 to allow for different next screening values depending on the value of the service indicator (si) parameter. These options are summarized in Table 5-20.

Table 5-20 Next Screening Options for the Allowed SIO Screen

SI NIC PRI H0 H1 NSFI

00

single value or wildcard

single value, range, or wildcard

single value, range, or wildcard

single value, range, or wildcard

DESTFLD, DPC, BLKDPC, STOP

01, 02

single value or wildcard

single value, range, or wildcard

single value, range, or wildcard

single value, range, or wildcard

DPC, BLKDPC, STOP

03

single value or wildcard

single value, range, or wildcard

Not Specified

Not Specified

CGPA, CDPA, DPC, BLKDPC, STOP

04 - 15

single value or wildcard

single value, range, or wildcard

Not Specified

Not Specified

DPC, BLKDPC, STOP

Also in Release 22.0, messages can be screened on the message priority (PRI) field. In previous releases, the message priority was included in the Allowed SIO screening entry, but was not part of the screening process. This allowed only one message priority value, or range of values, for each Allowed SIO entry with a specific sr/si/nic/h0/h1 parameter combination. In Release 22.0, different message priority values can be specified for an Allowed SIO entry with a specific sr/si/nic/h0/h1 combination, along with different next screening values for each entry.

5.88 S-Port Subscriber Differentiation (Release 42.0)

The Service Portability (S-Port) Subscriber Differentiation feature allows multiple routing numbers to be provided for a subscriber. This functionality allows different processing to be performed on different groups of subscribers.

This feature uses the Additional Subscriber Data (ASD) as the subscriber’s private routing number (for message relay features) and the Generic Routing Number (GRN) as the subscriber’s public routing number (for query/response features). If ASD is not provisioned, then subscribers follow standard S-Port processing using the GRN.

The feature overrides the S-Port application of the GRN by using the ASD, if present, for call flows resulting in message relay.

5.88.1 Feature Control Requirements

  • FAK for Part Number 893-0379-01
  • The S-Port feature (Part Number 893-0343-01) must be enabled before the S-Port Subscriber Differentiation feature can be enabled.
  • A temporary FAK cannot be used to enable the S-Port Subscriber Differentiation feature.
  • The S-Port Subscriber Differentiation feature cannot be turned off after it has been turned on.
  • The INP feature (Part Number 893-0179-01) with the MR service, Info Analyzed Relay Number Portability feature (Part Number 893-0261-01), MO-based GSM SMS NP feature (Part Number 893-0194-01), MO-based IS41 SMS NP feature (Part Number 893-0195-01), or Prepaid IDP Query Relay feature (Part Number 893-0160-01) must be turned on before S-Port Subscriber Differentiation processing can occur.

5.89 SS7 Firewall Enhancements (Release 46.6)

The SS7 Firewall Enhancements feature is a combination of several enhancements for the SS7 Firewall feature. These enhancements include the following:

  • Display GTTSETIDX in RTRV-GTTSET command - Adds GTT set index (setdix) column to the rtrv-gttset command output. This allows GTT set information to be retrieved based on the GTT index number. Up to 7 setidx can be specified in the list.

  • GTT Per Path Measurement feature enhancement -

  • RTRV-GTA should allow any combination of PKGTYPE, ACN, and OPCODE - The rtrv-gta command allows any combination of the pkgtype, acn, and opcode parameters.

  • Segmented XUDT first segment support in TOBR and MAP Based Routing - The TOBR feature is able to decode a partial TCAP segment in the first segment of a segmented XUDT message. It will try to decode the TCAP package Type with the ACN or Opcode, or both, and apply the TOBR feature on that MSU.

  • Traffic volume measurements on individual rules/GTTSets - Introduces two (2) measurement registers per GTTSet. One register shows MSUs that don't have any matching rule. The second shows all MSUs for which a matching rule was found and the rule has the option to count MSUs.

  • Treat differently by SCCP message type - Provides the ability to apply separate routing or security rules based on the SCCP message type.

5.90 SS7 Firewall on EAGLE (Release 46.3)

The SS7 Firewall feature provides a set of capabilities to monitor, throttle or validate messages. This feature enhances the existing FLOBR/TOBR/GTT Actions framework to support more parameters in the selection criteria (DN, IMSI, VLR Nb, etc.). This feature also creates a new logging engine to feed a "Network Security" log and adds Throttling to a destination feature.

See Database Administration - GTT User's Guide for more information.

5.90.1 Hardware

The SS7 Firewall Logging functionality is supported on the E5-ENET-B card. A maximum of 5 IPS cards can be configured per EAGLE. A maximum of 2 IPS cards are allowed to be provisioned as SFLOG type.

Logging IPS cards will use Ethernet Interface Port A for IP connectivity.

5.91 SS7 Firewall - Stateful Applications (Release 46.6)

SS7 Firewall - Stateful Applications allows the Signaling Transfer Point (STP) to validate the messages coming in for a subscriber roaming out by validating them against the Visitor Location Register (VLR) the subscriber was last seen by the Home Location Register (HLR). Once the HLR provides a validity of the new VLR, the EAGLE then lets the message into the network. If the message is not validated, it is handled per configuration (either silent discard, fallback, or respond with error).

The interaction of the Stateful Applications card in EAGLE is depicted in the following figure. The message forwarding from LIM to SFAPP cards will only work with IPSG+GTT SLIC cards. For IPSG-only SLIC cards, messages will be forwarded to the SCCP cards, which will then forward the message to the SFAPP SLIC cards:

Figure 5-21 Call Flow for VLR Validation


img/stateful-apps-call-flow-vlr.jpg

As seen in the previous figure, VLR Validation uses the information stored in the HLR about the current VLR to validate the VLR from which the message is received.

Figure 5-22 Call Flow for Velocity Check Using ATI


img/stateful-apps-call-flow-velocity-check.jpg

As seen in the previous figure, Velocity Check using ATI uses the information stored in the HLR about the current VLR and the age of location parameter to identify if the new VLR is reachable from the current VLR, stored in HLR.

This use case is dependent on the validity of the information stored in the VLR and the T3212 timer (periodic update location timer). In case the time distance between two networks is less than the value of T3212 timer configured for the network, this use case test would provide false positives.

See Stateful Applications User's Guide for more information.

5.91.1 Hardware

SS7 Firewall - Stateful Applications is only compatible with SLIC hardware.

SS7 Firewall - Stateful Applications is only supported on the 64-bit flash GPL.

5.92 SS7 Firewall (Stateless Screening Enhancements) (Release 46.6)

The SS7 Firewall (Stateless Screening Enhancements) feature adds support for the following operations in MAP Based Routing:

  • PurgeMS
  • RestoreData
  • Reset
  • RegisterSS
  • USSD-Request
  • USDD-Notify
  • SAI
  • CheckIMEI
  • PSL
  • SubscriberLocationReport
  • UpdateGPRSLocation

This feature also adds support for IMEI as a parameter. See Database Administration - GTT User's Guide for more information.

5.93 SS7 Message Rejection Due to Screening (Release 22.0)

The EAGLE produces these UIMs to alert the user that an MSU has been discarded because of gateway screening.

UIMs

  • UIM 1005 — GWS rcvd OPC that is not allowed

  • UIM 1006 — GWS rcvd DPC that is not allowed

  • UIM 1007 — GWS rcvd OPC that is blocked

  • UIM 1008 — GWS rcvd DPC that is blocked

  • UIM 1009 — GWS rcvd SIO that is not allowed

  • UIM 1010 — GWS rcvd a priority that is not allowed

  • UIM 1011 — GWS rcvd TFC, AFTPC not in routing tbl

  • UIM 1012 — GWS rcvd Clg Party that is not allowed

  • UIM 1013 — GWS rcvd Cld Party that is not allowed

  • UIM 1014 — GWS rcvd Translation Type not allowed

  • UIM 1015 — GWS rcvd SCMG with not allowed AFTPC

These messages cannot be received at the SEAC unless the SEAS port is configured to receive unsolicited system maintenance messages. In release 22.0, when any of these UIMs are generated, the REPT-SCRREJ message is sent to SEAS, regardless of the configuration of the SEAS port to alert the user at the SEAC that the EAGLE has discarded an MSU because of gateway screening.

This feature allows the user to limit how many of these UIMs are sent to the EAGLE terminals and how many REPT-SCRREJ messages are sent to SEAS. This limit is configured with the set-scrrej-prmtrs command to control the number of UIMs sent to the EAGLE terminals, and with the SET-SCRREJ-PRMTRS command function on the SEAS interface to limit the number of REPT-SCRREJ messages are sent to SEAS.

5.94 SS7 over High-Speed Signaling Link (Release 23.0)

The ATM high-speed signaling link feature introduces signaling links transmitting at 1.544 Mb/s. Before Release 23.0, the fastest transmission speed on a signaling link was 64 kb/s. This feature uses the ATM (asynchronous transfer mode) protocol to implement this feature. ATM is a specific packet-oriented transfer mode that uses an asynchronous time-division multiplexing technique to multiplex information flow in fixed blocks called cells.

Tekelec’s implementation of ATM differs from the Bellcore ATM model in these ways.

  • The AAL5CP protocol support (primarily segmentation and reassembly of user data PDUs) is provided by the hardware, from the AATM applique of the high-speed ATM signaling link card, not from the software. The AATM applique also provides CRC10 support for OAM F5 ATM cell flows.

  • The ATM driver is not a defined block in the protocol model, but is needed in the Tekelec implementation to control and interface with the AATM applique. The ATM driver provides the software interface to the AAL5CP hardware functionality. The ATM driver also provides the ATMM (ATM layer management) functions that are supported in the EAGLE.

  • As a part of providing new ATM (MTP-level 2 equivalent) functions into the existing EAGLE software (based on MTP-3 and MTP- 2, not MTP-3 and SAAL), some of the interfaces to and from MTP level 3 are to and from the MAAL (management ATM adaptation layer), rather than the SSCF (service specific coordination function) handling all MTP-3 interaction.

5.95 SS7-Over-IP Gateway for Point-to-Point Links (IP7 Release 1.0)

This feature allows the use of an IP network in place of point-to-point SS7 links to carry SS7 MSUs. For example, the C links between a mated pair of STPs or B/D Quad links between STPs can be replaced by an IP transport network with gateway STPs deployed on both ends of the link. The gateway converts the SS7 MSUs to IP packets on one end of the link and IP packets to SS7 MSUs on the other end of the link. Full MTP level 3 functionality is provided with this feature.

Figure 5-23 STP Connectivity via MTP over IP

img/c_ss7_over_ip_gateway_for_point_to_point_links_ip7_release_1_0_prf-fig1.jpg

This feature provides single TCP/IP point-to-point connectivity by way of a new GPL, IPLIM, running on the DCM which, together with the hardware, provides a TCP/IP point-to-point connection to carry SS7 traffic.

To provide point-to-point connections, a number of administration steps must be performed, as follows:

  • Links, link sets, destinations, and routes to those destinations via the existing EAGLE SS7 administration capabilities must be configured.

  • Socket connections that should be created at each IPLIM card must be configured.

Unlike the point-to-multipoint configuration, the user is not required or allowed to configure SS7 Routing Key associations for IPLIM socket connections. A single socket exists on the DCM card running the IPLIM application. All SS7 traffic is carried over the single socket.

5.96 SS7 SCCP-User Adaptation Layer (SUA) Request for Comment (RFC) (Release 31.10)

The current SUA Draft Version 3 support on the IPGWx GPL will be enhanced to comply with SUA RFC with the following feature highlights:

  • SUA Draft Version 3 support on the IPGWx GPL is REPLACED with support for SUA RFC

  • Support SCCP Connectionless messages via SUA CLDT and CLDR. Connection Oriented messages are not supported

  • Support SUA Signaling Network Management Messages

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

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.

5.97 Standalone PDB on EPAP (EPAP 16.0)

This enhancement allows the EPAP to operate in a standalone mode with only the Provisioning Database (PDB). An EPAP operating in standalone or PDB-only mode runs on a single E5-APP-B server. Geographical redundancy is permitted, which allows the Active and Standby PDB in different locations. An EPAP can operate without a local mate. This enhancement also increases the PDBI performance.

EPAP operating both PDB and Real-time Database (RTDB), or Mixed EPAP, continues to be available. EPAP operating in standalone mode, or PDB-only mode, is optional and must connect to a non-provisioning EPAP with RTDB to load the EAGLE Service Module cards. The PDB-only EPAP software supports all interfaces currently available in Mixed EPAP configurations related to PDB or Operations and Maintenance (O & M). Both mixed EPAP mode and standalone (PDB-only) mode support a maximum of 22 non-provisioning sites (44 servers). When PDB and RTDB coexist on the provisioning EPAP pair, the limit increases to 48 servers.

5.98 STC on E5-ENET Assembly (Release 37.0)

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.

Note:

Hot-swapping the SSEDCM and E5-STC cards requires cable adaptors.

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.

5.99 STP LAN Feature (Release 20.0)

The EAGLE STP LAN feature allows the EAGLE to support a TCP/IP connection from any interface shelf to external hosts. Message signal units (MSUs) processed by the EAGLE can be copied and directed through the LAN interface to an external server or microcomputer application.

The STP LAN feature is an optional feature that is off by default. To use the STP LAN feature, it must be turned on by entering the appropriate command. Once this feature is turned on, it cannot be turned off.

This feature requires a new circuit card, the application communication module (ACM) card. The ACM card provides an Ethernet interface at the interface shelf backplane and the processing power required to support message encapsulation and TCP/IP support.

The Ethernet connection uses an adapter that is connected to a single port media access unit (MAU). The MAU is attached to the backplane interface connector of the ACM and supports standard Ethernet function.

From the MAU, the user may attach any compatible host system. The host system must be using TCP/IP as the higher layer protocol and must support 10BASE2 Ethernet as the transmission method.

The EAGLE software on the ACM card receives SS7 MSUs from the LIMs and ASM-SCCP cards and copies those MSUs into memory on the ACM card. The copied MSU is encapsulated and transmitted using TCP/IP packets and Ethernet to the host computer. The host computer is responsible for reassembling the original message and processing the data.

This feature is designed to provide an open system architecture, allowing third parties to design applications that can be attached as adjuncts to the EAGLE STP.

The gateway screening feature provides a copy function. When an MSU passes all screening criteria, the MSU is allowed to pass through the EAGLE STP out to the SS7 network. With the copy function, the MSU is copied, and the copy is sent through the STP LAN interface to a host application. This allows the host to track which MSUs from an external network were allowed to pass through the EAGLE.

The entire MSU is copied, including the MTP, which allows the host application to process the entire message. Total octet counts, including MTP level 2 and level 3, can be tallied and used for a variety of external measurements.

Messages from an X.25 signaling link reflect the translated message. The message is passed to the interface, and the screening and copy functions for an X.25 packet are invoked, after the EAGLE has completed protocol conversion. The result is an SS7 message that can be processed by the external application.

One ACM card is capable of servicing a maximum of 30 link interface modules (LIMs), regardless of the LIM type. This allocation is determined by the EAGLE’s internal load balancing algorithm that is capable of reassigning LIMs to other ACM cards in the event an ACM card should fail, or if the traffic rate to a single ACM changes significantly.

Typically you should provision extra ACM cards for redundancy. By provisioning extra ACM cards, the load balancing software ensures that when an ACM card fails, the LIMs assigned to the failed ACM card are reassigned to another ACM card, providing it has been configured. The EAGLE STP can support up to 32 ACM cards.

The IP addresses of adjacent hosts are entered into the EAGLE by using the EAGLE database administration commands. The EAGLE also provides load balancing for all ACM cards. A threshold is set through the database administration commands for each card, which determines when the EAGLE begins shedding traffic from the specified ACM card and redistributes that traffic to another ACM card.

This method of load balancing allows the user to configure each ACM card with a threshold, and provides an automatic mechanism by which traffic can be evenly distributed over multiple ACM cards. In addition to load balancing, this feature also reassigns traffic when an ACM card fails, so that all traffic can still be supported even when an ACM card fails. The ACM cards are capable of handling approximately 400 messages per card.

5.100 STPLAN Port to DCM (Release 26.0)

This feature ports existing STPLAN functionality to the DCM (Database Communications Module) hardware platform. The DCM provides the EAGLE with two 10/100 Base-Tx IEEE 802.3/Ethernet ports capable of carrying IP traffic.

This feature provides:

  • the same functionality as STPLAN on ACM

  • the same command interface

  • the same network interfaces (single 10BaseT port; no 100BaseT)

  • the same provisioning rules as for the ACM

    Note:

    The DCM is NOT a drop-in replacement for ACM. If a DCM is used as a replacement for an ACM card, the replacement is not a “plug-in” type replacement. The STPLAN card and datalink must be reprovisioned. Also, fans and a new GPL for the DCM are required.

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.

5.101 STPLAN SSEDCM Capacity Increase (Release 34.0)

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.

5.102 STPLAN with Default Router (Release 23.0)

The STPLAN application allows the user to selectively copy received messages to a remote host for further processing. The external link consists of an Application Communication Module (ACM) equipped with an Ethernet interface using the TCP/IP protocol to communicate to an external processing device. Each ACM card supports a single destination host. In previous releases, each ACM and corresponding host had to be in the same network. This feature allows messages to be sent to a remote host on a different network using a TCP/IP router between the ACM and the corresponding host. Messages destined for a host in a different network or subnetwork are sent to the default router for routing. Messages destined for a host that is in the same network as the TCP/IP data link is not sent to the router but is sent directly to the remote host. The router is not part of the EAGLE.

Figure 5-24 shows an example of using a router with the STPLAN feature. ACMs 1 and 2, with IP addresses 193.4.202.50 and 193.4.202.57, need to route their traffic to the remote host at IP address 200.11.202.44. The ACMs and the remote host are in two different networks, the network ID of the ACMs is 193.4.202 and the network ID of the remote host is 200.11.202. The EAGLE can only connect to TCP/IP nodes that are in the same network as the EAGLE. A TCP/IP router is placed in between the EAGLE and the remote host. The TCP/IP router is located in the same network as the EAGLE, with the IP address of 193.4.202.87. The messages can now be sent to the remote host through the TCP/IP router.

Figure 5-24 STPLAN Router Example

img/c_stplan_with_default_router_release_23_0_prf-fig1.jpg

The EAGLE requires that a default router be entered when the class and network ID of the data link’s IP address and the host’s IP address do not match or when subnet routing is used. The EAGLE cannot tell whether the user has deployed a large network or is using subnet routing. In a large network, no TCP/IP routers are required because all the nodes are directly connected to a single Ethernet network as shown in Figure 5-25.

Figure 5-25 STPLAN in a Large Network

img/c_stplan_with_default_router_release_23_0_prf-fig2.jpg

If a user is using subnet routing and therefore multiple Ethernet networks, TCP/IP routers are required and must be configured in the EAGLE as shown in Figure 5-26.

Figure 5-26 STPLAN Network with Subnet Routing

img/c_stplan_with_default_router_release_23_0_prf-fig3.jpg

The EAGLE cannot distinguish between a large network and the use of subnet routing, and cannot detect the omission of a TCP/IP router. For example, the IP addresses of the TCP/IP data links and the remote node are the same in Figure 5-25 and Figure 5-26. In Figure 5-25, the remote node is in the same network as the TCP/IP data links, so no TCP/IP router is needed. In Figure 5-26, the user is using subnet routing. The remote node is in one subnetwork, and the TCP/IP data links are in another subnetwork. Even though the network portion of the IP addresses of the TCP/IP data links and the remote node are the same (93, a Class A IP address), a TCP/IP router is required because the user is using subnet routing.

If, when the user is configuring STPLAN according to the network in Figure 5-26, the TCP/IP router is not configured with the ent-ip-node command, the EAGLE will not detect that the TCP/IP router has been omitted. No warnings will be given that the TCP/IP router has been omitted. The data link will be unable to function since it will not be able to connect to the TCP/IP node. The EAGLE sees the remote node as a TCP/IP node in the same network as the TCP/IP data links, because of the class of the IP addresses, and does not require the user to specify the iprte parameter of the ent-ip-node command.

5.103 SUA DAUD with SSN Support (Release 37.0)

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

The SUA DAUD with SSN Support feature has the following limitations:
  • DAUD messages that contain the SSN parameter are not subjected to the Gateway Screening service.
  • Subsystem status updates are implemented only when the route key is full SCCP (DPC-SI[3]-SSN). If a subsystem is present on a remote ASP connected by an AS that has only DPC or DPC-SI route key, then the IPGWx code does not send updates on the status for the remote subsystem to the SCCP management module.

5.104 Support >25 SCCP cards with EPAP T1200 application server (Release 42.0)

The Support >25 SCCP cards with EPAP T1200 application server allows up to 32 SCCP cards to be supported when any EPAP-based feature is turned on and an EPAP T1200 application server is used. This feature also increases the system SCCP transactions per second (TPS) to (Maximum card TPS * 32 cards).

This functionality impacts the TPS quantities implemented by the E5-SM4G Throughput Capacity feature. Table 5-21 shows the revised TPS capacities for each E5-SM4G Throughput Capacity quantity.

Table 5-21 TPS Capacities

Feature Quantity Part Number Maximum TPS Capacity per E5-SM4G Card Maximum System TPS Capacity*
893-0191-01 3125

75,000 TPS with one or more EPAP-related features and 24+1cards

96,875 TPS with one or more EPAP-related features enabled and 32 cards

5000

150,000 TPS with no EPAP-related or ELAP-related feature traffic and 31+1 cards

120,000 TPS with G-Flex and the ANSIGFLEX STP option and 24+1 cards

155,00 TPS with G-Flex and the ANSIGFLEX STP option and 31+1 cards (EPAP running on T1200 AS)

40,000 TPS with ELAP and 8+1 cards

85,000 TPS with ELAP and 17+1 cards

893-0191-02 6800

210,800 TPS with no ELAP-related or without EPAP-related feature traffic and 31 + 1 cards

163,200 TPS with one or more EPAP-related features and 24+1 cards

54,400 TPS with ELAP and 8+1 cards

115,600 TPS with ELAP and 17+1 cards

*32 cards implies an N+1 configuration, so 31 cards are used for calculating actual TPS capacity.

5.104.1 Hardware Requirements

  • All cards must be DSM or E5-SM4G cards.
  • A T1200 Application Server is required.
  • 4 Telco GigE switches are required for the EAGLE 5 ISS and EPAP inter-connection.

5.105 Support 12 Million Ported Numbers (Releases 24.0, 25.0)

This feature is not supported in initial shipments of Release EAGLE 25.0. Tekelec will issue a notice when the feature becomes available.

The Support for 12 Million Ported Numbers feature allows the EAGLE to contain and process 12 million ported telephone numbers for the local number portability (LNP) application. Before Release 25.0, the EAGLE could contain only four million ported telephone numbers.

Note:

For Release 24.0, the EAGLE supports only 4 million ported telephone numbers.

For the EAGLE database to contain up to 12 million ported telephone numbers, six lnp 4digit database objects must be in the database. Each lnp 4digit database object consists of two tables, one in the current partition and one in the backup partition of the database. The EAGLE database currently contains one lnp 4digit database object containing up to two million ported telephone numbers. This database object contains the database tables named lnp_4dig.tbl and lnp_4dig.bkp.

Refer to the Database Administration Manual - LNP and the LNPDatabase Synchronization Manual for the current details on this feature.

5.106 Support 22 Non-Provisionable EPAP Nodes (EPAP 13.0)

EPAP supports two provisionable EPAP nodes feeding up to 22 non-provisionable EPAP nodes. Each EPAP node contains two EPAP servers, or a total of 48 EPAP servers. The provisioning server should be a T1200 AS, and the non-provisioning EPAPs can be either T1000 or T1200 ASs

Hardware Requirements

A T1200 Application Server

5.107 Support Changing the Linkset Name (Release 28.0)

With this feature, the EAGLE supports changing the linkset name via an EAGLE terminal or SEAS, without having to delete or change any other data associated with the linkset (e.g. ent-ls command parameters, links, routes).

The ability to change the linkset name via SEAS is supported via the following methods:

  • A supplier-specific parameter for the chg-ls and chg-gtwyls commands

  • Flow-through

All EAGLE data that referenced the old linkset name will now reference the new linkset name, except for old entries in the security log.

5.108 Support CHG-GTT to change the GTA (Release 35.0)

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.

5.109 Support CRP check for SRI_SM using TCAP digits (Release 43.0)

The Support CRP check for SRI_SM using TCAP digits feature allows SCCP or TCAP MSISDN digits of SRI_SM messages to be used as the Directory or Dialed Number (DN) for MNP Circular Route Prevention (MNPCRP) processing performed by the MT-Based GSM SMS NP feature.

If the TCAP MSISDN is used as the DN, a Home Routing Number (RN) match is found in the incoming TCAP MSISDN digits, and the SRI_SM message is to be relayed, then the RN digits from the TCAP MSISDN are stripped before relaying the message to the Home Location Register (HLR).

5.109.1 Feature Control Requirements

The MT-Based GSM SMS NP feature (Part Number 893-0200-01) must be enabled before the Support CRP check for SRI_SM using TCAP digits functionality can be provisioned.

5.110 Support FastCopy on IPGW (Release 42.0)

The Support FastCopy on IPGW feature provides support for monitoring M3UA and SUA traffic on E5-ENET cards running the IPGHC GPL using Fast Copy-based or STC monitoring.

5.110.1 Hardware Requirements

The Fast Copy feature requires E5-ENET cards.

If Fast Copy monitoring is active, and an E5-ENET card is replaced by a DCM card, then the DCM card will perform STC-based monitoring, and any remaining E5-ENET cards will perform Fast Copy monitoring.

5.111 Support for 16 GTT Lengths in VGTT (Release 41.0)

The existing VGTT feature is enhanced to allow provisioning of 16 different GTT digit string lengths per translation type in a GTT set.

5.111.1 Feature Control Requirements

Feature control requirements for the Support for 16 GTT Lengths in VGTT feature include:

  • The VGTT feature must be turned on before the Support for 16 GTT Lengths in VGTT feature can be enabled.
  • A FAK for part number 893-0248-01
  • A temporary FAK cannot be used to enable the feature.
  • The feature cannot be turned off after it is turned on.

5.111.2 Hardware Requirements

The Support for 16 GTT Lengths in VGTT feature requires an E5-SM4G or higher card.

5.112 Support for 32 Prepaid SMS Intercept Platforms (Release 37.0)

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.

Note:

The Support for 32 Prepaid SMS Intercept Platforms feature removes the dependency of the PPSMS feature on the G-Port feature. PPSMS can now be enabled without enabling G-Port.

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.

5.113 Support for 32 Prepaid SMS Intercepts (EPAP 9.0)

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.

5.114 Support for 2000 ITU Links per Node (Release 35.1)

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.

Note:

Although the Support for 2000 ITU Links per Node feature increases the total capacity of the node, the increase applies to ITU links only. The maximum number of ANSI links that can be supported by the node remains 1500.

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

5.115 Support for 2800 Provisioned Links Per Node (Release 41.1)

The Support for 2800 Provisioned Links per Node feature extends the Large System # Links feature to allow up to 2800 SS7 links to be provisioned on an EAGLE 5 ISS node.

Current limits on the maximum number of cards and links for each application continue to be supported as shown in Table 5-22.

Table 5-22 Links and Cards Limits per Application

Application/GPL Maximum Number of Cards Maximum Number of Links/Card
IPSG 100 (E5-ENET) 32
IPLIM 100 (E5-ENET) 16
IPGW 125 (E5-ENET) 1
SS7 (ANSI/ITU)

250 (E5-E1T1)

125 (HC-MIM)

64 (HC-MIM)

32 (E1/T1)

64 (E1/T1)

2 (SE-HSL)

ATM 90 (E5-ATM) 2
VSCCP 32 N/A
GLS 8 N/A
STPLAN 32 N/A

5.115.1 Feature Control Requirements

  • The Large System # Links feature (Part Number 893-0059-11) must be enabled
  • If any card other than those provided in the Hardware Requirements section is present in the system, then the feature cannot be enabled.
  • This Large System # Links feature is an enable-only feature. Once enabled, the default status of the feature is ON.
  • The feature cannot be turned off after it is enabled.
  • A temporary FAK cannot be used to enable the feature.

5.115.2 Hardware Requirements

  • The following cards are supported with 2800 links on an EAGLE node:
    • HC-MIM
    • E5 E1/T1
    • E5-ATM
    • E5-SM4G
    • E5-ENET
    • E5-OAM
    • HIPR
    • SLAN (SSEDCM and E5-SLAN)
    • STC (SSEDCM and E5-STC)
    • MCPM
    • IPSM/E5-IPSM
    • TSM/E5-TSM (for GLS)

    If any other card is installed after the feature is enabled, then the card is auto-inhibited.

  • The active and standby OAM cards must be based on E5-OAM.

5.115.3 Limitations

Certain card types and link types combinations prevents achievements of 2800 links capacity. Refer to Table 5-22 for the current limits on card and link types.

5.116 Support for IP7 8.0 Gateway Features (EAGLE Release 30.0/IP7 Secure Gateway Release 8.0)

Description

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

5.117 Support for IPSG M3UA and SCTP Graceful Shutdown (Release 41.0)

The Support for IPSG M3UA and SCTP Graceful Shutdown feature consists of two aspects:

  • M3UA Graceful Shutdown

    The ipsg application is updated to increase the shutdown timer to 2 seconds, which allows the ASP to deplete all the messages from its queue before the ASP is brought down. The M3UA software is also enhanced to progress the shutdown when a designated response is received from a peer.

  • SCTP Graceful Shutdown

    SCTP functionality of the ipsg application is updated to allow manual initiation of graceful shutdown for an M3UA association.

5.117.1 Hardware Requirements

M3UA and SCTP shutdown is performed on only E5-ENET cards running the ipsg application.

5.118 Support for LSMS Audit Enhancements (Release 26.1)

LSMS users need a method of auditing locally provisioned data as well as data that is sent from the NPAC to the LSMS and subsequently sent to the EAGLE. Currently the following data cannot be audited from the LSMS and raises concerns about database consistencies.

  • Default GTT

  • Override GTT

  • NPA-NXX Split Data

This feature provides support for the LSMS audit of default GTT, override GTT, and NPA-NXX split data residing at the EAGLE. The LSMS audits the data, which is locally provisioned at the LSMS, against the data at the EAGLE LNP databases. EAGLE support allows LSMS retrieval of the data from the EAGLE database. (The LSMS will offer a mechanism to reconcile any discrepancies detected.)

In previous releases, even though the EAGLE allows the LSMS to provision Default GTT, Override GTT, or service provider database entries, it provided no mechanism to allow the LSMS to retrieve the DB entities that it has provisioned. This hampered the LSMS from determining exactly what was present in the EAGLE LNP DB for these entity types: the LSMS could add and delete these entity types, but could not retrieve them.

This feature rectifies this situation by adding the following new commands to facilitate additional auditing capabilities at the LSMS:

  • vfy-lnp-6ddt

  • vfy-lnp-lrnovr

  • vfy-split-npa

These commands are used similarly to the existing vfy-lnp-10dt command:

  • They are sent by the LSMS to the EAGLE via the OAP across the OAPEAGLE serial interface (also known as the "2 TN/sec channel," or the "slow channel").

  • They support retrieval of a single DB entity (see section 3.1.2 on page 13)

  • The command response is returned to the LSMS via the OAP, and is formatted similarly to the vfy-lnp-10dt output (i.e. machine-readable).

See Component Interaction Scenario more information on these commands.

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

img/c_support_for_lsms_audit_enhancements_release_26_1_prf-fig1.jpg

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 LSMSEAGLE 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).

5.119 Support for LSMS Split Provisioning (Release 26.1)

NPA-NXX splits currently are provisioned locally at the LSMS and at the EAGLE. This is not the optimum method of provisioning LNP data, as the LSMS can service multiple EAGLEs, making coordination of entering split data cumbersome.

This feature allows NPA-NXX Split data to be provisioned at the LSMS and forwarded to the EAGLE, instead of being provisioned at the EAGLE separately. This feature supports a single point NPA Split administration from the LSMS.

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 EAGLELSMS 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).

5.120 Support for Matching Self-ID Rule in SEAS CHG-SID (Release 22.0)

In previous releases the SEAS ASGN-SID and CHG-SID command functions could change the self ID point code and CLLI of the EAGLE if either SEAS command were entered. From the SEAS interface, only the ASGN-SID command function can change the point code and CLLI of the self ID. The CHG-SID command function is not supposed to change the point code or CLLI of the EAGLE, but those parameters are used to verify whether they match the current point code and CLLI of the EAGLE.

This feature adds a rule to the SEAS CHG-SID command function on the EAGLE that requires that the specified point code and CLLI to match the current self ID point code and CLLI of the EAGLE. If they do not match the current values, the CHG-SID command attempt is rejected.

This gives customers using the SEAS interface protection against accidental changing of the EAGLE’s self ID. This feature does change the functions of the SEAS ASGN-SID and EAGLE chg-sid commands.

5.121 Support for MTP Status Functions (IP7 Release 2.0)

This feature, available only on DCM cards that support the ss7ipgw application, allows the Message Transfer Part (MTP) status of point codes in the SS7 networks to be made available to IP-connected media gateway controllers (MGCs) and IP-SCPs. This feature is similar to the MTP3 network management procedures used in an SS7 network.

This feature enables an IP device to:

  • Divert traffic from an SG that is not able to access a point code that the mated SG can access

  • Audit point code status

  • Build up routing tables before sending traffic

  • Be warned about SS7 network congestion

  • Abate congestion

  • Obtain SS7 User Part Unavailability status

5.122 Support for Provisioning Multiple EPAPs (Release 29.0)

Currently, it is only possible to provision a single mated pair of MPS nodes, where each MPS node contains one EPAP A and one EPAP B. EPAP A contains a PDB and an RTDB. EPAP B contains only an RTDB. For customers who need to deploy more than one pair of MPSs, this requires them to provision each pair separately.

Many customers desire the ability to add more MPSs without having to change their provisioning system, or provision from multiple sources.

This feature is transparent to the PDBI clients. Each client can provision data in the same manner, no matter if it is provisioning a single MPS pair, or multiple MPS pairs.

With EPAP 3.0, customers may choose to add EAGLEs to their network without changing the way that they provision data. EPAP Software updates the Real-time databases at the additional sites. The two MPSs that contain the PDB are called "provisionable" because these are the sites to which the customer provisioning application may connect. The additional MPSs are called "non-provisionable."

Newly added non-provisionable MPSs will use the Selective Homing of EPAP RTDBs feature to specify the PDB(s) from which to receive updates.

Hardware Requirements

The MPS platform is required to support the ability to install both provisionable and non-provisionable EPAP MPSs.

Enhancements to the User Interface

With the addition of Support for Provisioning multiple EPAP RTDBs, references to the "Local" and "Remote" PDB may no longer have meaning. These references will be changed throughout the text UI and GUI to specify the IP address of the PDB being identified.

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. Interaction with EAGLE is not affected by this feature.

5.123 Support for SCCP XUDT/XUDTS Messsages, In-Sequence Delivery of Class 1 SCCP UDT/XUDT Messages (Release 31.6)

Description

With the introduction of various new applications in the wireless industry, the size of application data on top of SCCP layer has increased to a point where it does not fit in a single MTP message. This has led to the requirement of segmentation and reassembly of the SS7 messages - both at SCCP level and at higher application levels (like TCAP). These messages are carried over SCCP class 0 protocol and SCCP class 1 protocol. Class 1 is used when the sequence of the segments of the message and number of message within the same transaction or dialogue needs to be guaranteed at the arriving node.

The EAGLE distributed architecture and internal method of load sharing across SCCP processing cards means that one message of a sequence could arrive at one SCCP card for processing, while another message in the same sequence could arrive at a different SCCP card for processing. Depending upon the current loads and buffer levels in the two SCCP cards, it is possible that the second message may complete SCCP processing and arrive at the outgoing link ahead of the first message. Thus, the second message will arrive at the destination before the first, and the end node will be unable to process the sequence.

The In-sequence Delivery of SCCP Messages feature addresses the in-sequence delivery requirement of SCCP protocol class 1 message.

The Support of SCCP Extended User Data (XUDT)/Extended User Data Service (XUDTS) messages feature addresses the processing of EAGLE destined XUDT/XUDTS messages and in-sequence delivery requirement of SCCPXUDT/XUDTS protocol class 1 messages.

Long User Data (LUDT)/Long User Data Service (LUDTS) messages along with other non-UDT/XUDTSSCCP messages will not be supported by SCCP. UIM 1023 is generated on the incoming LIM card when LUDT/LUDTS messages is received and is destined to EAGLE. MTP routed LUDT/LUDTS messages will continue to be supported by EAGLE. However, GWS, TT mapping and Network Security features will not support LUDT/LUDTS messages.

EAGLE support is provided for the following features and functions when processing XUDT/XUDTS messages:

  • GTT, EGTT, VGTT

  • All supported link types, including E1/T1MIM, E1-ATM HSL, IPLIMx, and IPGWx

  • Multiple and duplicate point codes

  • SLAN and Sentinel Copy

  • G-Flex

  • LNPMR services for Class 1 UDT messages

  • INMPR services (but not INPQ)

  • G-Port, G-Port Message Relay, and IS-41 to GSM Migration - XUDT/XUDTS messages are supported as long as the G-PortGSNSRI or PPSMS query or IS-41 Loc Req messages are not segmented. If a query is segmented, it will treated as a G-Port non-SRI or IS-41 non-Loc REq message and message relay will be performed using the SCCPCDPA portion of the message.

The In-sequence delivery of SCCP messages feature addresses the in-sequence delivery requirement of SCCP protocol class 1 message.

The Support of SCCPXUDT/XUDTS messages feature addresses the processing of EAGLE destined XUDT/XUDTS messages and in-sequence delivery requirement of SCCPXUDT/XUDTS protocol class 1 message.

  • Both ANSI and ITU Class 1 UDT and XUDT/XUDTS (both Class 0 and Class 1) messages are supported.

Limitations

  • The NP, EIR, LNP, PPSMS, MNPSMS and MAP Screening features that use TCAP data do not support XUDT/XUDTS messages.

  • EAGLE does not perform re-ordering of XUDT/XUDTS Segmented messages.

  • EAGLE does not perform any conversion of XUDT/XUDTS to UDT message and vice versa.

  • The Weighted SCP Load Balancing and IGTTLS features do not support load sharing of messages across equal cost destinations for Class 1 UDT/ XUDT/XUDTS messages (when randsls is OFF or CLASS0)

  • EAGLE supports XUDTS messages as long as the message length is <=272 bytes.

5.124 Support for Secure Gateway Functionality through IP7 7.0 (Release 29.0)

EAGLE Release 29.0 supports the feature content of IP7 Secure Gateway Release 7.0 (i.e. IP User Interface: Telnet Support and FTP Retrieve and Replace.

5.125 Support for TALI Architecture (IP7 Release 4.0)

Each release of the IP7 Secure Gateway is built to the current level of the Transport Adapter Layer Interface (TALI) protocol. This release of the IP7 Secure Gateway supports TALI Release 3.0.

5.126 Support for the CLLI Parameter for Adding or Changing Linksets (Release 22.0)

In Release 22.0, the EAGLE accepts the FE-CLLI parameter when adding a linkset, changing a linkset, and displaying linksets on the SEAS interface. The FE-CLLI of the point code is not stored in the linkset table, but in the destination point code table.

When the FE-CLLI is specified while adding a linkset or changing a linkset’s attributes from the SEAS interface, the FE-PC and FE-CLLI are compared with entries in the destination point code table of the EAGLE. If the specified values match an entry in the destination point code table, the command adding the linkset is accepted. If either value does not match any entries in the destination point code table, the command is rejected. When changing a linkset’s attributes from the SEAS interface, the FE-CLLI value cannot be changed.

The EAGLE’s linkset configuration commands, ent-ls, chg-ls, and rtrv-ls, have also been changed to support this feature. The clli parameter has been added to the ent-ls and chg-ls commands. If the value of the clli parameter, specified with either the ent-ls or chg-ls commands, does not match the value of the CLLI of the adjacent point code, shown in the destination point code table by the rtrv-dstn command, the command is rejected with this error message.

Error Message


E2335 Cmd Rej: CLLI is not identical to that of matching Destination

The output of the EAGLE’s rtrv-ls command has been changed to support this feature. The following is an example of the output of the rtrv-ls command if a CLLI has been assigned to the adjacent point code of the linkset.

5.127 Support for the New Linkset Name Parameter for Changing the Attributes of a Route (Release 22.0)

The linkset name parameter (nlsn) has been added to the EAGLE’s chg-rte command and to the SEAS CHG-RTE command function. This eliminates the requirement on the EAGLE to remove an existing linkset and re-enter the linkset with a different linkset name to change the linkset name.

Error Messages

The following error messages displayed on the EAGLE terminal have been added to the chg-rte command.

  • Either the nlsn, or rc parameters must be specified with the chg-rte command. In neither of these parameter are not specified, the command is rejected and this error message is displayed.


E2136 Cmd Rej: At least one optional parameter is required
  • The new linkset specified by the nlsn parameter cannot be assigned to any existing routes. If the new linkset is assigned to any existing routes, the command is rejected and this message is displayed.


E2355 Cmd Rej: Linkset already assigned to route
  • If a new link set name (nlsn) is specified in the chg-rte command, that link set name must be defined in the linkset table. If the new linkset name is not defined in the linkset table, the command is rejected and this error message is displayed.


E2346 Cmd Rej: Linkset not defined
  • If a new link set name (nlsn) is specified in the chg-rte command, that linkset must contain at least one signaling link. If the new linkset does not contain at least one signaling link, the command is rejected and this error message is displayed.

    
    E2128 Cmd Rej: Linkset assigned to route must have at least one link
    
  • The new linkset specified by the nlsn parameter can be assigned to an adjacent point code that is a cluster point code as long as the linkset type of this linkset is either B, C, or D. If the linkset type of the linkset that is assigned to a cluster point code is either A or E, the command is rejected and this error message is displayed.


E2349 Cmd Rej: Link Set Type invalid for Cluster Destination

5.128 Support for Up to 41 IPLIMx DCMs (IP7 Release 2.2)

The IP7 Secure Gateway supports up to 41 DCMs that run either the iplim application or the iplimi application. In previous releases, the limit of DCM cards supported for the iplim application was six.

In addition, the IP7 Secure Gateway can support two DCMs that run the ss7ipgw application.

5.129 Support G-Flex at 1700 TPS per DSM (ANSI only) (Release 31.6)

This feature allows the DSM card to run at 1700 TPS when the G-Flex feature is turned on in an ANSI environment. Only G-Flex can be on to achieve the 1700 TPS per DSM.

This feature provides an STP option to allow the DSM card to run at 1700 TPS when the G-Flex feature is turned on in an ANSI environment.

Limitations

  • G-Flex at 1700 TPS per DSM is supported only when G-Flex is the only database feature active and there are no ITU