Description

The signaling link selection field (SLS) in an MSU is used to balance traffic across the links in each linkset that a message passes through. The originator of the traffic can, by using the same SLS for a group of messages, guarantee that the same links are selected and guarantee that the traffic will be in sequence. In previous releases, the EAGLE evenly distributed traffic using a 5-bit SLS by using a 3-bit counter to fill in the three most significant bits in the SLS. This can result in missequencing of MSUs, as shown in the following example and figure:

1. Node 1-1-1 generates two messages with the same SLS, intending for them to be sequenced, and transmits them across link 1.

2. STP 2-2-2 converts the 5-bit SLS to an 8-bit SLS, resulting in two different SLS codes. The two messages leave STP 2-2-2 on links 2 and 3 and arrive out of order at node 3-3-3.

   Figure 2-2 Example Network for Problem Description

   

This feature ensures that when a 5-bit SLS is converted to an 8-bit SLS, the MSUs arrive at the destination node in the order that they were generated by the originating node. The EAGLE also makes these SLS conversions:

• 5-bit ANSI SLS to 4-bit ITU SLS

• 4-bit ITU SLS to 5-bit ANSI SLS

• 8-bit ANSI SLS to 4-bit ITU SLS

The EAGLE does not convert a 4-bit ITU SLS to an 8-bit ANSI SLS.

The 5-bit to 8-bit SLS conversion takes place during the routing process, after the linkset is selected, but before the signaling link is selected. The ITU to ANSI SLS conversion takes place during the ANSI to ITU MSU conversion and after the outgoing signaling link is chosen.

Signaling Link Selection Conversion

5-bit to 8-bit SLS conversion is performed under these conditions:

• The incoming linkset is an ANSI linkset

• The asl8=no parameter is assigned to the incoming linkset

• The outgoing linkset is an ANSI linkset

• The outgoing linkset has either the slscnv=on and slsci=yes parameters, or the slscnv=perls and slsci=yes parameters assigned to it

• The three most significant bits of the SLS are zero.

When an ITU SLS is converted to an ANSI SLS, the ITU SLS is always converted to an ANSI 5-bit SLS. If the MSU containing the converted SLS is rerouted because of a link outage, the SLS may be converted from a 5-bit SLS to an 8-bit SLS.

When an ANSI SLS is converted to an ITU SLS, the ANSI SLS is always converted to an ITU 4-bit SLS.

When a 5-bit ANSI SLS is converted to an 8-bit ANSI SLS, the three most significant bits of the SLS are set using a function of originating point code and incoming port. This ensures that MSUs with the same originating point code, SLS, and incoming port will always have the same SLS after the conversion, guaranteeing that the MSUs arrive at the destination in the same sequence that they were sent.

All ANSI MSUs originating from the EAGLE will have an 8-bit SLS.

Description

EAGLE Release 29.1 requires that the EPAP databases accommodate 56 million G-Flex entries. Additional disk space is being provided by way of a hardware disk replacement, from 18 GB disks to 36 GB disks. All the new space on the data disk (18 GB minus overhead) will be appended to the database file system /usr/db. The additional space on the system disk (18 GB minus overhead) will be appended to the swap space. The disk upgrade will occur during a maintenance window, when no software upgrade is scheduled.

Although this feature has been developed specifically for the EPAP, it is not application-specific. This hard drive upgrade could be performed on any MPS server running any GA release.

Upgrade Procedure

The upgrade will be performed as follows:

• The technician will label the disks in the system and the disks in the upgrade kit.

• Using Disksuite functionality, half of the old disks will be replaced with the new disks, and will sync with the remaining old disks.

• Once the disks have been sync’d, the remaining old disks will be replaced with the remaining new disks. The new disks will then sync again.

• A script will expand the /usr/db and swap file systems to use all the space available.

A backout will be performed as follows:

• The MPS will be brought to run-level zero.

• The technician will remove the 36 GB disks, install all the old disks, and remove the new disks.

• The technician will boot the MPS.

• A script will re-mirror and repair the metadbs.

Hardware Requirements

This feature requires that all four 18 GB disks on an individual MPS be replaced with 36 GB disks. (New MPS’s with the EPAP application will be manufactured with the 36 GB disks.)

Overview

The 48 Million Number feature for EAGLE Release 27.0 provides the capability to expand the number of ported numbers supported on one EAGLE platform from 12 to 48 million numbers. This feature represents both an increase in the number of ported records a single EAGLE node can support and a re-architecture of the current LNP solution (i.e. the LSMS-OAP-OAM LNP interface) for increased database update performance.

The terms MPS and ELAP are used to describe the hardware and software that is replacing the EOAP and the LNP functions of the OAM. MPS refers to the hardware and OS software of the new platform. ELAP refers to the 48 million number application running on the MPS.

This feature is optional and requires a corresponding LSMS feature.

General Description

Customer databases of Local Number Portability (LNP) data are constantly growing. EAGLE Release 27.0 and LSMS Release 4.0 introduce the 48 Million Number feature to satisfy customer database size requirements. Because of the magnitude of the database size increase, several areas of the existing EAGLE/LNP architecture have been upgraded. The following functionality has been changed and improved for Release 27.0:

• Ownership of the "master" or "golden" real-time LNP database has moved from the EAGLE OAM to the ELAP.

  The data model for the new LNP solution closely resembles that of the International LNP solution. Data is collected at the LSMS from the NPAC (for subscription data) and from local provisioning on the LSMS (for default NPANXX, split NPANXX and other types of LNP records). This data is sent to the active ELAP at an EAGLE running Release 27.0 across a TCP/IP connection in the customer's network. The ELAP stores the data locally, and replicates it to the mate ELAP. The ELAP provides real-time database loading and provisioning functions for the EAGLE DSM cards, using two dedicated Ethernet networks between the MPS System and the EAGLE DSM cards.

  When the 48 Million Number feature is enabled, this new data model supersedes the existing EAGLE LNP model. The EAGLE OAM will not store LNP databases in Release 27.0. Also eliminated with the 48 Million Number feature are the BLM and DCM cards that previously were required to support EBD&A.

• The transmission rate of database updates from the LSMS to the EAGLE has increased from 2 TN/sec to 25 TN/sec.

  Prior to Release 27.0, LNP updates were sent from the LSMS to the OAP over the customer's network. The minimum OAP hardware in the field today runs on an 85MHz Sparc-4 platform. The OAP translates the data from the LSMS to character based commands resembling SEAS UPL commands for LNP. These commands are sent across a dedicated serial link to an EAGLE terminal port at 19,200 Kpbs. The command is then parsed and validated by the EAGLE before the real-time database is updated. Real-time updates are sent to SCCP cards serially using a card list.

  With Release 27.0, the 48 Million Number feature provides a much faster path for updates. LNP updates are sent from the LSMS to the ELAP over the customer's network. The ELAP performs minimal parsing and validation before updating the real-time database. Real-time updates are sent to the EAGLE DSMs in parallel using multicast technology.

• Enhanced Bulk Download and Audit (EBD&A) is supported directly by the ELAP.

  The ELAP now provides all of the functionality of EBD&A.

• All cartridge-based bulk download operations have been eliminated.

  Bulk loading is accomplished using the EBD&A functionality provided by the ELAP. Since EAGLE will not store the real-time database on disk, a cartridge based bulk load is no longer necessary.

• Real-time databases are recovered from one of the mate EAGLE's ELAPs in a disaster situation (ELAP failure at one EAGLE).

  In the unlikely event of a catastrophic failure of the complete MPS system at one EAGLE, resulting in the loss of the real-time database, it will be possible to copy the data from one of the MPS servers of the mated EAGLE node. After the MPS fault has been corrected, a craftsperson may gain access to it via a modem or through the customer's network. It will then be possible to initiate a connection to one of the MPS servers at the mate EAGLE site and initiate a transfer of the real-time database.

• The EAGLE security log functionality has been moved to the ELAP.

The following figure shows the system architecture supporting the 48 Million Number feature.

Figure 2-4 System Architecture Supporting 48 Million Number

Attached to each EAGLE is an MPS System, consisting of two MPS Servers (Server A and B) and their associated platform software (e.g., Operating System, DBMS, etc.). The servers in the MPS System execute the software developed for the 48 Million Number feature, which is referred to as the "ELAP software."

Throughout the remainder of this description, when the term "ELAP" is used, it means "the ELAP software running on an MPS Server." Thus when we say that there are two ELAPs attached to each EAGLE, we mean that there are two MPS Servers attached to each EAGLE, both of which are running the ELAP software. These two ELAPs run in a mated-pair configuration, with one behaving as the "active ELAP" and the other as the "standby ELAP."

System-Level Requirements

When the 48 million number feature bit is on, the following attributes of the EAGLE change:

• OAM-based LNP commands are not be allowed (tt-serv is allowed).

• MPS-based LNP commands are allowed (rtrv- commands only).

• Enhanced Bulk Download (EBDA) functionality is implicitly inherited by the new architecture

The 48 million number architecture inherits all functionality of the 12 million number architecture (except for a separate bulkdownload component). This includes:

• Support DN to LRN mapping and up to six services for message relay. CLASS,LIDB,ISVM and CNAM message relay service are supported. (Customer-defined services are supported.)

• Support AIN/IN, IS-41 and PCS 1900 LNP query/response.

• Support Measurements (OAM can retain LNP Measurements).

• Support Transaction Log for LNP updates.

• Support for MPS alarming via EAGLE terminal.

• Support warm restart/incremental loading of the DSM card.

• Support loading the DSM card.

• Support Warm/Cold Restart of the DSM card

• Database storage of the LNP data from the LSMS.

  Note:

  The MPS architecture supports a real-time database only

• LNP Commands (tt-serv and rtrv- only)

There is one security log on the ELAP. The security log on the ELAP logs global (across all DSM cards) LNP updates as one entry, regardless of the number of DSM's provisioned. However, actions taken for a specific DSM card by the ELAP are logged on a per-DSM card basis.

The 48 million number architecture does not preclude the operation of the mate STP with the 12 million number architecture.

Required Hardware

To support 48 Million Numbers feature and the increased download rate from the NPAC/LSMS, the following new hardware is being introduced:

DSM

The Database Services Module (DSM) supports 48 million numbers by providing 1 GB daughterboard memory increments up to a total of 4GB. The DSM also provides TCP/IP connectivity directly to the MPS.

The DSM does not support the alloc-mem command to allocate daughterboard memory. Instead, the memory physically present on the board determines the number of ported records supported.

MPS

The Multi-Purpose Server (MPS) running the ELAP application is designed as a replacement not only for the LNP functionality contained in the EOAP, but also for the LNP database that currently resides on the OAM. The MPS fits into one general purpose frame (GPF).

Upgrade Considerations

ELAP

ELAP software is new software. All initial applications of this feature will be new installations. Future software upgrades will be addressed with the Solaris "pkgadd" utility. The following data must be preserved or re-generated for upgrade:

• Data configured through the user interface

• Security logs

• Data provisioned from the LSMS

Each of these must be addressed by any future upgrade.

Maintenance

Three upgrade considerations affect maintenance:

• Support the EPAP alarms defined in Release 26.05 and 26.1 during upgrade. This must be done for both UAMs and the rept-stat-mps output.

• Allow TSM cards to co-exist with DSM cards and support the output in all rept-stat reports.

• Allow for the conversion of DSMs from DSM operation to TSM operation via a database restore operation.

Measurements

Measurements data are not preserved from a prior release to the upgrade release during an upgrade. If the customer desires to retain a record of pre-upgrade measurements, a hardcopy of the measurements data can be obtained using the documented LNP measurement report procedures. Alternatively, measurements data can be copied to a Measurements removable cartridge using the copy-meas command. The data is then available for offline (non-EAGLE) processing. Measurements data cannot be restored to the upgraded EAGLE due to potential changes in data formats as a result of the upgrade.

LNP Measurements are preserved when the LNP48MIL feature bit is enabled after upgrade.

Description

The 56 Million G-Flex Entries feature is a product of the 18GB (P/N 804-1282-01) to 36GB disk (P/N 804-1548-01) hard drive upgrade; see “18GB to 36GB Hard Drive Upgrade (Release 29.1) (IP7 Release 7.1)”. As a result of this increased storage capacity, the existing EPAP and EAGLE software now can support 56 Million G-Flex entries.

Hardware Requirements

This feature requires the 36 GB disk hard drive (P/N 804-1548-01).

Description

The 120 Million LNP number feature provides the capability to expand the maximum number of ported/pooled LNP numbers supported on one EAGLE platform from 96 million to up to 120 million LNP numbers. Local Service Management System (LSMS) _ EAGLE LNP Application Processor (ELAP) reload, audit and reconcile times increase proportionally to the size of the database. Aggregate times for Multi-Purpose Server (MPS) to DSM audit, reconcile, and reload increase slightly due to the increase in LNP database capacity, but the rate-per-time unit remain the same.

Hardware Requirements

The existing 4G DSM card is used for 120 Million LNP numbers.

Limitations

• This feature is only available for North American LNP customers.

• This feature is dependent on the LSMS 120 Million LNP number feature.

• If the Message Relay Group (MRG) Table exceeds 2 million entries then the Software Release Upgrade cannot occur. This is an incompatible situation and loss of data may occur if the upgrade is executed for either the EAGLE 5 ISS or ELAP.

Description

The 192 Million LNP Numbers Support feature expands the maximum number of ported/pooled Local Number Portability (LNP) numbers supported on one EAGLE 5 ISS platform to 192 million LNP numbers. The feature supports feature access keys for 132, 144, 156, 168, 180, or 192 million ported/pooled numbers.

Configurable alarm thresholds indicate:

• When the transactions-per-second (TPS) for the EAGLE 5 ISS (as a whole) reaches the threshold value.

• When the number of LNP ported TNs and LRNs in the database is approaching the configured percent of the enabled maximum number allowed in the database.

• When the thermal limits of an HC-MIM card have been reached.

The 192 Million LNP Numbers Support feature requires the ELAP 5.0 database application. The ELAP 5.0 database application is installed and runs on the T1100 application server.

Hardware Requirements

The existing 4GB DSM card must be used for the 192 Million LNP Numbers feature.

The ELAP 5.0 database application that supports 192 million LNP numbers runs on the T1100 platform.

Limitations

• The 192 Million LNP Numbers feature is available only for North American LNP customers.

• This feature requires the LSMS 192 Million LNP Numbers feature.

• Prior to the upgrade, Tekelec will perform a pre-upgrade health check to access the compatibility of your current hardware and software configuration. If the Message Relay Group (MRG) table exceeds 2 million entries, the Software Release Upgrade cannot occur. This is an incompatible situation, and a loss of data may occur if the upgrade is executed for either the EAGLE 5 ISS or ELAP.

• 192 Million LNP Numbers feature activation on the EAGLE 5 ISS is based on the following conditions:

  • The ELAP LNP Configuration feature access key must be on.

  • 4-Gigabyte DSMs are required; at least one 4-Gigabyte DSM must be provisioned in the system.

  • The ELAP software version must be ELAP 4.0 if an EAGLE 5 ISS feature access key for 96-120 Million LNP Numbers is enabled.

  • The ELAP software version must be ELAP 5.0 if an EAGLE 5 ISS feature access key for more than 120 Million LNP Numbers is enabled.

Description

As Local Number Portability becomes more established, competition increases, and number pooling becomes more widespread, the number of ported TNs continues to increase. Customers would like to manage a single LSMS that is capable of maintaining the national LNP database. Increased capacity is required on the ELAP.

Currently, Tekelec supports 192 Million LNP numbers per node on a 4 GB DSM card. With the advent of wireless portability and continued wireline LNP porting and pooling activity, it is anticipated that the 192 Million LNP numbers capacity will be exceeded sometime early-mid 2007 as shown in Figure FN-1.

Figure 2-5 Current LNP Growth Projections

The 228 Million LNP Numbers feature allows customers to use their existing hardware and remain in a centralized Eagle LNP architecture (all LNP numbers in one node).

The 228 Million LNP Numbers feature expands the maximum number of ported/pooled LNP numbers supported on one EAGLE node to 228 million LNP numbers in increments of 12 million numbers. Additional database improvements include faster MPS-to-DSM audit reconcile and reload times, and LSMS-to-ELAP audit times.

The 228 Million LNP Numbers feature expands the maximum number of ported/pooled Local Number Portability (LNP) numbers supported on one on the ELAP to 228 Million LNP Numbers. The feature supports feature access keys for increments from 204, 216, or 228 million ported/pooled numbers across all NPAC regions.

Hardware Requirements

The 228 Million LNP Numbers feature requires the existing 4 GB DSM card.

The 228 Million LNP Numbers feature runs on the T1100 platform.

Limitations

The 228 Million LNP Numbers feature is available only for North American LNP customers.

The 228 Million LNP Numbers feature requires the LNP 228 Million numbers feature on the LSMS.

Description

The 228 Million LNP Numbers feature allows the capacity of an EAGLE 5 ISS node to increase to 228 million LNP numbers without adding new hardware.

The increase is achieved by using existing 4GB DSM cards and enhancing the database. EAGLE 5 ISS supports the following feature access keys for LNP growth beyond 120 million LNP numbers on the existing 4GB DSM card:

• 132 Million LNP – 893-0110-15
• 144 Million LNP – 893-0110-16
• 156 Million LNP – 893-0110-17
• 168 Million LNP – 893-0110-18
• 180 Million LNP – 893-0110-19
• 192 Million LNP – 893-0110-20
• 204 Million LNP – 893-0110-21
• 216 Million LNP – 893-0110-22
• 228 Million LNP – 893-0110-23

The 228 Million LNP Number feature must be activated on the LSMS, ELAP, and EAGLE 5 ISS products. LSMS 8.5 and ELAP 6.0 with 228 Million LNP Numbers support are required to enable the feature on EAGLE 5 ISS.

Hardware Requirements

The 228 Million Numbers LNP feature has the following hardware requirement:

• The existing 4GB DSM card must be used for the 192 Million LNP Numbers feature.
• The ELAP 5.0 database application that supports 192 million LNP numbers runs on the T1100 platform.

Limitations

The 228 Million LNP Numbers feature has no limitations.

Description

The 1100 TPS/DSM for ITU NP feature allows a DSM card to support up to 1100 transactions per second (TPS) for the EAGLE 5 ISS G-Port, A-Port, INP, IS41 GSM Migration, EIR, and ANSI-41 INP Query features.

In most systems, only 50% or less of the traffic needs an EPAP-based database lookup while the rest of the traffic requires GTT-related database lookup. The 1100 TPS/DSM for ITU NP feature assumes that at most 70% of the traffic shall require EPAP-based database lookup.

A feature access key (FAK) for part number 893018001 is required to enable this feature.

• A temporary FAK is not allowed for this feature.

• This feature is an ON/OFF feature, it can be turned on and off after it has been enabled.

• At least one EPAP-based ITU feature (G-Port, G-Flex, INP, EIR, Prepaid IDP Query Relay, A-Port, IS41 GSM Migration, or AINPQ) must be on before this feature can be enabled.

• The ansigflex STP option cannot be used when this feature is enabled; this feature cannot be enabled when the ansigflex STP option is used.

Hardware Requirements

The 1100 TPS/DSM for ITU NP feature requires DSM cards running the VSCCP application

Limitations

When the 1100 TPS/DSM for ITU NP feature is on and more than 70% of the traffic requires EPAP-based database lookup, the DSM cards provisioned in the system for SCCP might not be able to support 1100 TPS.

Description

This feature increases the total number of routing keys on a SSEDCM IPGWx application from 1000 routing keys to 2500, while retaining the DCM IPGWx application to a maximum of 1000 routing keys. The total number of routing keys for each application may be all dynamic, all static, or a combination of both.

The SG supports two types of routing keys for use by the IPGWx application, Static Routing Keys and Dynamic Routing Keys. Both routing keys are stored in one routing key table which is located in RAM on the IPGWx application.

• Static Routing Keys. These routing keys are provisioned via administration commands and are stored in the OAM static database. The SS7IGWx application keeps a copy of the static routing keys in the SS7 Routing Key Table on-board in RAM for quick access.

• Dynamic Routing Keys. Dynamic Routing Keys are provisioned via a request sent over an IP connection and allows an IP connection to automatically direct traffic towards (or away from) themselves by sending messages to the Signaling Gateway.

Note that all IP connections (TALI/TCP, M3UA/SCTP and SUA/SCTP) on the IPGWx application use routing keys. Currently, only TALI sockets have the capability to create dynamic routing keys via dynamic registration. However, this feature makes no assumptions regarding an IP connection’s ability to register dynamic routing keys.

New Auto-inhibit Facility

The System Configuration Manger (SCM) software is responsible for determining if the proper GPL should be fully loaded onto the requested card. For IPGWx applications, the SCM software will now calculate the sum of the CHG-SG-OPTS command parameters :SRKQ and :DRKQ to see if the total is over 1000.

If the sum is over 1000 and the IPGWx application board is a DCM, the card will be automatically inhibited, and the alarm message Insufficient memory for provisioning will be displayed. When a DCM IPGWx card is auto-inhibited, it will remain inhibited, unless the following sequence of events occurs.

• The number of routing keys on all IPGWx applications must be reduced to 1000 or less.

• Once the number of routing keys is reduced to 1000, the CHG-SG-OPTS command must be issued such that drkq + srkq <= 1000.

• The inhibited IPGWx card must be manually allowed.

Hardware Requirements

This feature requires the SSEDCM-based IPGWx GPLs (870-2372-xx).

Description

The 6000 Routesets feature expands the SS7 routing connectivity between the EAGLE and other nodes by increasing the number of routesets supported by the EAGLE. This allows for the EAGLE to function in larger SS7 networks.

The functionality of this feature applies to all LIM types except LIMs running the GX25 GPL, which will continue to utilize the X.25 2000 Routeset feature. However, the increased 6000 SS7 routeset table will also be downloaded on GX25 card.

Hardware Requirements

This feature requires the GPSM-II in the active and standby OAM slot, and a TDM change (870-0774-10 or later).

Description

The 8,000 Routesets feature expands the SS7 routing connectivity between the EAGLE 5 ISS and other nodes by increasing the number of routesets supported by EAGLE 5 ISS from 6000 to 8000. This feature can be viewed as an extension to the 6000 Routesets feature, which expanded the EAGLE 5 ISS routesets from 5000 to 6000.

A Feature Access Key (FAK) allows the customer to set the routeset limit to either 7000 or 8000. With the exception of a routeset provisioning limit imposed by the 7000 FAK, the 7000 Routeset and 8000 Routeset implementations are identical.

Limitations

If the customer has more than 8000 aliases provisioned, then the 7000 or 8000 Routesets feature cannot be enabled. Aliases must be deleted from the system until the 8000 alias limit is met.

Hardware Requirements

The 8000 Routesets feature permits customers to add additional routesets without requiring hardware change.

Description

The 50,000 GTT Capacity featur increases the GTT processing capability of EAGLE 5 ISS GTT-only nodes from 40,800 TPS to 52,700 TPS through the use of 32 DSMs per node (31 active and 1 for +1 redundancy), each running at 1700 TPS per card (31 x 1700 = 52,700).

Hardware Requirements

The 50,000 GTT Capacity feature requires 32 DSM cards exclusively for GTT functionality.

Limitations

The 50,000 GTT Capacity feature has the following limitations:

• The LNP, G-Flex, G-Port, INP, or EIR features cannot be activated if there are more than 25 DSM cards in the system. Therefore, these features are not supported in conjunction with the 50,000 GTT Capacity feature.

• The maximum number of SCCP cards allowed in a single EAGLE 5 ISS node is 32 (to provide n+1 functionality). 32 DSM cards are required to achieve 52,700 TPS: therefore, if any TSM cards are in the system, the total TPS rate will be less than the system maximum.

• The 50,000 GTT Capacity feature is not available on systems that are equipped with MPS.

Description

The 150,000 GTT TPS feature increases the throughput capacity of the EAGLE 5 ISS from 52,700 to 150,000 TPS for a node in which the SCCP message throughput traffic is processed by the GTT feature.

The 75,000 EPAP TPS feature increases the throughput capacity of the EAGLE 5 ISS from 20,400 to 75,000 TPS for a node that processes part of the SCCP message throughput traffic by one or more of the EPAP-based features (e.g. G-Port, G-Flex, EIR, or INP) or for a node that processes a combination of GTT and EPAP traffic.

These features require the E5-SM4G card to be installed in the EAGLE 5 ISS. The E5-SM4G Throughput Capacity feature must be enabled and turned on in order to operate at 5000 TPS (if traffic is processed by GTT) or 3125 TPS (if traffic is processed by the EPAP-based features).

If all of the SCCP traffic is processed by GTT, then a maximum of 32 E5-SM4G cards can be provisioned in the EAGLE 5 ISS. If the E5-SM4G Throughput Capacity feature is enabled and turned on, then each E5-SM4G card can process traffic at a rate of 5000 TPS, and the 150,000 TPS rate can be reached.

If any of the SCCP traffic is processed by an EPAP-based feature, then a maximum of 25 E5-SM4G cards can be provisioned in the EAGLE 5 ISS. If all of the SCCP traffic is processed by EPAP-based features, and if the E5-SM4G Throughput Capacity feature is enabled and turned on, then the rate of 75,000 TPS can be reached.

E5-SM4G cards can co-exist with DSM cards in the EAGLE 5 ISS; however, if both kinds of cards are used, then the maximum TPS rates cannot be reached.

Feature Control Requirements

The E4-SM4G Throughput Capacity feature has the following feature control requirements:

• A FAK for part number 893-0191-01
• A temporary key cannot be used to enable the E5-SM4G Throughput Capacity feature.
• After the E5-SM4G Throughput Capacity feature has been turned on, it cannot be turned off.
• The E5-SM4G Throughput Capacity feature cannot be enabled if any of the following features or options are turned on:
  • E5IS (EAGLE 5 Integrated Monitoring) feature
  • LNP feature
  • ANSIGFLEX STP option

Hardware Requirements

The E5-SM4G Throughput Capacity feature requires HIPR cards to be installed in all the shelves in an EAGLE 5 ISS node.

Limitations

The 150,000 GTT TPS and 75,000 EPAP TPS features have the following limitations:

• The real time database entry capacity of the E5-SM4G card for the EPAP-based features is smaller than the capacity supported by the current DSM 4G card.
• If the E5IS IMF or LNP feature, or the ANSIGFLEX system option is enabled, then the TPS level is held to the level of a DSM card (1700 TPS). The E5-SM4G Throughput Capacity feature cannot be enabled, and the 150,000 GTT TPS feature cannot be used.

Password Complexity

Password complexity rules for user passwords implemented by EPAP 14.0:

• The password cannot exceed 100 characters in length.
• The password must include at least one alpha character.
• The password must include at least one numeric character.
• The password must include at least one special punctuation character: question mark (?), period (.), exclamation point (!), comma (,), or semicolon (;).
• The password cannot contain three or more of the same alphanumeric or special punctuation character in a row.
• The password cannot contain three or more consecutive ascending alphanumeric characters in a row.
• The password cannot contain three or more consecutive descending alphanumeric characters in a row.
• The password cannot contain the user account name (login name).
• The password must not contain the user account name in reverse character order.
• The password must not be blank or null.
• The password must not be a default password.

Password Aging

Users can be forced to change their passwords after a certain number of days. The administrator can set a maximum password age of up to 180 days as a default for the system and can specify a different maximum password age for any individual user.

Password Reuse

Users cannot reuse their last N passwords, where N is a system-wide configurable number from 3 to 99, with a default of 5. The administrator cannot turn off this restriction by setting N to 0 (zero).

Description

This feature adds the following EAGLE cards to those supported by the EAGLE with Integrated Sentinel Feature introduced in EAGLE Release 28.0. Sentinel 8.1 supports monitoring for links on E1-ATM and LIM-ATM cards, and supports SS STC cards for monitoring:

• E1-ATM - With Release 28.2, the EAGLE supports Integrated Sentinel functionality for the E1-ATM card.

• LIM-ATM - With Release 28.2, the EAGLE supports Integrated Sentinel functionality for the LIM-ATM card.

• SS STC - With Release 28.2, the EAGLE supports the existing Sentinel routing functionality (EROUTE GPL) on a SS STC card.

New Hardware Required

No new hardware is required for this feature. Note, however, that the EAGLE with Integrated Sentinel feature does require the use of GPSM-II cards in place of MCAP cards, and HMUX cards in place of IPMX cards. Also, the EAGLE Time Synchronization feature must be active in conjunction with this feature. In addition, the timing requirements include the use of an external Bits clock.

Description

The ANSI-41 INP Query (AINPQ) feature adds support for using an ITU-N ANSI-41 NPREQ message for querying the INP database, in addition to the existing INP feature number portability query using the ITU-N and ITU-N24 INAP IDP message.

A feature access key (FAK) for part number 893017801 is required to enable the AINPQ feature.

• The GTT feature must be on before the AINPQ feature can be enabled.

• After the feature is enabled and turned on, it cannot be turned off.

• No temporary FAK is allowed for the feature.

• If any LNP quantity feature is enabled, the INP and AINPQ features cannot be enabled. If either the INP feature or the AINPQ feature is enabled, no LNP quantity feature can be enabled.

• The AINPQ feature and the EIR feature cannot be enabled in the system at the same time.

The AINPQ feature supports a mix of ITU and ANSI protocols in querying the INP database using the ANSI-41 NPREQ query.

Service selectors, INP options, and measurements are common to the INP and AINPQ features.

INP message relay functions operate when the INP feature, the AINPQ feature, or both features are turned on. The parameter values defined for INP query processing (through the INPQ service or PC/SSN) can apply to both the INP and AINPQ feature if both features are turned on.

INP query processing can be invoked by the following mechanisms (MTP routed NPREQ is not supported):

• For GTT-routed NPREQ query, INP query processing can be invoked using the inpq service selector that is defined using the SCCP Service Selector commands.

• For NPREQ-routed-based PC/SSN query, INP query processing can be invoked using the EAGLE 5 ISS point code and local subsystem number (PC/SSN) defined for the INP feature.

When the AINPQ featureis turned on,the INP query processing operates as follows:

• Handling of an ITU-N Point Code ANSI-41 NPREQ query encoded in ANSI-41 TCAP, ITU SCCP, and ITU MTP protocol stack is supported.

• ITU MTP/SCCP protocol validation and ANSI TCAP protocol validation for a received ANSI-41 NPREQ query are supported.

• For a received ANSI-41 NPREQ query subject to the INP query processing, the EAGLE 5 ISS uses the digits encoded in the DGTSDIAL parameter for database lookup.

• The EAGLE 5 ISS performs number conditioning on the DGTSDIAL value in preparation for database lookup. The Called Party Prefix, National Escape Code, Service Nature of Address, Nature of Number, and Country Codes are used to condition the number as a National or International number.

• Enhanced AINPQ and INP options for the Global Option for Connect on INP Query feature can be used to format information in the response that results from the database lookup.

• The AINPQ feature and the INP feature share the INP local subsystem, including SCCP subsystem management and service selection.

• The AINPQ feature and the INP feature share the CPCTYPE (Capability Point Code Type) state.

When the INP feature is turned on, the INP query processing operates as follows:

• Handling of the ITU-N and ITU-N24 INAP IDP message is supported.

• CDPN number conditioning is performed in preparation for database lookup.

• Enhanced AINPQ and INP options for the Global Option for Connect on INP Query feature can be used to format information in the response that results from the database lookup.

The INP options in the EAGLE 5 ISS have been enhanced to support the AINPQ feature.

• A new INP option is provided to define the National Escape Code (NEC) value, up to 5 digits, for each EAGLE 5 ISS node.

• The maximum number of Called Party Prefix entries allowed in the INPOPTS table has been increased from 5 to 40.

• AINPQ supports the Global Option for Connect on INP Query Response feature that was previously implemented for INP. The destination routing address (DRA) options have been enhanced for INP and AINPQ for formatting the ROUTDGTS parameter in the INP “Connect” message or AINPQ NPREQ “Return Result“ response message, as follows:

• Support RN + [CDPNPFX] + DN in INP “Connect” or AINPQ “Return Result” response messages

  • Support Routing Number in in INP “Connect” or AINPQ “Return Result” response messages

  • Support [CDPNPFX] + CC + RN + DN in INP “Connect” or AINPQ “Return Result” response messages

  • Support RN + [CDPNPFX] + NEC + DN in INP “Connect” or AINPQ “Return Result” response messages (the National Escape Code must be provisioned)

There are no new measurements pegs for NPREQ queries. The existing INP registers are pegged for the NPREQ query, the IDP query, or both; the peg for “IDP received” is a total count of the number of the IDP and NPREQ queries received if both the AINPQ and INP features are turned on.

Hardware Requirements

The ANSI-41 INP Query feature has the following hardware requirements:

• DSM card with at least 4G of memory running the VSCCP application

• After AINPQ is enabled, no DSM cards with less than 4G of memory can be provisioned. DSM cards installed with less than 4G of memory will be auto-inhibited if AINPQ is enabled.

Assumptions

The ANSI-41 INP Query feature assumes that an MSC will not initiate an NPREQ query for a call prefixed with International Escape Code (commonly defined as “00”) + CC+DN, as the call is intended for terminating to an international subscriber.

Limitations

None

Description

The ANSI-41 Mobile Number Portability (A-Port) feature enables an IS41 subscriber to change to a different service provider while retaining the same Mobile Dialed Number (MDN).

A-Port uses the EPAP (EAGLE Provisioning Application Processor) RTDB provisioning database to retrieve the subscriber portability status and provision directory numbers for exported and imported IS41 subscribers. This database maintains information related to subscriber portability in the international E.164 format. A-Port uses RN and PT values to provision directory numbers (DNs) for exported subscribers. In addition, A-Port uses SP to provision DNs for imported subscribers. It is optional to provision the PT values for imported subscribers.

Service Selector Lookup

Service selector lookup is performed using the MTP/SCCP data. If the selectors match and MNP service is assigned, A-Port handling is performed.

To manage number portability, A-Port uses the MNP SCCP Service Selector to process LOCREQ and SMSREQ SCCP messages. The EAGLE ISS intercepts LOCREQ messages for the RTDB database lookup. An ANSI-41 LOCREQ message is initiated by a TDMA/CDMA MSC that queries the HLR for information regarding user subscription/location before terminating a voice call.

A-Port supports both GT- and MTP-routed messages.

• GT-routed messages support UDT and non-segmented XUDT message types and perform service selector lookup after SCCP verification.

• A-Port processes MTP-routed messages if the MTP Messages for SCCP Applications (MTP Msgs for SCCP Apps) feature is turned on (see IS41 GSM Migration (Release 36.0) for details of MTP-routed message processing).

MNP begins A-Port general TCAP/MAP verification if the message is ANSI TCAP and A-Port is turned on. TCAP/MAP verification is performed on all messages; A-Port supports only the ANSI TCAP format.

Database Lookup and Routing

The DN is used for database lookup.

• For LOCREQ messages, the DN is derived based on the setting of the LOCREQDN option (see the new chg-is41opts command).

• For non-LOCREQ messages, the DN is derived from the SCCP portion of the message.

• A-Port performs number conditioning upon successful decode and verification of the message. HomeRN and IEC or NEC prefixes are removed. The DN is conditioned to international number format based on the service nature of address (SNAI or TCAPSNAI or MTPLOCREQNAI).

A-Port performs RTDB lookup on the conditioned number, and routes or relays the message based on the lookup result.

• An SMSREQ message is relayed like any other non-LOCREQ message. No changes are performed to the TCAP/MAP portion of the message.

• A-Port modifies the TCAP information for LOCREQ messages only when a HomeRN was deleted from the TCAP DN and LOCREQRMHRN = YES. Any gaps in the data caused by a change in field length will be resolved by shifting the remaining information up. Any IEC or NEC code is left.

• A-Port falls through to GTT if number conditioning fails or does not find the DN in the RTDB database, or the DN is found with non-A-Port data.

• If a HomeRN is detected in the Called Party and a matching DN with RN is found in the database, the EAGLE 5 ISS generates UIM 1256, indicating detection of circular routing, and routes the message using normal routing if both the MNP Circular Route Prevention feature and the IS41 GSM Migration featureare turned on.

• Normal routing is performing GTT if the incoming message is sent to the EAGLE 5 ISS Self Point Code. Normal routing is routing the message to the MTP DPC if the incoming message is MTP-routed (the MTP DPC of the message is not the EAGLE 5 ISS Self Point Code).

A-Port shares the service state and re-route with the IS41 GSM Migration feature and the G-Port feature, under one service called the MNP service state. (The G-Port service state is used if only the G-Port feature is on.) A-Port supports re-route functions as part of MNP service re-route. Alternate PCs are shared by all three features.

Alarms and the rept-stat-sccp command output show MNP Service information if the A-Port feature is enabled.

Feature Access Key

A feature access key (FAK) for part number 893015501 is required to enable the A-Port feature.

• The GTT feature must be on before the A-Port feature can be enabled.

• After the feature is enabled and turned on, it cannot be turned off.

• No temporary FAK is allowed for the feature.

• An LNP quantity feature and the A-Port feature cannot be enabled in the system at the same time.

Measurements

The following enhancements support the collection and retrieval of measurements related to the A-Port feature. These new measurement registers are supported with and without the Measurements Platform feature enabled.

• New registers are added to the NP SSP reports: Hourly Maintenance Measurements on NP SSP (MTCH-SSP) and Daily Maintenance Measurements on NP SSP (MTCD-SSP).

  • APLRACK—Number of call related LOCREQ messages acknowledged.

  • APLRRLY—Number of call related LOCREQ messages relayed.

  • APNOCL—Number of non-call non-LOCREQ related messages relayed.

  • APNOCLGT—Number of non-call Non-LOCREQ related messages that fell through to GTT.

Feature Interactions

G-Port, A-Port, and IS41 GSM Migration solve the problem of number portability from one network to another or number migration from one mobile protocol to another. One, two, or all three features could be active on a single EAGLE 5 ISS node at a given point. Because all of these features could have same type of MTP and SCCP layers (ITU or ANSI), it may look like same kind of message at service selection, which looks at the network domain and SCCP parameters. Therefore, all three features share one service. Because of this, existing functions like SRVSEL, Service, Re-route, CPC and rept-stat-sccp command service snapshot counts are affected.

Hardware Requirements

The A-Port feature has the following hardware requirements:

• DSM cards with at least 4G of memory

• A-Port cannot be enabled if any DSM cards with less than 4G of memory or any TSM cards for SCCP are present in the system. When A-Port is enabled, no DSM cards with less than 4G of memory and no TSM cards for SCCP can be provisioned for SCCP.

Assumptions

Within a portability domain (ordinarily a country) a Mobile Directory Number (MDN) assigned to an IS41 subscriber will not overlap with an MSISDN assigned to a GSM subscriber (one dialed DN can either be an IS41 or a GSM subscriber). Therefore, IS41 and GSM subscriber data can co-exist in the same EPAP provisioning database.

Limitations

The A-Port feature has the following limitations:

• Communication between the SMSCs in the originating network (a calling party’s home network or the network where the call was originated) and the SMSC in the terminating network is through SS7 and not SMPP.

• Number Portability across multiple countries is not supported.

Level 3 MSU Discrimination

The EAGLE must determine whether an incoming MSU terminates at the STP or must be routed to another destination. To accomplish the discrimination task, the EAGLE does the following.

• Compares the network indicator (NI) of an MSU to a database of valid NIs. If the network indicator is not valid, the MSU is discarded.

• Extracts the network indicator and destination point code (DPC) information from the incoming MSU. If an MSU is transmitted to an ANSI linkset, the network indicator is forced to a binary pattern of “10” before being extracted.

• Determines whether an incoming MSU terminates at the EAGLE or must be routed to another destination by joining the network indicator and DPC to a list of self point codes. The self point code is a combination of the true point code and capability point code. The capability point code identifies a group of nodes that have similar capabilities.

MSU Routing

MSU routing occurs after MSU discrimination and before MSU conversion (if conversion is necessary). The EAGLE selects an outgoing link on which to transmit the MSU. The MSU formats must be compatible with the linksets that transmit the MSUs.

EAGLEs are typically deployed in mated pairs. The EAGLE has a linkset for each supported network type. The EAGLE should have a unique adjacent point code. The EAGLE supports up to three self point codes—one for ANSI point codes, one for ITU international point codes, and one for ITU national point codes.

Figure 2-6 shows a sample network with mated gateway STPs. Note that there are different linksets for each network type. In the sample, STP (A) has an ANSI point code (007-001-001), an ITU National point code (09270), and an International point code (5-060-1).

Figure 2-6 Sample Gateway STP Network

Administering Point Codes

The EAGLE can support multiple network types because each destination can be addressed by a true point code or by a list of alternate point codes. The list of alternate point codes contains from 0 to 2 alternates. The true point codes and alternate point codes are entered in the key table (by using the ent-dstn command). For example, an ANSI destination could have both a true point code and an alternate point code that point to the same routing translation in the routing table.

Local Link Congestion

When a link is congested, the EAGLE sends ANSI TFCs to the ANSI origination point code (OPC) and ITU TFCs to the ITU origination point code (OPC). Figure 2-7 shows both an ANSI and an ITU network sending traffic to a congested link (the type of congested link does not matter). When an ANSI node is the source of the traffic to the congested link, the TFC contains a status. When an ITU node is the source of the traffic, the TFC does not contain a status.

Figure 2-7 Traffic to and from a Congested Link

All links in the system operate with four levels of congestion. If the congestion level is “0”, there is no congestion, the EAGLE does not transmit TFCs, and no MSUs are discarded. At level 3 (indicating a maximum level of congestion), the EAGLE transmits TFCs, and discards MSUs.

Whenever the congestion onset status is above congestion onset level 1, and has not abated below congestion abatement level 1, the EAGLE generates a TFC. Whenever the congestion discard status is above discard level 1, and has not abated below discard level 1, the EAGLE discards the MSU. See Figure 2-8.

Figure 2-8 Congestion Levels

Remote Link Congestion

Table 2-11 shows the EAGLE’s response to remote congestion indicators.

Description

The ANSI/ITU Translation feature allows any domain GTT selector to be assigned to a ‘cross’ domain GTT set. This allows access to GTA data within a GTT set that can be used to translate ANSI and ITU messages.

ANSI/ITU translation allows a user to provision a single cross domain GTT set with one set of GTA data and assign it to multiple GTT selectors, regardless of their domain. Since the user does not have to provision a GTT set with the same GTA data for each network domain GTT selector (gtia=2, gtii=2, gtii=4), GTA table space and user-provisioning activity is conserved.

The Enhanced GTT feature and ANSI-ITU-China SCCP Conversion feature must be on before the ANSI/ITU Translation feature can be enabled.

Hardware Requirements

The ANSI/ITU Translation feature has the following hardware requirements:

• Use of TSM or higher SCCP cards.
• LIM hardware types.

Limitations

The ANSI/ITU Translation feature has no associated limitations.

Hardware Required

Any ASM cards in the system must be replaced with TSM cards before the Release 31.6 upgrade can occur.

Limitations

• Beginning with EAGLE software release 31.6, there will be no support for the ASM card and card type.

Description

The Automatic PDB/RTDB Backup feature allows for the scheduling of automated backups of EPAP PDBs and RTDBs. The PDB backup copy is created on the EPAP A server and the RTDB backup copy is created on the standby EPAP server (A or B). A specific destination for the backup copy can be configured at the users discretion.

From the EPAP GUI terminal (Web UI only), the user can access a graphical user interface screen and configure the time, frequency, and destination of the backup copy.

Tekelec recommends that an Automatic PDB/RTDB Backup be performed on a daily (24 hour) basis. Both the PDB and RTDB backups are scheduled together and cannot be scheduled separately. The Time of the day to Start The Backup is the time that the RTDB backup starts. The PDB backup automatically starts 1 hour later.

Backups can only be scheduled and created on a provisionable EPAP server pair. An automatic PDB/RTDB backup is not allowed and cannot be scheduled on a non-provisionable EPAP server pair.

Normal provisioning is allowed during the automatic PDB/RTDB backup. This includes provisioning from

• the customer network to the PDB,

• the PDB to the Active EPAP RTDB, and

• the Active EPAP RTDB to the DSM RTDB.

RTDB backups are always created from the standby EPAP RTDB (A or B). The RTDB can resume receiving updates when it is brought back on line.

Disk Space Limitations

This feature supports the retention of three backup copies of the PDB and RTDB databases. However, the disk space in the EPAP free directory may not be sufficient to accommodate the retention of three backup copies on sites with large PDB and RTDB databases. When insufficient disk space exists, a dialog box appears asking the user “Do you want to delete the old backups”.

• If yes, the new database backup copy is written over the previous version.

• If no, the user must create a directory in a location with sufficient disk space and then specify the location of the backup directory to create the backup copy in.

Automatic PDB/RTDB Backup Screen

This feature adds to the list of EPAP Maintenance menu options, the item “Automatic PDB/RTDB Backup”. The scheduled time, frequency, and destination of the backup file can be configured by the user from the Automatic PDB/RTDB Backup screen.

Figure 2-9 Automatic PDB/RTDB Backup screen.

Most of the input parameters are self explanatory. The following options are configurable by the user:

The frequency of the backup copy can be any of the following increments:

• 12 hours (see Note below)

• 1 Day (daily)

• 2 Days

• 3 Days

• 5 Days

• 7 Days

The Backup Type parameter is the destination for the backup file:

• Local - A backup copy of the data is saved to the local disk on the same EPAP server as the PDB/RTDB being backed up.

• Mate - A backup copy of the data is created on the local server and then sent via SCP to the mate EPAP server.

• Remote - A backup copy of the data file is created on the local EPAP server and then sent via SFTP to a remote server configured by the user. This server may or may not run EPAP software and can be any machine on the network that is running an SFTP daemon or service.

• None - No backup is scheduled and cancel all previously scheduled backups. This will not affect a backup that is currently in progress.

The following table can be used as a guide when scheduling the Automatic PDB/RTDB Backup.

The default file path where subdirectories are created (on the mate and local servers) is /var/TKLC/epap/free/

Description

The Automatic PDB Export Enhancement feature provides more flexible scheduling for automatic PDBA exports.

With more options to choose from, scheduling an automatic PDB export is now very similar to the way tasks or appointments can be scheduled in a calendar manager.

In addition to the previously available choices for export format, mode, and data type, these enhancements allow the user to:

• View, modify, or delete existing reports
• Choose from multiple options for the frequency of the export:
  • Daily
  • Weekly
  • Monthly
  • Yearly
• Choose the time of day to start the export
• Add comments to describe the export

Hardware Requirements

None.

Limitations

None.

Hardware Requirements

No new hardware is needed to support this feature.

Limitations

No measurements are collected showing the number of MSUs converted by this feature.

No error message is generated if an error occurs during the conversion of the PIP and GN parameters.

If the CNCF feature is turned on, the DTA feature is disabled. No message redirection using the DTA feature will be performed.

If the copy=yes parameter is specified with the redirect=yes parameter, the MSU is copied for the STP LAN feature after it has been converted by the CNCF feature.

If there are multiple PIP parameters or GN parameters with calling name information within a single ISUPIAM, only the first occurrence of the parameter in the ISUPIAM message is converted.

Messages on X.25 linksets cannot be converted with the CNCF feature.

Only GNIAM messages containing calling name information (Type of Name = Calling Name, Presentation = Allowed, Parameter Length >1) are converted to PIPIAM messages.

Only PIPIAM messages containing Calling Name Information (Sub-Parameter Code = Name Information, Name Element Indicator = Calling Party) are converted to GNIAM messages.

If the received IAM message contains both a GN and a PIP parameter with calling name information, the GN parameter is retransmitted and the PIP parameter is deleted.

Any MSU that is not converted is simply retransmitted. These MSUs include non-ISUPMSUs, non-IAMMSUs, and any IAMMSU received that does not contain either a GN or PIP parameter.

If the PIP parameter contains other information in addition to the calling party name information, only a GN parameter containing calling party name information is generated.

The linkset being screened for this feature should not contain C links (lst=c parameter of the ent-ls and chg-ls commands). This would result in the double conversion of the ISUPIAM messages.

IAM messages containing a GN parameter that are to be converted, must be 262 bytes or less. The ANSISS7MSU can contain a maximum of 272 bytes, including the Level 3 routing label. Without the routing label, the MSU can contain 265 bytes, starting at the Circuit ID code field. Since the PIP parameter has 3 bytes more than the GN parameter, the MSU can contain a maximum of 262 bytes.

Table 2-16 summarizes the conversion action performed based on the optional parameters found within the MSU.

PIP and GN Parameters

The PIP format contains a parameter name (0xFC), parameter length and optional sub-parameters. The format is shown in Table 2-17. The Name Element Indicator, Name Element Length and Name Information fields can be repeated within a single PIP.

The GN format contains a parameter name (0xC7), parameter length and up to 16 additional octets. The format is shown in Table 2-18.

Conversion of PIP to GN

The mapping of PIP parameters to GN parameters for this conversion is shown in Figure 2-11. The new GN parameter length field is computed based on the PIP name element length and not the PIP parameter length or Sub-Parameter length fields.

Figure 2-11 PIP to GN Parameter Mapping

Conversion of GN to PIP

The mapping of GN parameters to PIP parameters for this conversion is shown in Figure 2-12.

Figure 2-12 GN to PIP Parameter Mapping

Table 2-19 shows how the PIP and GN parameters are mapped during the conversion process.

Message Conversion

The conversion process only occurs in ISUP Initial Address Messages (IAM) with either the PIP or GN optional parameters that contain calling party name information. The conversion either replaces PIP parameters with GN parameters or GN parameters with PIP parameters. In some cases, network-specific optional parameters are also deleted from the message. The Level 2 Length Indicator is also updated since the MSU length is changing. The sections shown in bold type show which fields of an IAM with the GN parameter are effected by the CNCF feature.

Output Example

Protocol Flavor: ANSI-SS7
Total Message Length: 56
*** Start of MTP Level 2 ***
                MTP
000 00000000 00 
    -0000000    Backward Sequence Number                 0 
    0-------    Backward Indicator Bit                   0 
001 00000000 00 
    -0000000    Forward Sequence Number                  0 
    0-------    Forward Indicator Bit                    0 
002 00110101 35
    --110101    Length Indicator                         53
    00------    Spare                                    0
*** Start of MTP Level 3 ***
                MSU                                      
003 10000101 85 
    ----0101    Service Indicator                        0101 - ISDN User Part 
    --00----    Network Priority                         00 - priority 0 
    10------    Network Indicator                        10 - National Network 
004 00000110 06 Destination Point Code                   4-5-6 
005 00000101 05 
006 00000100 04 
007 00000011 03 Origination Point Code                   1-2-3 
008 00000010 02 
009 00000001 01 
010 00000000 00 Signaling Link Selection                 0 
*** Start of ISDN User Part ***
                Initial address Message                  
011 00000000 00 Circuit Identification Code              0 
012 00000000 00 
    --000000    
    00------    Spare                                    0 
013 00000001 01 Message Type                             01 
                Nature of connection indicators         
014 00000000 00 
    ------00    Satellite Indicator                      00 - no satellite in the connection
    ----00--    Continuity check indicator               00 - continuity check not required 
    ---0----    Echo Control Device Indicator            0 - outgoing half echo cntrl dev not inc 
    000-----    Spare                                    0 
                Forward call indicators                 
015 00000000 00 
    -------0    Incoming International Call Indicator    0 - not an incoming international call 
    -----00-    End-to-End Method Indicator              00 - no end-to-end method available 
    ----0---    Interworking Indicator                   0 - no interworking encountered -all SS7 
    ---0----    IAM Segmentation Indicator               0 - no indication 
    --0-----    ISDN User Part Indicator                 0 - ISDN user part not used all the way 
    00------    ISDN User Part Preference Indicator      00 - ISDN-UP preferred all the way 
016 00000000 00 
    -------0    ISDN Access Indicator                    0 - originating access non-ISDN 
    -----00-    SCCP Method Indicator                    00 - no indication 
    ----0---    Spare                                    0 
    0000----    Reserved for National Use                0 
                Calling party's category                
017 00000010 02 Calling party's category                 00000010 - operator, language English 
                Variable Portion                         
018 00000011 03 User service information Pointer         Offset 021 
019 00000101 05 Called party number Pointer              Offset 024 
020 00010001 11 Optional Portion Pointer                 Offset 037 
                User service information                 
021 00000010 02 User service information Length          2 
                Octet 3                                  
022 11000000 c0 
    ---00000    Information transfer capability          00000 - speech 
    -10-----    Coding Standard                          10 - national standard 
    1-------    Extension                                01 
                Octet 4                                  
023 10010000 90 
    ---10000    Information transfer rate                10000 - 64 kbit/s 
    -00-----    Transfer mode                            00 - circuit mode 
    1-------    Extension 4                              Excluded 
                User information layers                 
                Called party number                      
024 00001100 0c Called party number Length               12 
025 00000011 03 
    -0000011    Nature of address indicator              national (significant) number
    0-------    Odd/even indicator                       0 - even number of address signals 
                Octets 2-10                             
026 00010000 10 
    ----0000    Spare                                    00 
    -001----    Numbering plan                           001 - ISDN(Telephony) numbering plan 
    0-------    Spare                                    00 
027 00100001 21 Address                                  12345678901234567890
028 01000011 43 
029 01100101 65 
030 10000111 87 
031 00001001 09 
032 00100001 21 
033 01000011 43 
034 01100101 65 
035 10000111 87 
036 00001001 09 
                Optional Portion
                Generic Name                             
037 11000111 c7 Generic Name Type                        199 
038 00010000 10 Generic Name Length                      16 
039 00100000 20 
    ------00    Presentation                             00 - Presentation Allowed 
    ----00--    Spare                                    00 
    ---0----    Availability                             0 - Name available, or unknown 
    001-----    Type of Name                             01 
040 01000001 41 NAME                                     ABCDEFGHIJKLMNO
041 01000010 42 
042 01000011 43 
043 01000100 44 
044 01000101 45 
045 01000110 46 
046 01000111 47 
047 01001000 48 
048 01001001 49 
049 01001010 4a 
050 01001011 4b 
051 01001100 4c 
052 01001101 4d 
053 01001110 4e 
054 01001111 4f 
055 00000000 00 End of optional parameters               00

The sections shown in bold type show which fields of an IAM with the PIP parameter are effected by the CNCF feature.

Output Example

Protocol Flavor: ANSI-SS7
Total Message Length: 59
*** Start of MTP Level 2 ***
                MTP                                      
000 00000000 00 
    -0000000    Backward Sequence Number                 0 
    0-------    Backward Indicator Bit                   0 
001 00000000 00 
    -0000000    Forward Sequence Number                  0 
    0-------    Forward Indicator Bit                    0 
002 00111000 38 
    --111000    Length Indicator                         56 
    00------    Spare                                    0 
*** Start of MTP Level 3 ***
                MSU                                      
003 10000101 85 
    ----0101    Service Indicator                        0101 - ISDN User Part 
    --00----    Network Priority                         00 - priority 0 
    10------    Network Indicator                        10 - National Network 
004 00000110 06 Destination Point Code                   4-5-6 
005 00000101 05 
006 00000100 04 
007 00000011 03 Origination Point Code                   1-2-3 
008 00000010 02 
009 00000001 01 
010 00000000 00 Signaling Link Selection                 0 
*** Start of ISDN User Part ***
                Initial address Message                  
011 00000000 00 Circuit Identification Code              0 
012 00000000 00 
    --000000    
    00------    Spare                                    0 
013 00000001 01 Message Type                             01 
                Nature of connection indicators         
014 00000000 00 
    ------00    Satellite Indicator                      00 - no satellite in the connection 
    ----00--    Continuity check indicator               00 - continuity check not required 
    ---0----    Echo Control Device Indicator            0 - outgoing half echo cntrl dev not inc 
    000-----    Spare                                    0 
                Forward call indicators                 
015 00000000 00 
    -------0    Incoming International Call Indicator    0 - not an incoming international call 
    -----00-    End-to-End Method Indicator              00 - no end-to-end method available 
    ----0---    Interworking Indicator                   0 - no interworking encountered -all SS7 
    ---0----    IAM Segmentation Indicator               0 - no indication 
    --0-----    ISDN User Part Indicator                 0 - ISDN user part not used all the way 
    00------    ISDN User Part Preference Indicator      00 - ISDN-UP preferred all the way 
016 00000000 00 
    -------0    ISDN Access Indicator                    0 - originating access non-ISDN 
    -----00-    SCCP Method Indicator                    00 - no indication 
    ----0---    Spare                                    0 
    0000----    Reserved for National Use                0 
                Calling party's category                
017 00000010 02 Calling party's category                 00000010 - operator, language English 
                Variable Portion                         
018 00000011 03 User service information Pointer         Offset 021 
019 00000101 05 Called party number Pointer              Offset 024 
020 00010001 11 Optional Portion Pointer                 Offset 037 
                User service information                 
021 00000010 02 User service information Length          2 
                Octet 3                                  
022 11000000 c0 
    ---00000    Information transfer capability          00000 - speech 
    -10-----    Coding Standard                          10 - national standard 
    1-------    Extension                                01 
                Octet 4                                  
023 10010000 90 
    ---10000    Information transfer rate                10000 - 64 kbit/s 
    -00-----    Transfer mode                            00 - circuit mode 
    1-------    Extension 4                              Excluded 
                User information layers                 
                Called party number                      
024 00001100 0c Called party number Length               12 
025 00000011 03 
    -0000011    Nature of address indicator              national (significant) number
    0-------    Odd/even indicator                       0 - even number of address signals 
                Octets 2-10                             
026 00010000 10 
    ----0000    Spare                                    00 
    -001----    Numbering plan                           001 - ISDN(Telephony) numbering plan 
    0-------    Spare                                    00 
027 00100001 21 Address                                  12345678901234567890
028 01000011 43 
029 01100101 65 
030 10000111 87 
031 00001001 09 
032 00100001 21 
033 01000011 43 
034 01100101 65 
035 10000111 87 
036 00001001 09 
                Optional Portion                         
                Party Information Parameter
037 11111100 fc Party Information Parameter Type         252 
038 00010011 13 Party Information Parameter Length       19
039 11111110 fe Sub-Parameter Code                       254 - Name Information
040 00010001 11 Sub-Parameter Length                     17
041 00000001 01 Name Element Indicator                   01 - Calling Party Name
042 00001111 0f Name Element Length                      15
043 01000001 41 Name Information                         ABCDEFGHIJKLMNO
044 01000010 42 
045 01000011 43 
046 01000100 44 
047 01000101 45 
048 01000110 46 
049 01000111 47 
050 01001000 48 
051 01001001 49 
052 01001010 4a 
053 01001011 4b 
054 01001100 4c 
055 01001101 4d 
056 01001110 4e 
057 01001111 4f 
058 00000000 00 End of optional parameters               00

Description

This feature provides a conversion of ISUP IAM messages using two versions of calling name identification presentation (CNIP) for calling name information delivery. One version of the CNIP uses the nonstandard, proprietary ISUP party information (PIP) parameter. The other version uses the ANSI standard ISUP generic name (GN) parameter. The conversion will either replace the PIP parameter with the GN parameter or the GN parameter with the PIP parameter in the ISUP IAM message.

The gateway screening feature is used to select which ISUP messages are converted. The incoming messages are selected based on the OPC and DPC in the routing label of the message, and the message type in the service information octet. The message type is defined by the value of the service indicator (SI) field of the SIO. ISUP messages contain the value 5 in the service indicator field of the SIO. Screening rules for Allowed OPC, Allowed DPC, and the Allowed SIO entities must be configured in the database for this feature.

Refer to the Database Administration Manual - Gateway Screening for details on using this feature.

Unsolicited Information Messages

The commands chg-scr-aftpc, chg-scr-cdpa, chg-scr-cgpa, chg-scr-tt, ent-scr-aftpc, ent-scr-cdpa, ent-scr-cgpa, and ent-scr-tt cannot use any entry shown in the rtrv-gws-actset command output that contains the redirect stop action (RDCT) or the CNCF stop action (CNCF). This restriction is not enforced when the chg-gws-actset and the chg-scr-aftpc, chg-scr-cdpa, chg-scr-cgpa, chg-scr-tt, ent-scr-aftpc, ent-scr-cdpa, ent-scr-cgpa, and ent-scr-tt commands are entered into the database. The database will accept these commands using entries from the gateway screening stop action table, but when the EAGLE encounters MSUs that pass gateway screening at the AFTPC, CDPA, CGPA or TT screens, these UIMs (unsolicited information messages) are generated indicating that gateway screening received a MSU that could not be redirected or converted.

UIM 1125 – Gateway Screening received a Called Party Address that could not be Redirected for the DTA feature

RLGHNCXA03W 99-01-07 00:57:31 EST Rel 24.0.0
1001.1125    CARD 1103,A  INFO         GWS rcvd CDPA that could not be RDCTd
             SIO=03   OPC=001-001-001  DPC=002-002-002
             SCCP MT= 18
             CDPA:  AI=10  PC=003-003-003  SSN=005  TT=250  ADDR=1234567890
             CGPA:  AI=10  PC=004-004-004  SSN=005  TT=251  ADDR=1234567890
             SR=scrb  LSN=A1234567
      Report Date: 98-09-07  Time: 16:27:19

UIM 1126 – Gateway Screening received a Calling Party Address that could not be Redirected for the DTA feature

RLGHNCXA03W 99-01-07 00:57:31 EST Rel 24.0.0
1002.1126    CARD 1103,A  INFO         GWS rcvd CGPA that could not be RDCTd
             SIO=03   OPC=001-001-001  DPC=002-002-002
             SCCP MT= 18
             CDPA:  AI=10  PC=003-003-003  SSN=005  TT=250  ADDR=1234567890
             CGPA:  AI=10  PC=004-004-004  SSN=005  TT=251  ADDR=1234567890
             SR=scrb  LSN=A1234567
      Report Date: 98-09-07  Time: 16:27:19

UIM 1127 – Gateway Screening received an Affected Point Code that could not be Redirected for the DTA feature

RLGHNCXA03W 99-01-07 00:57:31 EST Rel 24.0.0
1003.1127    CARD 1103,A  INFO         GWS rcvd AFTPC that could not be RDCTd
             SIO=03   OPC=001-001-001  DPC=002-002-002
             SCCP MT= 18
             CDPA:  AI=10  PC=003-003-003  SSN=005  TT=250  ADDR=1234567890
             CGPA:  AI=10  PC=004-004-004  SSN=005  TT=251  ADDR=1234567890
             SR=scrb  LSN=A1234567
      Report Date: 98-09-07  Time: 16:27:19

UIM 1128 – Gateway Screening received a Translation Type that could not be Redirected for the DTA feature

RLGHNCXA03W 99-01-07 00:57:31 EST Rel 24.0.0
1004.1128    CARD 1103,A  INFO         GWS rcvd TT that could not be RDCTd
             SIO=03   OPC=001-001-001  DPC=002-002-002
             SCCP MT= 18
             CDPA:  AI=10  PC=003-003-003  SSN=005  TT=250  ADDR=1234567890
             CGPA:  AI=10  PC=004-004-004  SSN=005  TT=251  ADDR=1234567890
             SR=scrb  LSN=A1234567
      Report Date: 98-09-07  Time: 16:27:19

UIM 1215 – Gateway Screening received a Called Party Address that could not be processed by the Calling Name Conversion Facility feature

RLGHNCXA03W 99-01-07 00:57:31 EST Rel 24.0.0
1005.1215    CARD 1103,A  INFO         GWS rcvd CDPA that could not be CNCFd
             SIO=03   OPC=001-001-001  DPC=002-002-002
             SCCP MT= 18
             CDPA:  AI=10  PC=003-003-003  SSN=005  TT=250  ADDR=1234567890
             CGPA:  AI=10  PC=004-004-004  SSN=005  TT=251  ADDR=1234567890
             SR=scrb  LSN=A1234567
      Report Date: 98-09-07  Time: 16:27:19

UIM 1216 – Gateway Screening received a Calling Party Address that could not be processed by the Calling Name Conversion Facility feature

RLGHNCXA03W 99-01-07 00:57:31 EST Rel 24.0.0
1006.1216    CARD 1103,A  INFO         GWS rcvd CGPA that could not be CNCFd
             SIO=03   OPC=001-001-001  DPC=002-002-002
             SCCP MT= 18
             CDPA:  AI=10  PC=003-003-003  SSN=005  TT=250  ADDR=1234567890
             CGPA:  AI=10  PC=004-004-004  SSN=005  TT=251  ADDR=1234567890
             SR=scrb  LSN=A1234567
      Report Date: 98-09-07  Time: 16:27:19

UIM 1217 – Gateway Screening received an Affected Point Code that could not be processed by the Calling Name Conversion Facility feature

RLGHNCXA03W 99-01-07 00:57:31 EST Rel 24.0.0
1007.1217    CARD 1103,A  INFO         GWS rcvd AFTPC that could not be CNCFd
             SIO=03   OPC=001-001-001  DPC=002-002-002
             SCCP MT= 18
             CDPA:  AI=10  PC=003-003-003  SSN=005  TT=250  ADDR=1234567890
             CGPA:  AI=10  PC=004-004-004  SSN=005  TT=251  ADDR=1234567890
             SR=scrb  LSN=A1234567
      Report Date: 98-09-07  Time: 16:27:19

UIM 1218 – Gateway Screening received a Translation Type that could not be processed by the Calling Name Conversion Facility feature

RLGHNCXA03W 99-01-07 00:57:31 EST Rel 24.0.0
1008.1218    CARD 1103,A  INFO         GWS rcvd TT that could not be CNCFd
             SIO=03   OPC=001-001-001  DPC=002-002-002
             SCCP MT= 18
             CDPA:  AI=10  PC=003-003-003  SSN=005  TT=250  ADDR=1234567890
             CGPA:  AI=10  PC=004-004-004  SSN=005  TT=251  ADDR=1234567890
             SR=scrb  LSN=A1234567
      Report Date: 98-09-07  Time: 16:27:19

In order to stop these UIMs from being generated, the gateway screening rule shown in the UIM must be identified. Once the gateway screening rule has been identified, a gateway screening change command can be used either to remove the gateway screening action set name or change the gateway screening action set name to a different gateway screening action set not containing the CNCF or redirect gateway screening stop actions. The gateway screening stop action set can also be changed with the chg-gws-actset command to remove the redirect or CNCF gateway screening stop actions. However, this could keep other gateway screening rules from redirecting or converting MSUs passing gateway screening from the BLKOPC, BLKDPC, SIO, OPC, DPC, or DESTFLD screens.

CDU Port

The existing CDU utility has been ported for the DSM/DCM card, and a new GPL VCDU has been created. The new GPL has all the existing functionality. The DSM board can hold up to 4GB of memory. The CDU or the VCDU utility is downloaded automatically, depending on the type of the board. For the DSM, the VCDU utility is downloaded; for the other boards, the CDU utility is downloaded.

The CDU or the VCDU can be downloaded into any card with the following command:

 alw-card:loc=xxxx:code=utility

The following act-memtst command used with the parameter set to "fast" lets the VCDU utility test 4GB of memory in 4 hours:

 cdu:loc=xxxx:cmd=
" ACT-MEMTST:BEG=H'100000:END=H'200000 :TYPE=FAST
"

Quick Test

The quick go/no go test is implemented with the ACT-QCKTST command in CDU/VCDU. Using this command, the VCDU utility can check the basic integrity of the memory within 10 minutes. This test includes verifying the address and data lines to the memory, and verifying accessibility of each memory chip of 4GB.

Ping Test

The VCDU utility uses a new command, act-pingtst, to test the network. The ping test applies to the DCM/DSM card only.

 cdu:loc=xxxx:cmd=
" act-pingtst:port=<a/b>:dest=<ip_address> :router=<router>:loop=n
"

This command activates the ping test. The port parameter specifies the origination address. The dest parameter specifies the destination address to be pinged. The router parameter is an optional parameter that specifies the router through which the network interface can be tested. The loop parameter specifies the number of times the test should be run before termination.

Description

The cluster routing and management diversity feature eliminates the need for a full point code entry in the routing table to route to every signaling point in every network. The cluster routing and management diversity feature allows the EAGLE to configure one route set to a entire cluster of destinations. This allows the EAGLE to manage and switch traffic to more end nodes.

A cluster is defined as a group of signaling points whose point codes have identical values for the network and cluster fields of the point codes. A cluster entry in the routing table is shown with an asterisk (*) in the member field of the point code, for example, 111-011-*. Cluster entries can only be provisioned as ANSI destination point codes. ANSI destination point codes can be specified as either a full point code, for example, 123-043-045, or as a cluster of signaling point codes, for example, 111-011-*.

Provisioning of clusters as well as full point codes that belong to the same cluster as destination point codes is also supported. The point codes 111-011-*, 111-011-005 and 111-011-045 entries can be provisioned. The cluster destination point code 111-011-* represents all the point codes of the cluster except for point codes 111-011-005 and 111-011-045. Cluster entries in the destination point code table can also be used as a destination point code (DPC) for a route. A group of such routes with varying relative cost forms a routeset to a cluster just like a routeset to a full point code.

Exception Lists (X-lists)

An exception list for a cluster is a list of point codes in a cluster whose route status is more restricted than the corresponding route status of that cluster. The term “more restricted” is used when comparing the route status of a cluster member to the route status of the cluster. A PROHIBITED status is more restrictive than a RESTRICTED status and a RESTRICTED status is more restrictive than an ALLOWED status. This list contains point codes that are not assigned to any individual routeset and the only routesets to that node is through a cluster routeset. The exception list is a dynamic list that changes when the status of the cluster routeset or any member routesets in that cluster changes.

For each cluster, the user can specify an exception list exclusion indicator (ELEI) when configuring the cluster point code with the ent-dstn command. When the ELEI is yes, the EAGLE does not maintain exception list entries. When the ELEI is no, the EAGLE maintains exception list entries.

Exception list entries are stored as an extension of the destination point code table, which can contain up to 2500 entries. The EAGLE allows the user to specify the number of entries reserved for the exception list, between 500 to 2000 entries. The remainder of the 2500 entries in the destination point code table are reserved for the full and cluster point codes.

The outputs of the ent-dstn, dlt-dstn, chg-dstn, and rtrv-dstn commands display the following destination point code usage information.

• The number of configured full point codes

• The number of configured cluster point codes

• The sum of configured destinations (full and cluster point codes)

• The number of entries reserved for configured destinations (full and cluster point codes). This number is 2500 minus the number of entries reserved for the exception list.

• The number of entries reserved for exception list

There is an STP-wide expiration time value for exception list entries. This timer specifies the amount of time an idle exception list entry can be in the exception list before it is discarded. When this timer expires, unsolicited information message (UIM) 1146, REPT-SLST-TIMO: X-LIST entry expired, is displayed on the terminal and the specified exception list entry is discarded. The following is an example of UIM 1146.

Output Example:

RLGHNCXA03W 96-04-16 16:21:11 EDT Rel 21.0.0
1234.1146    CARD 1101    INFO  REPT-XLST-TIMO: X-LIST entry expired
             DPC=011-212-033
Report Date: 96-04-16  Time: 16:20:19

In this example, the point code (DPC) 011-212-033 was in the exception list, the timer expired, and the point code was discarded from the exception list.

The value of the exception list timer is shown in the MTPXLET field of the rtrv-stpopts command output and is configured with the mtpxlet parameter of the chg-stpopts command.

The rtrv-stpopts command output contains three other fields that show the parameters of the exception list, MTPXLQ, MTPXLOT, and MTPDPCQ.

The MTPXLQ field shows the maximum number of entries the exception list (x-list) can contain. This value is configured with the mtpxlq parameter of the chg-stpopts command.

The MTPXLOT field shows the exception list (x-list) occupancy threshold (in terms of the percentage of the exception list space being used). The percentage of occupancy threshold is configured with the mtpxlot parameter of the chg-stpopts command. The default value for the threshold is 90%. For example, if there are 1500 entries configured for the exception list and the exception list contains 1000 entries, the percentage of the exception list space being used is 66%. If this threshold is exceeded, a minor alarm, unsolicited alarm message (UAM) 321, X-LIST occupancy threshold exceeded, is displayed. The following is an example of UAM 321.

UAM Messages

    RLGHNCXA03W 96-04-16 16:21:11 EDT Rel 21.0.0
*   0061.0321  * XLIST                 X-LIST occupancy threshold exceeded

The MTPDPCQ field shows the maximum number of destination point codes that can be configured in the EAGLE.

The EAGLE raises a major alarm, UAM 338, X-LIST space full-entry(s) discarded, when the exception list becomes completely full and the EAGLE fails to create any more exception list entries. The following is an example of UAM 338.

    RLGHNCXA03W 96-04-16 16:21:11 EDT Rel 21.0.0
**  0055.0338 ** SYSTEM                X-LIST space full-entry(s) discarded

An exception list entry’s expiration timer is restarted when an exception list entry gets created, updated, or used for routing. This expiration timer can be set for a minimum of 20 minutes to a maximum of 24 hours. The default value for the expiration timer upon system start-up is 60 minutes. If the timer expires before it is restarted, the exception list entry is removed. The expiration timer allows the EAGLE to save resources if the exception list entry is sitting idle for a specified period of time.

An exception list entry can be created for three distinct set of conditions.

1. The first set of conditions creates exception list entries based on the status of the route (allowed, restricted, or prohibited) and are marked as “exception list due to routing.”

2. The EAGLE creates an exception list entry to maintain the congestion status of a non-provisioned, cluster routed destination point code. These entries are marked “exception list due to congestion.”

3. The EAGLE also creates an exception list to prohibit routing to a member of a cluster when circular routing to that member is detected. These exception list entries are marked “exception list due to circular routing.”

An exception list entry for a particular cluster can be removed from the exception list when the following conditions are met:

1. The status of all routes to the specified point code changes to a status that is less or equally restrictive than corresponding status of cluster’s routes. This can happen for two reasons.

   1. A dact-rstst command was issued. The dact-rstst command changes the route’s status to allowed.

   2. A network management message (TFA or TFR) was received indicating the new status of the route to the specified point code.

2. The expiration timer for the exception list entry expires.

3. When a chg-dstn command is issued and changes the ELEI to yes for the cluster; the EAGLE removes all exception list entries created for that cluster.

4. The chg-stpopts command was issued with the mtpxlet parameter and the new value for the mtpxlet parameter was smaller than the original value. This command can change allocation of routing table entries for exception lists. If the size of the exception list is reduced and the number of entries in the exception list is now greater than the new value of the mtpxlet parameter, the EAGLE will remove excess exception list entries at random.

5. When a user allows a circular routed “exception list due to circular routing” entry after fixing the problem. The rst-dstn command is used to allow the routing.

6. When congestion abates for an “exception list due to routing” entry.

Cluster Routing

When the EAGLE receives an MSU to route, the routing function looks for the MSUs destination point code as a full point code entry in the routing table. If found, the full point code entry is used to find the corresponding routeset and the outgoing route. If a full point code entry is not found, the routing function uses the destination point code’s network and cluster values to find a cluster entry to which a destination point code belongs. If found, the cluster entry is used to find the corresponding routeset and the outgoing route. If neither a full point code entry or cluster point code entry is found, the EAGLE generates UAM 1004, “MTP rcvd unknown DPC.”

Compatibility with Non-Cluster Routing STPs

It is possible that not all STPs in the network that the EAGLE is operating in are cluster routing STPs. In such a situation, those STPs not doing cluster routing will interpret TCx messages and apply them to each individual point code belonging to the concerned cluster. This may cause an inconsistency in the status records for exception listed point codes in different STPs. In order to avoid this situation, the EAGLE takes the following steps:

1. After broadcasting a TCR message for a cluster, the EAGLE enables TFPs for the cluster’s exception listed prohibited member point codes by stopping the level 3 T8 timer. This allows TFPs to be sent for prohibited members immediately after a TCR is broadcast.

2. After broadcasting a TCA message for a cluster, the EAGLE enables a one-time TFR for the cluster’s exception listed restricted member point codes by stopping the level 3 T18 timer and enables the TFPs for the cluster’s exception listed (prohibited) member point codes by stopping the level 3 T8 timer. This allows TFPs to be sent for prohibited members and TFRs for restricted members immediately after a TCA is broadcast.

Compatibility with the ITU Network and X.25 Gateway

ITU SS7 networks do not use the concept of clusters of point codes and cluster network management messages. The EAGLE does not generate TCx messages towards ITU nodes. The EAGLE does not send TCx messages to adjacent ITU point codes during the broadcast phase of TCx messages when the EAGLE is acting as an STP between an ITU network and an ANSI network. It is possible that messages may be lost in such a case. In order to reduce message loss and quickly notify the sending ITU node about the status, the EAGLE enables TFPs or TFRs immediately (with the level 3 T8 or T18 timers stopped) and relies on the TFPs or TFRs to convey the status information.

While sending response method network management messages in response to a received MSU, the EAGLE checks the MSU’s originating point code. If the MSU’s originating point code is an ITU point code, a TFx message is returned.

Cluster entries can only be provisioned as ANSI destination point codes. Cluster entries cannot be provisioned for ITU international or ITU national destination point codes. The ANSI alias point code for an ITU international or ITU national destination point code must be a full point code. Cluster routing is not supported for X.25 destinations. X.25 destinations and any alias point codes used for X.25 destinations must be full point code entries.

Cluster Management When the Cluster Routing Feature is Turned Off

Cluster routing is an optional feature and can be turned on with the chg-feat:crmd=on command. Once this feature is turned on, it cannot be turned off. If this feature is turned off, the EAGLE does not send any cluster management messages or allow cluster destination point codes to be added to the destination point code table. The EAGLE is capable of processing incoming cluster management messages even though the feature is turned off. When a cluster management message is received, the EAGLE treats this message as though network management messages were received for each full point code, configured in the destination point code table, belonging to that cluster.

Description

The Command Class Management feature allows the user to place EAGLE commands into 32 new configurable command classes. The craftsperson can provision any of these configurable command classes to contain any of the EAGLE commands. The command classes can then be assigned to a user and/or terminal, thus allowing the user or terminal the privilege of executing any command in the class. This allows users and terminals to fully configure custom command classes. This capability is controlled via a feature access key.

Refer to the Commands Manual for current detailed information on this feature.

Hardware Requirements

No new hardware is needed to support this feature.

Limitations

There is a limitation on the feature’s operation regarding the use of the ENT-USER, CHG-USER, CHG-SECU-TRM and CHG-CMD commands. These commands can assign a maximum of eight command classes per command execution. However, subsequent command executions can be used to readily assign the full number of required configurable command classes.

Command Execution

To ensure reliability and uniqueness of pattern, a sequence of eight End of Transmission (EOT) characters (h’04) is used to indicate that the entered command has completed. These End of Transmission characters are not visible on the terminal display. This sequence, in most cases, means that all associated data output in response to the command entered has been displayed. Exceptions in which data output between the start of a command and the receipt of the EOTs may differ from the norm include the following:

• Commands with delayed completion that allow other output to be displayed (for example, copy-disk and format-disk).

• Commands that report completion but actually continue displaying results for some amount of time (for example, rept-meas).

• Commands entered in midstream of unsolicited output via Ctrl-A. For example:

Output Example for Release 22.2:

lnpstp 97-12-30 18:02:07 EST Rel 22.2.0.0
Error writing table 206:   on standby TDM (A);
>set-date:date=971201
Command Accepted - Processing
      DMS0002:table not found on disk[H’290e].
;
   lnpstp 97-12-30 18:02:07 EST Rel 220.18.0.0    set-date:date=971201    Command entered at terminal #5.
;
   lnpstp 97-12-30 18:02:07 EST Rel 220.18.0.0    Date set complete. ;(Response Ended - string of EOTs here)

Output Example for Release 24.0:

RLGHNCXA03W 99-01-07 00:57:31 EST Rel 24.0.0
Error writing table 206:
  on standby TDM (A);
>set-date:date=990301
Command Accepted - Processing
  DMS0002:table not found on disk[H’290e].
;
RLGHNCXA03W 99-01-07 00:57:31 EST Rel 24.0.0
set-date:date=990301
Command entered at terminal #5.
;
RLGHNCXA03W 99-03-01 00:57:31 EST Rel 24.0.0
Date set complete.
;(Response Ended - string of EOTs here

Description

In this feature, the database management commands are used to perform the following operations.

• Backing up the database to the fixed disk and to the removable cartridge

• Restoring the database from the fixed disk and from the removable cartridge

• Copying the approved GPLs from the active fixed disk onto a removable cartridge

• Copying the measurements data from the fixed disk onto a removable cartridge

• Displaying the directories and files on either the fixed disks or the removable cartridge

These five operations are discussed separately, below.

Backup

This command makes a backup copy of the administered data that can later be used to restore the data. The backup is made onto both the fixed disks or onto the removable cartridge according to a parameter of the command. The original data is taken from the current partition on the fixed disk.

If the backup is made to the fixed disks, the current partition on a fixed disk is copied to the backup partition on the same fixed disk.

If the backup is made to the removable cartridge, it is taken from the current partition of the fixed disk of the active MASP and copied to the removable cartridge. There is only one data partition on the removable cartridge, and this is defined to be the backup partition.

Restore

This command allows the user to bring back onto the fixed disk a set of known good tables, which had been previously backed-up on a disk (either fixed or removable). This command only restores the administered data tables, not the GPLs or measurement tables.

When the restore is from the fixed disk, the backup partition is copied into the current partition.

When the restore is done from the removable cartridge, the backup partition on the removable cartridge is copied onto the current partition on the fixed disk. This command modifies the data tables on the fixed disks of both the active and standby MASPs.

When the restore is from the removable cartridge, the tables are copied to the fixed disks on both TDMs. It does not propagate any data changes to the SCCP cards, LIMs, and so forth. To propagate the changes resulting from the restored database, the EAGLE must be reinitialized.

Copy GPL

This command copies the set of approved GPLs from the active fixed disk on the TDM onto a removable cartridge. This is typically done after the installation of a new GPL on the system, when the GPLs have been approved, and will allow the user to keep one removable cartridge with a copy of all the approved GPLs in use on the system.

These GPLs may be brought back into the system from the removable cartridge using change GPL commands if there is a need to bring a system back to a prior state, or if a spare fixed disk needs to be brought up to date.

Copy Measurements

When there is a need to perform offline analysis of the raw measurements data, this command copies that data onto the removable cartridge. The data is copied from the active fixed disk on the TDM to the removable cartridge.

Measurements collection is not allowed to continue while this command is copying the tables, since this may result in data from one collection period spilling over into data from another collection period. Measurements cannot be copied if measurement collection is turned on. Measurement collection must be turned off if you wish to copy the measurements tables.

Since there are two formats for removable cartridges, and only one of these is valid for measurements, the command will give a clear error message if the wrong type of removable cartridge is mounted in the drive.

Disk Directory

This command displays the directory on the specified disk. It can be used to display the creation date for each file or selected files and to verify that the correct version of files are on the fixed disks or the removable cartridge.

Description

This feature provides some level of user control over the TCP retransmission behavior that an individual TALI socket exhibits. Several aspects of TCP retransmissions need to be introduced in order to understand how this delay versus throughput feature will work.

As far as this feature is concerned, there are three primary aspects of TCP retransmissions that need to be understood.

• Retransmission timer

• Retransmission mode

• Congestion window

Retransmission Timer

Conceptually, the TCP retransmission timer is a timer that is started when a TCP data segment is sent on a socket. The TCP data segment is encapsulated in an IP packet (we will refer to this data segment being sent as a TCP packet, even though TCP is a byte oriented transport layer that does not typically send 'packets'). If an acknowledgement for the TCP packet arrives before the timer expires, the timer is stopped. If the timer expires before an acknowledgement arrives, the original packet is assumed to be lost/corrupted and a retransmission of that packet occurs.

In practice, most TCP implementations do not start a separate timer for each packet, rather an internal timer expiration occurs at a fixed interval and upon each internal timer expiration the data related to outstanding transmit packets without acknowledgements is analyzed to determine which retransmissions occur. It may take multiple expirations of the internal timer until the overall timeout exceeds the retransmission timer. Therefore the actual time delay for each initial retransmission falls within a range determined by the frequency of the fixed timer expiration. For example, if a 50 millisecond internal timer is used, and it takes three expirations of the internal timer until a retransmission occurs, the actual timeout used varies from 101 milliseconds to 150 milliseconds.

In this document, the term 'internal retx timer' refers to the internal TCP timer that expires at a fixed interval regardless of how many transmit packets are outstanding. Upon each internal retx timer expiration, retransmissions are analyzed and possibly sent.

In this document, the term 'initial retransmission timeout' refers to the minimum amount of time that passes from when a packet is first transmitted until the initial retransmission occurs. It is important to note that the timeout refers to the minimum time before retransmission (not the maximum or average).

In this document, the term 'retransmission timeout' refers to the minimum amount of time that passes until the next retransmission occurs. The pending retransmission may or may not be the first retransmission based on the condition being described. The 'retransmission timeout' always refers to the current timeout.

In this document, the terms 'previous retransmission timeout' and 'next retransmission timeout' refer to the minimum timeouts before and after the current retransmission timeout.

Retransmission Mode

The retransmission mode refers to how the timeout varies from previous to current to next retransmission timeout.

There are several modes discussed in this document.

• BSD mode refers to exponential growth of the timeout. Upon each timeout the next retransmission timeout is equal to 2 x the current retransmission timeout. Usually there is an upper limit on the exponential growth (exponential up to a threshold, then stays at the threshold).

• FIXED mode refers to a constant timeout that does not change as subsequent retransmissions of the same packet occurs.

• MODIFIED mode refers to a combination of the above two modes. One implementation of this mode may use a fixed mode for two out of every three consecutive retransmissions, shifting to the BSD mode on every third retransmit.

The following figure shows the relative spacing of timeouts for the three different retransmissions modes. Note that the spacing for BSD mode is incomplete due to its relatively long sequence

Figure 2-15 Spacing of Retransmissions in the Three Modes

• The TCP protocol uses a sliding window to determine how much transmit data can be sent at one time, based on the minimum of the node's transmit window size and the far end's receive window size. The default TCP sliding window size is 8K bytes. Once 8K bytes of transmit data have been sent, with no acknowledgements received, the transmitter is prohibited from sending more until the far end sends acknowledgments for some portion of the window. The TCP window is said to slide when acknowledgments arrive, allowing packets with higher sequence numbers to be sent as packets with lower sequence numbers are acknowledged.

• Even though a particular socket within a TCP stack is configured for an 8K sliding window size, there are times when the TCP protocol does not take advantage of the entire 8K sliding window. One of these times is when retransmissions occur.

• When the TCP layer needs to retransmit one or more packets on a socket, the TCP protocol uses the minimum congestion window size rather than the TCP sliding window size to limit how much traffic can be sent until it must wait for acknowledgments. The minimum congestion window size is typically much less than the TCP sliding window size. As acknowledgments arrive from the far end after a retransmission event, the node slowly grows the congestion window up from the minimum congestion window to the size of the TCP sliding window.

• Another way of looking at this aspect of retransmission is to state that when a retransmission occurs, a transmitter intentionally lowers its own throughput until enough evidence from the far end arrives to assure the transmitter that the network is not congested. This phenomena is also referred to as congestion avoidance.

Socket Connection Dropped due to Retransmission Timeouts

• One other aspect of TCP retransmissions that should be mentioned is what happens when the same packet gets retransmitted over and over. When multiple retransmissions occur for a single packet, the TCP layer counts the number of retransmissions that is performed, and when this count gets too high the TCP socket is closed due to excessive retransmission timeouts. This shows up in the netstat -p tcp output in the 'connection dropped by rexmit timeout' row.

• In the BSD TCP stack, when a packet has been retransmitted 12 times, the socket is closed. Given the use of the exponential retransmit mode in standard BSD, the 12 retransmissions correspond to a time period of approximately 205.5 seconds where the packet was not able to sent/ack'd. (205.5 is based on 500 ms x 511, 511 is the sum of the tcp_backoff[] array which governs how the exponential backoff occurs and when the top threshold is reached).

• In the IP⁷ SG stack, when a packet has been retransmitted 12 times, the socket is closed. Given the use of fixed retransmission mode with a 125ms timer, the 12 retransmissions correspond to a time period of approximately 1.5 seconds where the packet was not able to be send/ack'd.

Behavior of Standard BSD Sockets

The following table summarizes the TCP retransmission characteristics of a standard BSD socket.

BSD sockets are extremely tolerant of poor network conditions and continue to wait for longer and longer time periods before performing subsequent retransmissions. These characteristics are not very well suited for time sensitive data such as SS7.

Behavior of IP⁷ SG Release 4.0 IPLIMX & IPGWX Sockets

The following table summarizes the IPLIMX & IPGWX retransmission characteristics present in the IP⁷ SG Release 4.0 product.

IPLIMX & IPGWX sockets have been tuned to handle time sensitive data and expect network conditions with low RTT and few transmission errors. The configuration shown above is not tolerant of networks with RTT above a certain threshold (approximately 100ms) or with too many transmission errors. The 4.0 implementation does not expect packet loss due to congestion. The only loss that is expected is due to hardware and/or transmission errors, bad checksums, and so forth. The 4.0 implementation expects little or no congestion on the network, and does not react in a fair manner (with respect to congestion avoidance) when congestion does occur.

Behavior of IP⁷ SG Release 5.0 IPLIMX & IPGWX Sockets

The following table summarizes the IPLIMX and IPGWX retransmission characteristics that are available in the IP⁷ SG Release 5.0 product.

As seen in the tables above, the Delay vs. “Throughput for TALI Sockets” feature allows the end user to tune the retransmission characteristics of individual sockets. Sockets can be set so that they can function in a variety of network conditions (for example, LAN connection vs. a trans-Pacific WAN connection).

Upgrade Considerations

The addition of two new parameters in the entry (in the Socket Table) for each TCP/IP Socket necessitates the need for changes to the Upgrade Procedures for Engineering Release 37. These two new fields, Retransmission Mode and Round Trip Time Value, must be initialized to default values. The Retransmission Mode is initially set to "FIXED", with the Round Trip Time set to 60 milliseconds. A third field, the Congestion Window Lower Limit must be set to a calculated value using the default Round Trip Time (60 milliseconds). These fields must be set up for every assigned socket. The upgrade applies to both the OAM and Application copies of the Socket Table.

Limitations

The TCP/IP Protocol Stack timing mechanism has been modified by Tekelec software engineers. These changes enable the protocol to support TCP timers with resolutions as low as 125 milliseconds. It is not within the scope of the "Delay Vs. Throughput for TALI Sockets" feature to implement any other TCP timer resolutions than those currently supported. Each value entered as part of the Round Trip Time parameter is mapped to a corresponding Retransmission Timer, with a resolution of 125 milliseconds.

Description

G-Port and G-Flex allow the SCCP CdPA GTA field to be overwritten if G-Port determines the call should be relayed to its destination after a PDB lookup is performed.

G-Port and G-Flex support options that can be selected to overwrite or not to overwrite the SCCP CdPA GTA field. These options are defined by the DigitAction field of the PDBI Enter Network Entity command and Update Network Entity command. The user can also set these options to format the SCCP field before the EAGLE relays the message to the destination.

The rules for formatting the SCCP CdPA GTA field are based on the value specified in the DigitAction field. If digitaction = none, the EAGLE 5 ISS does not overwrite the SCCP CdPA GTA field. For all other values, the EAGLE 5 SAS formats the SCCP CdPA GTA field according to the value assigned to DigitAction field.

The following table provides samples of the format of the SCCP CdPA GTA field of an outgoing message using RN/SP ID= 1404 and default country code=886.

This feature expands the DigitAction field in PDBI and the EPAP GUI to support additional values "delcc," "delccprefix," "spare1," and "spare2." If the DigitAction value is "delccprefix," the SCCP CdPA GTA field of an outgoing message is formatted by prepending the RN/SP ID to the incoming SCCP CdPA GTA field and deleting the default country code if present. If the DigitAction value is "delcc," the SCCP CdPA GTA field of an outgoing message is the incoming SCCP CdPA GTA field without the default country code if present. The result of specifying the DigitAction field values “spare1” and “spare2” is the same as specifying the value “none.”

Hardware Requirements

Refer to the hardware baseline.

Description

This feature enhances the rept-stat-alm report to show all the devices that are alarm-inhibited, at what level and duration they are inhibited, and their current alarm level, if any.

Use of the Display Parameter

• If DISPLAY=INHB is used, a plus sign (+) seen in the “Alarm Inhibit Report” (i.e. in the CUR ALM LVL column) indicates that the current alarm is not inhibited, because the level of the inhibit is less than the level of the alarm.

• Column description:

  • Device and element is listed first. Only devices that are alarm inhibited are shown.

  • Duration shows whether the device is alarm inhibited permanently or temporarily.

  • The “alm inh lev” shows the level in which devices are alarm inhibited. The inh-alm command defaults level to major. Devices cannot be alarm inhibited at a critical level unless the stpopt critalminh is turned on.

  • The “current alm lev” shows the level of the current alarm on that device. “None” means there is no alarm currently on that device. If there is no alarm currently on that device, the Duration should show “Perm.”

Hardware Requirements

No new hardware is needed to support this feature.

Description

Instead of a card having to be removed to change the configuration, each card can be configured using new commands and extensions to existing commands. This capability allows customers ease of configuring and updating their network using the EAGLE. Also, since the DIP switches are no longer required, they can be removed from future production E1 appliques.

With the introduction of this feature, the administration of the E1 will be done by EAGLE commands. Thus various EAGLE commands have been created or modified.

Currently E1 cards are "provisioned" via dip switches on the LIM board. Although this method of provisioning is functional, customers desire to integrate the provisioning of E1 functionality similar to other LIM cards, via software. This feature enhances the current 2-Port E1 feature by allowing the customer to configure the E1 hardware without using the DIP switches on the applique. This feature also provides support for E1 Master Timing.

Description of E1 Operation within an EAGLE

The introduction of this feature brings complete product support for the E1 line interface into the EAGLE, thereby concluding the E1 effort begun during Release 22.2. Along with V.35, the E1 interface is a primary interface used outside of North America. Thus, this large market base is a large market potential for an EAGLE with an E1 interface.

The E1 cards are provisioned and operate in a fashion very similar to the current DS0/OCU/V.35 signaling links:

• E1 cards and links must be configured in the EAGLE in a manner similar to how existing signaling links are configured. These configuration activities include entering cards, entering links, assigning links to link sets, and activating cards and links, in addition to entering E1 parameters. Changes to existing EAGLE commands, and new EAGLE commands, to perform these configuration activities are required.

• Two new card types, 'LIME1' and 'LIMCH', are used to define the E1 card and Channel cards, respectively, in the EAGLE.

• A set of E1-specific interface parameters must be maintained on a per-E1 basis. These parameters include:

  • which E1 port is used (either #1 or #2)

  • CRC4, CAS/CCS, HDB3/AMI, master/slave clocking options

  • signaling bits settings

• A set of E1-specific interface parameters must be maintained on a per-signaling link basis. These parameters include:

  • which E1 card is the card dropping timeslots

  • which timeslots are being used

• The current E1 implementation provisions E1 cards as either DS0 or OCU, based on master/slave timing. This feature provisions the cards as E1 or channel with either master or slave timing.

• Building Integrated Timing System (BITS) clock alarms must be supported when E1 cards with master timing are provisioned in the EAGLE. Currently, this is the reason that E1 cards are provisioned as DS0 cards.

The TST-SLK command will continue to support local transceiver loopback using the ISCC, just like the DS0/OCU/V.35 cards; no changes are necessary.

EAGLE Application Support for E1

Currently the SS7 application software initializes the hardware completely based on DIP switch values. With the new E1 Administration and Alarms feature allowing E1 cards to be provisioned, the SS7 application software needs to only initialize the hardware to a benign state until provisioning information is provided. This initial hardware state is similar to the other link interface module (LIM) cards' initial state.

Hardware Requirements

This feature is dependent upon the EAGLE E1 hardware, consisting of the LIM E1 backplane kit (P/N 890-1037-01), which allows connectivity between the E1 LIM card(s) and the corresponding E1 channel card(s) (both P/N 870-1379-01).

Upgrade Considerations

• The system release containing the E1 Administration and Alarms feature must be field-upgradable, with the EAGLE in an in-service mode.

• The new current and backup tables for E1 link interface parameter values must be created.

• A new phase is needed in the upgrade procedure to update the database with E1 information retrieved from the network cards after the network cards have been loaded with the latest GPL.

• Prior to collecting E1 information, cards will be loaded with the latest GPL with data from the database, including link information. Cards containing existing E1 links must load and bring up their SS7 links using the DIP switches instead of downloaded E1 data in this case.

• Card type field in the current and backup IMTA tables needs to be corrected from DS0/OCU based on information received from each card.

• E1 parameter information needs to be updated in current and backup E1LINK tables.

• E1 timeslot information needs to be updated in current and backup LINK and XLINK tables.

• Since upgrade must be able to be performed remotely, there must be an automated way to map the E1/Channel card relationship via some method such as far-end loopback detection.

• Since TS0 and TS16 (when CAS is enabled) may be assigned using the DIP switches, the upgrade must detect and report this condition. However, no change can be made to the timeslots.

Limitations

The E1 Administration and Alarms feature has these limitations:

• The configuration of the various E1/channel cards via the E1 backplane is not validated with the E1 parameter set information.

• There is no verification that the E1 and channel cards are connected to the E1 backplane.

Description

International customers desire increased signaling bandwidth by utilizing Asynchronous Transfer Mode (ATM). This capability requires EAGLE software to support ATM, as well as some hardware modifications to the existing LIM-ATM card that currently supports ATM over T1. The existing HCAP design for the LIM-ATM, with some modifications to the appliqué, is being used to accommodate the E1 ATM connectivity to the EAGLE.

This feature provides a new E1 interface capability on the EAGLE. This new capability is provided using the existing LIM-ATM via an HCAP card, a new Applique' ATM (AATM) daughterboard, and a new GPL. A modified LIM-ATM supporting 2.048 Mb/sec is here referenced as an E1 ATM card. The E1 ATM capability supports a single ATM Virtual Channel Connection (VCC) at a line speed of 2.048 Mbps. The E1 ATM replaces the MTP layers 1 and 2, (ITU-T Q.702 and ITU-T Q.703) with an ATM-based protocol (ITU-T Q.2110, Q.2140 and Q.2144). ATM is used as the transport technology for carrying the signaling information via PDU's between network nodes.

Refer to the NSD Hardware Manual for detailed hardware information.

New Hardware

E1 ATM LIM provides one Asynchronous Transfer Mode over E1 Interface at 2.048 Mbps, (P/N 870-1293-xx). This module uses an E1 Asynchronous Transfer Mode Applique (E1 ATM) installed on a High Capacity Application Processor (HCAP) main assembly. The E1 ATM applique provides a new communications capability on the EAGLE, a High Speed Link (HSL) using ATM over E1. This capability is provided using the existing HCAP card, a new applique, and a new GPL (ATMITU).

Refer to the NSD Hardware Manual for detailed hardware information.

Limitations

OAM F5 Performance Monitoring

ATMANSI does not provide OAM F5 performance monitoring. This capability has not been added for this feature. Because the anticipated deployment of this feature is as a direct connection, performance monitoring of the network is not anticipated to supply any additional information that SAAL does not.

OAM F5 Fault Management

ATMANSI only provides OAM F5 fault management for OAM loopback. It does not provide support for alarm surveillance and continuity check. These capabilities have not been added for this feature. Because the anticipated deployment of this feature is as a direct connection, fault management of the network is not anticipated to supply additional functionality. Connection issues will be detected by the SAAL and the link will be deactivated if appropriate.

Traffic Size

Traffic size will have a definite impact on MSU throughput of the system; see table.

AMI

AMI is not supported in this release. HDB3 is the only supported encoding option for the E1 ATM card.

OVERSIZE MESSAGES

Oversize messages (>272 octets) will not be supported in this release. This limitation is a holdover from ATMANSI.

A general purpose implementation of the ATM HSL protocol stack would allow for 'Large MSUs' to be transferred across the physical link. The SSCOP layer is capable of handling data from SSCF that is up to 4096 byes long. Since SSCF does not add a trailer to MTP3 data, this equates to an MTP3 packet of 4096 bytes.

However, the current implementation of the ATM HSL stack restricts the largest MSU size to 272 bytes of MTP3 data. This restriction will be used for this feature, and as in the ATMANSI gpl, a the same UIM will be generated with a Large MSU is received.

Description

The E1/T1 MIM on EPM feature provides a single-slot, high-density E5-E1T1 card for channelized E1 and T1 link solutions. This card can be operated with a 40 Amp frame-level power budget and does not require a fan.

The E5-E1T1 card can be assigned a maximum of 32 signaling links of configurable channelized T1 connectivity. The links on the card can operate in a linkset with other links running at different speeds. The total number of provisioned T1 links cannot exceed the allowed system maximum (the quantity shown for the Large System # Links entry in the rtrv-ctrl-feat command output).

The E5-E1T1 card terminates 8 E1/T1 ports (trunks) and routes them to the A and B ports of the EAGLE 5 ISS backplane. These ports can be configured to select which E1/T1 ports are active and which channels on each port are used for signaling links.

The E5-E1T1 card supports one SE-HSL signaling link on one of the eight ports. Channelized operation is not possible on any E5-E1T1 card that is provisioned for SE-HSL. SE-HSL requires a Feature Access Key on a system level basis. The E5-E1T1 card provides copying and time-stamping of MSUs for all provisioned signaling links (up to 32 LSLs or 1 SE-HSL) simultaneously when the EAGLE 5 Integrated Monitoring Support (E5IS) feature is turned on.

Modes of Operation

The E5-E1T1 card can be provisioned to operate in the E1 or T1 mode. The mode of operation defines the trunk format for the 8 ports on the card.

Along with the T1 mode, the E5-E1T1 card provides a Channel Bridging function that allows users to utilize T1 bandwidth that is not used by EAGLE 5 ISS signaling links. T1 ports 1, 3, 5, and 7 (master ports) can be independently channel bridged with their adjacent even-numbered (slave) T1 ports 2, 4, 6, and 8 to allow non-signaling data pass-through.

In T1 mode, the E5-E1T1 card generates an idle code in idle (unused) time slots. If the Channel Bridging function is used, idle codes are inserted into timeslots on even ports corresponding to the reflected signaling channels on the odd port.

EAGLE 5 ISS supports the Channel Bridging function for all combinations of master/line timing modes invoked by the adjacent equipment. Internal clock selection criteria ensure synchronous data paths through the bridged channels.

Thermal Management

The E5-E1T1 card includes and alarming provisions to protect the card from damage if environmental conditions hinder thermal stability. The EAGLE 5 ISS responses to increasing temperatures are as follows:

• Temp1 Exceeded—Major alarm raised
• Temp2 Exceeded—Critical alarm raised; failover initiated, traffic rerouted
• Temperature abated. Normal operation restored

Hardware Requirements

The E1/T1 MIM on EPM feature has the following hardware requirement::

• HIPR cards are required on each shelf that contains E5-E1T1 cards.

Limitations

The E1/T1 MIM on EPM feature has the following limitation:

• The E1 functions are not supported in EAGLE 5 ISS Release 35.0.

Description

The E1/T1MIM on EPM feature enhances the E1/T1 MIM on EPM feature from Release 35.0 by adding EAGLE 5 ISS support for E1 functionality and SE-HSL links. This Feature Notice documents only these enhancements. Refer to the EAGLE 5 ISS 35.0 Feature Notice for a detailed discussion of the E1/T1 MIM on EPM feature.

With support for the E1 functionality, the E5-E1T1 card can terminate 8 E1/T1 ports (trunks) and route them to the A and B ports of the EAGLE 5 ISS backplane. These ports can be configured to select which E1/T1 ports are active and which channels on each port are used for signaling links.

The E5-E1T1 card supports one SE-HSL signaling link on one of the 8 ports. Support for SE-HSL requires a system-level Feature Access Key.

The E5-E1T1 card provides copying and time-stamping of MSUs for all provisioned signaling links (up to 32 low-speed links ) simultaneously when the EAGLE 5 Integrated Monitoring Support (E5IS) feature is turned on.

Modes of Operation

The E5-E1T1 card can be provisioned to operate in the E1 or T1 mode. The mode of operation defines the trunk format for the 8 ports on the card.

In T1 mode, a port represents a time-division-multiplexed data stream of 24 channels with an aggregate data rate of 1.544 Mbps. In E1 mode, a port represents a time-division-multiplexed data stream of 32 channels with an aggregate data rate of 2.048 Mbps.

E1 and T1 port configurations cannot be mixed on a single card. The E5-E1T1 card provides a Channel Bridging function that allows use of E1T1 bandwidth that is not used by EAGLE 5 ISS signaling links. E1 and T1 ports 1, 3, 5, and 7 (master ports) can be independently channel bridged with their adjacent even-numbered (slave) E1 and T1 ports 2, 4, 6, and 8 to allow non-signaling data pass-through.

In the E1 or T1 mode, the E5-E1T1 card generates an idle code in idle (unused) time slots. If the Channel Bridging function is used, idle codes are inserted into timeslots on even ports corresponding to the reflected signaling channels on the odd port.

EAGLE 5 ISS supports the Channel Bridging function for all combinations of master/line timing modes invoked by the adjacent equipment. Internal clock selection criteria ensure synchronous data paths through the brIdged channels.

Hardware Requirements

The E1/T1 MIM on EPM feature requires HIPR cards on each shelf that contains E5-E1T1 cards.

Limitations

The E1/T1 MIM on EPM feature has the following limitations:

• E1 and T1 port configurations cannot be mixed on a single card.

• Channelized operation cannot be performed for any E5-E1T1 card that supports SE-HSL links.

The E1/T1 Multi-Channel Interface Module (MIM) provides increased E1 signaling connectivity and a channelized T1 connection to the EAGLE STP.

The MIM increases the number of SS7 links (ports) the EAGLE handles per E1 card. This allows the EAGLE to interact in larger SS7 networks, as well as decreases the footprint of an EAGLE (i.e. previously 250 cards were required to support 500 links; now only 63 cards are required). The E1/T1 MIM can be used in systems equipped with either the IPMXor the HMUX board. The MIM also provides a new channelized T1 connection to the EAGLE. The MIM can replace an existing LIME1/LIMCH card (as an E1 terminating card or E1 channel card), with no reprovisioning required. E1 MIM is hot-swappable with LIM-E1.

The E1/T1 Multi-Channel Interface Module (MIM) card has 2 physical backplane port connections, as other LIM cards do. These are referred to here as interface A and interface B. For the E1/T1 MIM, as with the existing LIM-E1 card, interface A has 2 ports of E1/T1 connectivity. These 2 ports are referred to as port #1 and port #2. Interface B provides the expansion port to service channel cards.

Refer to the Database Administration Manual - SS7 for detailed and configuration information.

Hardware Requirements

No new hardware other than the new MIM card itself (870-2198-01) is needed to support this feature.

For detailed information on hardware, refer to the NSD Hardware Manual.

The E5-E1T1-B card (Part Number 870-2970-01) is a single slot card based on the EPM-B module and can be inserted in slots provisioned for SS7ANSI or CCS7ITU applications.

The E5-E1T1-B card is provisioned using the ent-card command with the type=lime1 or type=limt1 parameter. The appl=ss7ansi parameter is used for ANSI, and the appl=ccs7itu parameter is used for ITU.

The E5-E1T1-B card provides eight E1 or T1 termination ports, processing up to 32 signaling links of configurable channelized E1 or T1 connectivity. The eight ports reside on backplane connectors A and B. All ports on a single E5-E1T1-B card must operate in the same carrier scheme of E1 or T1. An EAGLE node can have a mix of E1 and T1 signaling links with some E5-E1T1-B cards operating in E1 mode and other E5-E1T1-B cards operating in T1 mode.

The maximum provisionable links for the E5-E1T1-B card is 32 links. Total system signaling link capacity depends on other cards in the system and the enabled features, and must not exceed the provisioning limit of the EAGLE.

Channelized Mode

The E5-E1T1-B card provides access to eight E1 or T1 ports residing on backplane connectors A and B. Each data stream consists of 24 T1 or 31 E1 signaling links assigned according to a Time-Division Multiplex (TDM) scheme. Each channel occupies a unique timeslot in the data stream and can be selected as a local signaling link on the interface card. Each card can select up to a total of 32 signaling links.

Channel Bridging

Channel Bridging is the processing of signaling channels that are intermixed on trunks with voice or data channels. The E5-E1T1-B card provides Channel Bridging which allows for better utilization of bandwidth without dedicating entire trunks to signaling. Non-signaling channels are bridged to an adjacent E1 or T1 port for transport to other network devices. Signaling channels are merged to non-signaling data for transmission to the mixed network.

E5-ENET-B with EROUTE

E5-ENET-B cards can be used in slots that are provisioned for the EROUTE application. The card is provisioned using the ent-card command with type=stc and appl=eroute.

E5-ENET-B with IPGWx, IPLIMx, SS7IPGW

E5-ENET-B cards can be used in slots that are provisioned for the IPGWI, IPLIM, IPLIMI, or SS7IPGW application. The card is provisioned using the ent-card command with type=dcm and appl=ipgwi/iplim/iplimi/ss7ipgw.

E5-ENET-B with IPS

See IPS Application on E5-ENET-B (Release 44.0) for information on the E5-ENET-B card running the IPS application.

E5-ENET-B with IPSG

E5-ENET-B cards can be used in slots that are provisioned for the IPSG application. A new ENETB card type is introduced for use with the E5-ENET-B card and IPSG application. The card is provisioned using the ent-card command with type=enetb and appl=ipsg.

An E5-ENET-B card with the IPSG application has a capacity of 6500 TPS. If E5-ENET-B cards are installed in slots that are provisioned for E5-ENET cards, then the E5-ENET-B cards process at 5000 TPS. If an E5-ENET card is installed in a slot provisioned for an E5-ENET-B card, then the E5-ENET card auto-inhibits.

If the E5-ENET-B IPSG High Throughput (Release 44.0) feature is turned on, then the E5-ENET-B cards process at rates up to 9500 TPS.

E5-ENET-B with STPLAN

E5-ENET-B cards can be used in slots that are provisioned for the STPLAN application. The card is provisioned using the ent-card command with type=dcm and appl=stplan.