The Large MSU Support for IP Signaling feature allows the Large BICC MSU Support for IP Signaling feature to support additional service indicator (SI) values. As part of this feature, the Large BICC MSU Support for IP Signaling feature is now referred to as the Large MSU Support for IP Signaling feature.

The Large MSU Support for IP Signaling feature supports MSUs with a SIF size of up to 4095 bytes for M2PA and M3UA protocols with SI values from 6 - 15.

The SI values are:

• 6, 7—Data
• 9—Broadband ISDN
• 10—Satellite ISDN
• 13—BICC
• 14—H.248
• 8, 11, 12, 15—Spare

The SLAN, Database Transport Access (DTA), and E5IS features do not support Large MSUs.

The level 2 SS7 data is divided into 2 groups, service data and alignment data.

Service data is a running history of when the link comes in service and goes out of service. The history contains the reason the link fails from the perspective of Level 2 along with the timestamp. This information can be used to help solve whether the near end or far end node is responsible for causing the link to fail. This is a list of all the possible level 2 link failure reasons.

• RC/BSNR link failure — Received two out of three invalid backward sequence numbers from the far end. The far end office should be contacted to determine why invalid BSNs are being sent.

• RC/FIBR link failure — Received two out of three invalid forward indicator bits from the far end. The far end office should be contacted to determine why invalid FIBs are being sent.

• SIE received — Received status indication of Emergency from the far end. An SIE indicates the far end is now being aligned. The far end office should be contacted to determine why an SIE was sent.

• SIN received — Received status indication of Normal from the far end. An SIN indicates the far end is now being aligned. The far end office should be contacted to determine why an SIN was sent.

• SIO received — Received status indication of Out of Alignment from the far end. An SIO is sent when the node begins initial alignment. The far end office should be contacted to determine why an SIO was sent.

• SIOS received — Received status indication of Out of Service from the far end. An SIOS is sent upon completion power up until initial alignment is started. An SIOS is also sent when the far end cannot transmit or receive message signal units for reasons other than processor outage. The far end office should be contacted to determine why an SIOS was sent.

• Stop commanded — Level 3 commanded Level 2 to stop.

• Stopped receiving data — No data is being received on the signaling link. Check the physical connections of the signaling link. Using an analyzer, test for level 1 and level 2 functions.

• SUERM link failure — Signal Unit Error Rate Monitor (SUERM) counter exceeded threshold. The SUERM maintains a counter to estimate the signal unit error rate. The far end office should be contacted to determine why the error rate is high.

• Too many ISCC interrupts — Too many interrupts received over the link.

• TXC/T6 expired — Remote congestion timer expired. The far end is in congestion too long. The far end office should be contacted to determine why BSN and BIB are not being sent.

• TXC/T7 expired — Excessive delay of acknowledgment timer expired. Far end taking too long to acknowledge the messages sent to it by the near end. The far end office should be contacted to determine why the delay in acknowledging MSUs.

The level 2 link failure reason shows which node on the link caused the fault and why. If the history shows the link did not realign after the failure, the alignment data buffer shows the reason the link was unable to be realigned.

Alignment data is a running history of Level 2 alignment events with timestamps. This information can be used to help solve why the link does not realign.

Alignment events are buffered during the out of service, initial alignment, aligned/ready and aligned/not ready states. Only the first unique occurrence of an event and its timestamp is buffered. Alignment events are transmitted signal units, received signal units, level 3 commands, level 2 status and state transitions. The following table lists all the possible alignment events sorted by event type. Realignment may fail for reasons other that the events listed in the table. For example, realignment fails if an SIO is received when the link is in the aligned/ready state. Therefore, the failure reason is displayed as an abnormal link state control state transition.

These are definitions of the alignment failure reasons.

• AERM/Abort proving - Alignment Error Rate Monitor (AERM) counter exceeded threshold. AERM increments a counter if it detects an error in the signal unit. Aborting the proving period causes the proving period count to be incremented. If the proving period count exceeds its threshold, the link will fail with the Level 2 Exceeded proving period count failure reason. The far end office should be contacted to determine the cause for the high error rate.

• Exceeded proving period count - The proving period was aborted five times by the AERM before the proving period timer expired. The far end office should be contacted to determine the cause for the high error rate.

• RC/BSNR link failure — Received two out of three invalid backward sequence numbers from the far end. The far end office should be contacted to determine why invalid BSNs are being sent.

• RC/FIBR link failure — Received two out of three invalid forward indicator bits from the far end. The far end office should be contacted to determine why invalid FIBs are being sent.

• Stop commanded — Level 3 commanded Level 2 to stop.

• Stopped receiving data — No data is being received on the signaling link. Check the physical connections of the signaling link. Using an analyzer, test for level 1 and level 2 functions.

• SUERM link failure — Signal Unit Error Rate Monitor (SUERM) counter exceeded threshold. The SUERM maintains a counter to estimate the signal unit error rate. The far end office should be contacted to determine why the error rate is high.

• T1 expired - Align/Ready timer expired. Far end is not responding during Aligned/Ready or Aligned/Not Ready states before timer expires. The far end office should be contacted to determine why the far is not responding.

• T2 expired - Not aligned timer expired. Far end is not responding during Not Aligned Initial Alignment Control state before timer expires. The far end office should be contacted to determine why the far end is not responding.

• T3 expired - Aligned timer expired. Far end is not responding during Aligned Initial Alignment Control state before timer expires. The far end office should be contacted to determine why the far end is not responding.

• Too many ISCC interrupts — Too many interrupts received over the link.

The service data and alignment data is displayed with the L2stats parameter of the rept-stat-slk command. The L2stats parameter has the following values:

no = don’t display Level 2 status information (the default value)

align = display alignment data only

service = display service data only

both = display both alignment and service data

brief = display at most last 10 alignment data events only

The alignment data is displayed in a three column format. Column 1 is the type of event that was buffered. Column 2 is the event. Column 3 is the timestamp for the event.

The service data is displayed in a two column format. Column 1 contains the event. Column 2 has the corresponding timestamp.

The following is an example of how the service data and alignment data is displayed.

Input/Output Examples

rept-stat-slk:loc=1203:port=b:L2stats=both

SLK    LSN       CLLI        PST            SST       AST
1203,B lsnsspn2  ----------- OOS-MT-DSBLD   LPBK     ISCC

Event Type Event                Timestamp
Transmit   SIOS                 97-06-07 10:04:23.000
State      Out of Service       97-06-07 10:04:23.000
State      Initial Align        97-06-07 10:05:31.100
State      Idle                 97-06-07 10:05:31.100
Transmit   SIO                  97-06-07 10:05:31.105
State      Not Aligned          97-06-07 10:05:31.105
Receive    SIO                  97-06-07 10:05:46.425
Transmit   SIN                  97-06-07 10:05:46.430
State      Aligned              97-06-07 10:05:46.430
Receive    SIN                  97-06-07 10:06:02.110
State      Proving              97-06-07 10:06:02.120
Receive    SIN                  97-06-07 10:06:02.885
State      Idle                 97-06-07 10:06:53.625
Transmit   FISU                 97-06-07 10:07:14.000
State      Align/Ready          97-06-07 10:07:14.000
Receive    FISU                 97-06-07 10:08:01.760
State      In Service           97-06-07 10:08:01.760

Service Event       Timestamp
In Service          97-06-07 02:11:54.875
SIOS received       97-06-07 05:40:10.160
In Service          97-06-07 05:42:12.235
SIOS received       97-06-07 09:37:02.100
In Service          97-06-07 09:38:55.995
SUERM link failure  97-06-07 10:02:02.125
In Service          97-06-07 10:08:01.760

rept-stat-slk:loc=1203:port=b:L2stats=brief

SLK    LSN       CLLI        PST            SST       AST
1203,B lsnsspn2  ----------- OOS-MT-DSBLD   LPBK     ISCC

Event Type Event                Timestamp
Transmit   SIOS                 97-06-07 02:44:23.000
State      Out of Service       97-06-07 02:44:23.000
State      Initial Align        97-06-07 02:45:31.100
State      Idle                 97-06-07 02:45:31.100
Transmit   SIO                  97-06-07 02:45:31.105
State      Not Aligned          97-06-07 02:45:31.105
State      T2 Expired           97-06-07 02:45:46.425

If a card is unplugged, the link status information is lost.

The alignment data buffer and service data buffers are circular buffers that can hold 69 events.

The level 2 statistics can only be displayed for SS7 LIMs. If the specified signaling link is not an SS7 LIM, the command is rejected and this message is displayed.

Error Message

E2918 Cmd Rej: Link must be SS7 to display Level 2 stats

Proper functionality of a signaling link (SLK), from an EAGLE MTP card to a remote Network Element, is determined through a variety of mechanisms provided by EAGLE. This feature covers two main areas of improvement to these mechanisms. These improvements are the introduction of an operator command to force a signaling link into local line-oriented loopback and the enhancement of the TST-SLK command to allow for duration tests up to 24 hours.

The LFS Increase for MPL-T and MIM feature increases the number of simultaneously initiated Link Fault Sectionalization (LFS) tests on the MPL-T, T1 MIM and CR-T1 MIM from 1 to at least 4.

The current method for reporting link unavailability requires the user to decipher several print outs. The first report informs the user of the link status, while subsequent reports detail the reasons for the status change. This feature provides a single report informing the user of the link unavailability with the corresponding reason. This report is generated by the rept-stat-slk command. If there are multiple reasons for the link becoming unavailable, the user is informed of the highest priority cause.

The rept-stat-slk command output is expanded to display new error codes in the Unvail Cause field for each of the link unavailability causes detailed in the following table. Two lines of information for the Unavail Cause field are displayed if conditions require it.

When an unavailability cause clears, the alarm text is displayed for the next highest priority cause.

When the last unavailability cause clears, a link available message (UAM 200) is displayed.

The signaling link unavailability messages use Bellcore recommended keywords in the output message. The following table shows the keywords that are supported in Release 21.0.

The signaling link unavailability messages also support Bellcore signaling link related keywords, link unavailability messages have been updated to support SEAS link failure cause codes shown in Section 8 of the SEAS-STP Interface Specification, GR-310-CORE, Issue 1, November 1994. These standard three letter codes denote the reason for link failure.

This feature provides an optional alternate routing determination algorithm that is more tolerant during linkset transitions and reduces the likelihood of experiencing congestion on linksets that do not have a sufficient quantity of available links to carry normal traffic loads.

This feature prevents congestion on newly available linksets for GT routed traffic in addition to MTP routed traffic.

This feature supports ITU linksets and ANSI linksets.

Transfer Restricted (TFR) procedures support ITU-N linksets only if the ITU TFR option is turned on for the linkset. ITU-I linksets do not support TFR procedures. However, the restricted status for a route internal in the EAGLE still applies for ITU linksets when the lsrestrict option is on. The user can set the number of links required to a higher number just like ANSI linksets.

The restricted status for a route internal in the EAGLE still applies for ITU linksets when the lsrestrict option is on.

For routing path decisions, two factors determine what route (linkset) a message should take:

1. Route Status. Restricted and Allowed are both considered available from a routing path perspective.

2. Routing cost (ent-rte:rc=)

Currently, once the lowest cost available route is determined, it is always used. This can lead to congestion issues when the least cost Available route has a linkset status of Restricted (too few links available to handle the expected load). A higher cost Available route that is Allowed will receive no traffic, even though it may have more links available than the lowest cost Available route and would be able to handle the load without causing congestion.

The current routing determination algorithm does not use Restricted status when determining the preferred route. Use of the current algorithm is normally not an issue for messages not destined to the EAGLE (e.g., ISUP) but can have detrimental effects on messages destined to the EAGLE's point code (e.g., GTT traffic). The EAGLE can issue TFRs for MTP-routed traffic and expect the upstream nodes to find alternate routes. However, when GTT traffic arrives destined for the EAGLE's point code during a linkset failure, the originating node does not receive a TFR concerning the EAGLE's point code. Therefore, GTT traffic will not be diverted; and when the first link in the failed linkset becomes allowed, the EAGLE will try to route all traffic over the newly available link. Congestion can occur due to the potentially large amounts of GTT traffic. This behavior is shown in the following figure.

Figure 4-4 Example of SCCP Traffic During Linkset Failures

The B-linkset from STP 235-0-8 to STP 235-0-7 and the D-Linkset from STP 235-0-8 to STP 235-0-5 fail. Normally, a TFR would be sent to the MSC/VLR concerning destinations such as HLR 235-1-1. MTP traffic would be diverted from STP 235-0-8 to STP 235-0-6 and STP 235-0-8 would not receive any traffic. As links become available again on the B- or D-linksets, when the threshold is specified by the tfatcabmlq parameter, a TFA/TCA is broadcast to the MSC/VLR and thus allow MTP-routed traffic to flow again through STP 235-0-8.

However, GT-routed traffic to the true point code or CPC of STP 235-0-8 continues to arrive at STP 235-0-8 and be sent over the C-linkset when the B- and D-linksets fail. The failure is caused by an affected destination of the TFx message. The destination tells the receiving node the point code that is allowed, restricted, or prohibited. The affected destination would not be the EAGLE's point code.

When links start to become available on the B-linkset again, GT-routed traffic immediately starts to undergo changeback procedures, and these procedures can congest the newly available links if there are not enough links within the B-linkset to carry the normal traffic load. Again, MTP-routed traffic is still be diverted to the mate STP 235-0-6 by the MSC/VLR until the setting in the tfatcabmlq parameter is met and a TFA/TCA is issued.

The Linkset Restricted Support feature changes the routing path decision process. The routing path decision process chooses a higher-cost Allowed route over a lower-cost Restricted route based on available link count.

The Linkset Restricted Support feature provides an optional alternate routing determination algorithm that is more tolerant during linkset transitions and reduces the likelihood of experiencing congestion on linksets that do not have a sufficient quantity of available links to carry normal traffic loads.

This feature prevents congestion on newly available linksets for GT-routed traffic in addition to MTP-routed traffic.

The route (linkset) that a message takes is determined using one of two factors:

1. Route Status. Restricted and Allowed are both considered available from a routing path perspective.

2. Routing cost (ent-rte:rc=)

Current routing procedures determine and use the least cost available route, regardless of whether the route is Allowed or Restricted. However, congestion can occur if too few Allowed links are available to handle an unexpected spike in the traffic load. While at the same time, a higher cost available route may exist that is Allowed and with more links available to handle the congestion, receives no traffic.

The current routing determination algorithm does not use Restricted status when determining the preferred route. Use of the current algorithm is normally not an issue for messages not destined to the EAGLE 5 SAS (e.g., ISUP) but can have detrimental effects on messages destined to the EAGLE 5 SAS's point code (e.g., GTT traffic). The EAGLE 5 SAS can issue TFRs for MTP-routed traffic and expect the upstream nodes to find alternate routes. However, when GTT traffic arrives destined for the EAGLE 5 SAS's point code during a linkset failure, the originating node does not receive a TFR concerning the EAGLE 5 SAS's point code. Therefore, GTT traffic will not be diverted; and when the first link in the failed linkset becomes allowed, the EAGLE 5 SAS will try to route all traffic over the newly available link. Congestion can occur due to the potentially large amounts of GTT traffic. This behavior is shown in the following figure.

Figure 4-5 Example of SCCP Traffic During Linkset Failures

The B-linkset from STP 235-0-8 to STP 235-0-7 and the D-Linkset from STP 235-0-8 to STP 235-0-5 fail. Normally, a TFR would be sent to the MSC/VLR concerning destinations such as HLR 235-1-1. MTP traffic would be diverted from STP 235-0-8 to STP 235-0-6 and STP 235-0-8 would not receive any traffic. As links become available again on the B- or D-linksets, when the threshold is specified by the tfatcabmlq parameter, a TFA/TCA is broadcast to the MSC/VLR and thus allow MTP-routed traffic to flow again through STP 235-0-8.

However, GT-routed traffic to the true point code or CPC of STP 235-0-8 continues to arrive at STP 235-0-8 and be sent over the C-linkset when the B- and D-linksets failed. STP 235-0-8 knows that HLR 235-1-1 is restricted, but has no method of notifying MSC 2-5-4 to attemp to find an alternate path. Since the destination of the GT-routed traffic is STP 235-0-8, a TFR to MSC 254 concerning HLR 235-1-1 is ignored.

As links become available on the B-linkset again, GT-routed traffic immediately starts to undergo changeback procedures. This can congest the newly available links, if there are not enough, within the B-linkset to carry the normal traffic load. Again, MTP-routed traffic is still being diverted to the mate STP 235-0-6 by the MSC/VLR until the setting in the tfatcabmlq parameter (broadcast minimum link quanity) is met and a TFA/TCA is issued.

The Linkset Restricted Support feature compares a linkset’s available links against its provisioned links to determine if it is capable of carrying its normal load. If all or most links are available, the linkset is considered Allowed. If fewer than a specified number of links are available, the linkset may experience congestion and is considered Restricted.

Based on available link count, the Linkset Restricted Support feature alters the routing path decision process and chooses the higher-cost Allowed route instead of the lower-cost Restricted route.

For Linkset Restriced Support, while the B-Linkset is Restricted, it gets bypassed and GT-routed traffic is sent on the C-Linkset. When enough links become available for the B-Linkset to be Allowed, then B-Linkset will again be used for routing. This helps prevent congestion by ensuring that traffic gets routed on the linkset with the most available capacity.

The concepts and facilities in this section apply to the LNP 96 Million TNs feature, the Increase LNP LRN and Default NPA-NXX Table Capacities feature, and the Mass Update of SPIDs feature. For convenience of discussion, these three features are presented here.

Description

The Local Number Portability (LNP) implementation for the ELAP Application on the MPS platform consists of a Real-Time-Database (RTDB) component, which performs the following tasks.

• Accepts provisional transactional updates from a Local Service Management System (LSMS).

• Processes Auditing requests.

• Processes Bulk re-load request of the entire Database (DB).

• Handles Provisioning & Reload sessions to the PROV task.

• Services UI requests for Data Retrieval.

Ownership of the "golden database" resides on the LSMS, and maintains the integrity of the RTDB. All provisioning occurs on the LSMS. Additionally, the ELAP provides the ability to locally provision LNP data through the ELAP User Interface.

The following figure provides an architectural overview an LNP 48/96 Million System.

Figure 4-6 LNP 48/96 Million System Architectural Overview

Feature Control Mechanism

This feature requires that the LNP feature be on. Previously, the mechanism for identifying this condition was to perform the EAGLE UI command rtrv-feat and to view the LNP component in the "ON" state. This feature employs the Feature Control Mechanism. With feature keys, the verification method for identifying the LNP feature condition is to perform the EAGLE UI command rtrv-ctrl-feat. If the "LNP portedTN" entry is displayed, the LNP feature is considered to be ON.

The feature key mechanism provides some additional security against mistakes and/or fraud, thereby protecting the feature assets. There is a single feature key to indicate the existence of the ELAP device. This feature key behaves similarly to the previous LNP48MIL feature bit.

The LNP ELAP Configuration feature key indicates that the VSCCP applications should look to the TCP/IP connection for the source of the LNP DB. Three additional feature keys (LNP ported TN QTY, LNP ported NPANXXs QTY, and LNP ported LRNs QTY) regulate the maximum capacity allowed within the LNP DB System.

Under the current system, neither the feature bits nor the feature keys are conveyed to the ELAP. The ELAP currently performs no regulation of the capacities within the LNP System, other than the global capacity that it can perform. The LNP 96 Million TNs Feature enforces LNP quantities on the ELAP by way of the feature keys. Loading and maintaining the feature key table on the ELAP via the OAM accomplishes this enforcement. Therefore, the feature keys are to be provisioned solely on the OAM, and the associated keys are to be distributed to the ELAP. Synchronization occurs on the ELAP in a similar manner to that of the EAGLE LIM cards.

Upgrade routines convert feature bits to feature keys by examining the existing feature bits and SCCP hardware to determine the LNP ELAP Configuration feature key and LNP QTY levels.

Object Capacity

The maximum capacity of the objects for persistent storage is increasing; see the following table.

Table 4-8 Maximum Object Capacity

Object	LNP 12 Million	LNP 48 Million	LNP 96 Million
Telephone Number (TN)	12 Million	48 Million	96 Million.
NPANXX	150,000	150,000	300,000
Local Routing Number (LRN)	100,000	100,000	150,000

Measurements Collection

The measurements requirements remain the same as the existing LNP 12 Million and LNP 48 Million architectures, with the exception of the expanded NPANXX and LRN listed in the previous table. Measurement objects are capped at 150,000 NPANXXs and 100,000 LRNs when collection is performed via the OAM. When measurements are being collected by the Measurement Platform, the objects are capped at 300,000 NPANXXs and 150,000 LRNs.

SCCP Application Storage and Provisioning

The new LNP 96 Million TNs architecture utilizes DSM cards ranging from 1 GB to 4 GB of expanded memory. Like the existing LNP systems, the LNP 96 Million TNs feature auto-inhibits any SCCP application card that does not meet the minimum hardware requirements, based upon feature key capacities and the LNP ELAP Configuration feature keys.

Enhancements to ELAP Graphical User Interface

The ELAP Graphic User Interface has been enhanced to support this feature. For more information, see ELAP Administration Manual.

Simplex Mode Menu Option

The new Simplex Mode menu option provides the functionality to view as well as change (i.e toggle) whether or not the ExAP is in simplex mode; see the following figure.

Figure 4-7 Maintenance>Simplex Mode Submenu

View Simplex Mode

This menu selection displays whether or not the ExAP is in simplex mode state. The user requires "View Simplex Mode" action privilege to view this menu selection.

Figure 4-8 View Simplex Mode Screen

Change Simplex Mode

This menu selection toggles simplex mode on the selected ExAP.

Figure 4-9 Change Simplex Mode Screen

The current state of the selected ExAP is determined prior to the output of this screen. If the ExAP is not currently in simplex mode, this screen will enable the user to force it into simplex mode. If the contrary is true, the user will be enabled to remove the simplex mode condition on the selected ExAP. User requires "Change Simplex Mode" action privilege to view this menu selection.

View LNP Qty Features

This new ELAP version-only menu item selection displays the enabled LNP quantity features as provisioned on the EAGLE . The user requires "View LNP Qty Features" action privilege to view this menu selection.

Figure 4-10 View LNP Qty Features Screen

Subscriptions

This menu option allows the user to retrieve a single subscription record using a single 10-digit subscription or an optional 10-digit subscription range as a key. If a single 10 digit subscription is used the exact value is displayed if present, otherwise, a "not found" message is displayed.

If a 10-digit subscription range is used a start value (TN:) and end value (ETN:) must be specified and the first subscription found in the specified range is displayed if present, otherwise, a "not found" message is displayed.

Figure 4-11 Retrieve Subscription Screen

Retrieve

This menu option allows the user to retrieve a single subscription record using a single 10 digit subscription or an optional 10 digit subscription range as a key.

Figure 4-12 Retrieve Subscription Screen

If a single 10-digit subscription is used, the exact value is displayed if present; otherwise, a "not found" message is displayed. If a 10-digit subscription range is used, a start value (TN:) and end value (ETN:) must be specified. The first subscription found in the specified range is displayed, if present; otherwise, a "not found" message is displayed.

Currently, the LNP AIN solution does not preserve the Charge Number and Charge Party Station type in the LNP AIN query and response. Without these parameters, SSP’s cannot set up calls to IC type trunk groups.

With this enhancement, the EAGLE STP’s LNP solution provides the ability to copy Charge Number and Charge Party Station type parameters from the LNP AIN query to the LNP AIN response. This capability is accessed on a per-STP basis via the LNPOPTS.

In Release 24.0, a change was implemented to address a non-conformance to the LNP message relay function. This change involved discarding a message if it was related to a ported TN, with LRN override data provisioned, but not for the specific service. This change has resulted in these customers provisioning default service data into the override tables to continue this type of LNP message relay service portability functionality.

In order to address the needs of these customers while continuing to provide the enhanced solution, in Release 26.0 the EAGLE will allow for either method of operation for LNP message relay on a per STP basis.

Figure 4-14 Example Network

Consider the network depicted in the figure. If customer 212-543-2345 ports from Service Provider B to A, Service Provider A needs to provide CNAM functionality, as it does not provide CNAM service within its network. However, Service Provider B can potentially "resell" CNAM service to Service provider A. The EAGLE LNP subsystem for Service Provider B would require that only the override GTT for the CNAM service be provisioned at the STP. Calls from the customer requiring LIDB service that originate in Service Provider's B network would arrive at Service Provider's B EAGLE Gateway STP.

Since 212-543-2345 is ported out, the override GTT data is first used. If the override data contains only data for CNAM service, the EAGLE formerly used the default data in the NPAC subscription information for LIDB and route the query to Service Provider A's Gateway STP.

This functionality was changed so that individual services would not default to the NPAC subscription data if the override GTT data was provisioned for one service, but was missing for another service. Due to this change, if Service Provider B wanted to route the LIDB query to Service Provider A's gateway STP, Service Provider B would have to provision the NPAC default data into the override table in order not to reject the LIDB query. This could cause unacceptable provisioning requirements for Service Provider B.

Currently, STPLAN functionality does not include LNP responses generated from the EAGLE LNP Database. This is due to the fact that the response is an EAGLE-generated MSU that does not have the STPLAN copy flag set.

With this feature, the LNP Query Service application now supports the copying of LNP response messages to the STP/LAN application. All LNP response messages will have the GWS Action Set ID set to the value of the corresponding LNP query message. This ensures that all LNP query messages that passed gateway screening with the STOP&COPY action set will have their responses copied to STPLAN.

The LNP response messages that are copied to STP/LAN are:

• AIN

• IN

• TCAP Error Response

• Wireless LNP

• PCS 1900

Refer to the Commands Manual for current usage information.

ent-lnp-sub

The ent-lnp-sub command is used to add an LNP 10 digit ported telephone number and its LNP query LRN or message relay global title information to the database.

dlt-lnp-sub

The dlt-lnp-sub command is used to remove an LNP 10 digit ported telephone number message relay service, LRN, or the entire telephone number subscription from the database.

chg-lnp-sub

The chg-lnp-sub command is used to change the attributes of an existing 10 digit telephone number subscription. The chg-lnp-sub command uses these parameters.

rtrv-lnp-sub

The rtrv-lnp-sub command displays all the LNP 10 digit ported TNs and their assigned services in the database.

dlt-lnp-serv

The dlt-lnp-serv command is used to remove an LNP service from the database.

chg-lnp-serv

This chg-lnp-serv command is used to change the attributes of an existing LNP service using the chg-lnp-serv command.

The alw-ss command is used to bring a mated application subsystem back into service. This command uses only one parameter, ssn, the mated application subsystem number. This command can only be executed when the current state of the mated application subsystem is OOS-MT-DSBLD and the subsystem is online. When the subsystem has been successfully placed back into service, the primary maintenance state of the specified mated application subsystem is set to IS-NR (in service normal).

Automatic call gapping controls the rate that location routing number (LRN) queries for a particular telephone number or a portion of a telephone number are received by the EAGLE LNP when a particular threshold is reached. ACG controls are used under two conditions:

1. When a node overload condition is detected and an ACG control is configured for that overload level, the EAGLE LNP sends an ACG component within each LRN query response it processes. The ACG control is invoked for the first 6 or 10 digits of the called party address in all queries sent to the EAGLE LNP to control the rate that queries are processed.

2. If no overload control is sent, the EAGLE LNP sends an ACG for a manually initiated control to control the rate of queries for a particular area code (3 digits), area code and prefix (6 digits), 10 digit telephone number, or part of a 10 digit telephone number (6 to 10 digits) are processed. The database can contain a maximum of 256 manually initiated ACG controls.

3. Refer to the Database Administration Manual - LNP for the current details of this feature.

Refer to the Commands Manual for current usage information.

ent-acg-nog The ent-acg-noc command is used to add an ACG node overload control level to the database.

dlt-acg-noc The dlt-acg-noc command is used to remove an ACG node overload control level from the database. The dlt-acg-noc command uses only one parameter, lvl - the overload levels 1 though 9. The database contains 10 ACG node overload levels, but only nine are configurable.

chg-acg-noc The chg-acg-noc command is used to change the values of an existing ACG node overload control level in the database.

rtrv-acg-noc The rtrv-acg-noc command displays the definitions of the node overload levels in the database. The definition is comprised of the threshold LNP query rates for node overload levels and the values for the ACGs to be sent when at the level. The rtrv-acg-noc command uses one parameter, lvl, to display a specific node overload level.

ent-acg-mic The ent-acg-mic command is used to assign ACG controls to all LNP queries or to specific LNP query services and called party digits. If the EAGLE LNP query service receives a query to which a control applies, then the EAGLE LNP sends an ACG, encoded as configured, with the response.

dlt-acg-mic The dlt-acg-mic command is used to remove an ACG manually initiated control.

chg-acg-mic The chg-acg-mic command is used to change an existing ACG manually initiated controls .

rtrv-acg-mic The rtrv-acg-mic command displays the values of ACG controls assigned to certain queries. The control can apply to all queries or to specific query services and called party digits. A set of controls is selected to be displayed by specifying the type of control(s), the service (serv), and/or the digits (dgts).

This capability allows the call to be completed to a telephone number that has been moved from one switch to another, a ported number. When a call is placed to a ported telephone number, the switch where the number used to reside sends a query to the LNP database to obtain the location routing number (LRN). The LRN gives the location of the new switch that the telephone number resides on. When a response to the query is returned to the old switch, the call is completed using the LRN to route the call to the new switch. To implement this capability, these features are required.

• LRN query processing - services LRN queries in real time and generates the appropriate LRN response. Multiple query types are supported.

• SMS interface - the SMS interface is required for LNP database management from an SMS system.

• ACG control - Automatic call gapping is required for overload control when an excessive number of LRN queries are received for a number.

• Local subsystem management - The LNP query processing application is implemented as a local SCCP subsystem and local subsystem management functions are performed in the EAGLE LNP.

A new action, import, has been added to the action parameter of the chg-db command. The action=import parameter restores selected portions of the current LNP database from a removable cartridge created by the LSMS. If the EAGLE LNP’s database becomes severely out of sync with the LSMS’s LNP database, the chg-db:action=import command can be used to resynchronize the LNP portion of the database with the LSMS.

The removable cartridge containing a copy of the LSMS’s LNP database, formatted in EAGLE database format, is created at the LSMS. The action of the chg-db:action=import command is similar to the action of the chg-db:action=restore:src=remove command, except that only these tables in the LNP portion of the database are replaced.

• servprov.tbl

• lnp_stat.tbl (only a portion of this table is imported)

• lnp_lrn.tbl

• lnp_mr.tbl

• lnp_npa.tbl

• lnp_4dig.tbl

• lnp_dbmm.tbl

After the chg-db:action=import command has completed, this minor alarm is raised for all operational TSMs showing that the TSMs must be reinitialized to use the newly imported LNP data.

 *   5022.0429 *  CARD xxxx SCCP       LNP database is inconsistent

When the chg-db:action=import command has completed successfully, both the active and standby MASPs are reinitialized.

The clr-disk-stats command is a debug command used to clear the disk performance statistics and set all the disk performance statistic fields to 0. This command uses only one parameter, loc - the card location of the MASPs, either 1113 or 1115.

For the LNP application, software loading has been modified to verify the validity of the hardware configuration for both MASP and SCCP cards. The MASP hardware configuration is verified first. Once MASPs configuration is determined to be valid, then the SCCP hardware configuration is verified. The hardware configuration for MASP and SCCP cards is verified only when the LNP feature is turned on. The verification of the hardware includes:

• validity of the main assembly

• verification of applique’s memory size

When the hardware configuration for the MASP is determined to be invalid for the LNP feature, the MASP enters a degraded mode. Degraded mode inhibits some MASP functionality in hopes of preventing more serious system fault conditions.

When the hardware configuration for an SCCP card is determined to be invalid for the LNP application, SCM automatically inhibits loading for that specific SCCP card. A minor alarm is generated indicating that card loading for that SCCP card has failed and has been automatically inhibited (i.e. prevented from reloading again). When card loading has been inhibited, the primary state of the card is set to OOS-MT-DSBLD and the secondary state of the card is set to MEA (Mismatch of Equipment and Attributes).

To activate loading of an SCCP card which has been automatically inhibited, enter the alw-card command. The alw-card command is rejected if the LNP is in degraded mode.

Degraded mode is entered under any of these situations:

• Active and standby MASPs do not have an E586 main assembly and an applique with a minimum of 256 Mbytes of memory.

• Any IS-NR SCCP card does not have an E586 main assembly and an applique with a minimum of 256 Mbytes of memory.

The following actions are taken during degraded mode:

• LNP database commands for configuring LNP data in the database is rejected. Retrieve commands is accepted.

• Loading of SCCP cards is disabled. SCCP cards requesting to be loaded will have loading automatically inhibited. SCCP cards already in service continue to run.

• The LNP subsystem is prevented from going online. (any attempt to execute the alw-map-ss is rejected). The LNP subsystem can be taken offline (the inh-map-ss is accepted).

• The PST/SST of each MASP with an invalid configuration is set to IS-ANR/MEA.

• The rept-stat-sys command output shows that the EAGLE is in degraded mode.

The method to recover from degraded mode is dependent upon the reason degraded mode was entered. The list below defines method(s) to recover from degraded mode for each possible reason the mode can be entered.

• The active and standby OAMs do not have the correct main assembly/applique combination.

  Change the MASP hardware configuration to an E586 main assembly with a minimum of 256 Mbytes of memory on the applique.

• An SCCP card does not have the correct main assembly/applique combination.

  Change the SCCP hardware configuration to an E586 main assembly with a minimum of 256 Mbytes of memory on the applique.

The EAGLE requires that the destination point code contained in the global title translation data in the database has a route assigned to it so the MSU can be routed to the destination point code. The LNP subscription data the EAGLE receives from the LSMS can contain global title translation data with destination point codes that do not have routes assigned to them in the EAGLE database. Normally this type of data would be rejected since the EAGLE does not know how to route to the destination point code. However, since this data is coming from the LSMS for LNP updates, the EAGLE must accept it.

This feature generates a report of LNP subscriptions in the database whose destination point codes have not been assigned to a route. Two types of reports are generated:

• All destination point codes in the LNP database that are not assigned to a route.

• For each telephone number, all destination point codes in the LNP database that are not assigned to a route.

The disp-disk-stats command is a debug command that displays the disk performance statistics. The MASPs maintain disk read/write access times as well as statistics for each table and application showing the number of disk accesses and cache accesses. The application and table statistics that have zero values will not be output if an application ID or table ID is not specified; only non-zero statistics are displayed in the default report.

Refer to the Commands Manual for current usage information.

The EAGLE LNP uses the same platform as the EAGLE STP, but with these changes.

The LNP data is stored on the fixed disk drive on the TDM. The fixed disk is partitioned to store both the LNP data and the STP data to prevent a failure of either database from affecting the other. The LNP data is downloaded from the fixed disk drive to the TSM, an ASM containing 1 Gbyte of memory. The TSM is made up of an E586 main assembly and 4 M256 appliques. Each M256 applique contains 256 Mbytes of memory.

To configure an EAGLE LNP for the LNP feature, these software changes have been made.

• The LNP feature must be turned on with the chg-feat command. No LNP commands can be executed if the LNP feature is not turned on. The LNP feature cannot be turned on if the SCCP memory (ASM or TSM) is not large enough to hold the LNP data.

• If a TSM card is loading data, LNP data cannot be configured until the loading process has completed.

• The LNP database is audited every 24 hours.

The LNP database contains this data.

• Six global title translation services requiring message relay service. This data is received from the LSMS.

• Default global title translation for each ported NPANXX. This data is received from the LSMS.

• A list of ported NPANXX requiring SCCP message relay service at the EAGLE LNP. This data is received from the LSMS.

• An indication for each translation type (applicable for only ported NPANXXs requiring LIDB, CLASS, ISVM, and CNAM message relay service) indicating if SCCP CDPA includes 10 digits. The default is “Yes.” This indicator is used only when the length of the SCCP CDPA is 10 digits, but only 6 digits are included. If the length of the CDPA is 6 digits, this indicator is ignored. This data is received from the LSMS.

• Six digit global title translation for LNP query messages. This data is not required if this global title translation is performed in a preceding STP. The results of the global title translation is an alias point code (or true point code of the EAGLE LNP) and SSN of the LNP query function. The alias point code represents the LNP query function. Using the alias point code instead of true point code allows using same global title translation record in both mated STPs. This global title translation data can be configured from SEAS or EAGLE LNP terminals.

• LNP information for each 10 digit ported telephone number. This data is received from the LSMS.

  • Directory number (DN) or range of directory numbers

  • Location routing number (LRN)

  • Current facilities based service provider ID

  • Service 1 global title translation data through Service 6 global title translation data (DPC/SSN, routing indicator, etc.)

  • Billing Service Provider ID

  • If the global title translation is a final global title translation, then the mated application and related data (loadshare mode, concerned point code list, etc.) corresponding to the global title translation data.

• Parameters required to customize LNP query and response processing. These are configured on each EAGLE LNP.

  • AMAslpID value

  • Indicator to include or exclude AMAslpID parameter in the AIN response

  • Billing indicators (call type and feature ID) for the IN connection control response

  • 3 or 4 digit CIC for IN connection-control response

Parameters for treatment of outgoing global title translation messages. The new translation type and global title address indicator can be configured for each DPC, as long as the DPC is used in an existing non-final global title translation. The global title address indicator shows the outgoing global title address treatment, either the telephone number or LRN.

The EMS is an interface between the EAGLE LNP and the LSMS and converts the LSMS protocol (CMIP) to an asynchronous serial format. Two terminal disk module (TDM) ports (RS-232) running at 19,200 bps connect the EMS to the EAGLE. The EMS is connected to the LSMS using the Q.3 interface. The EMS is mounted in the OAPF frame.

The EMS performs these functions.

• Receiving LNP data and requests from the LSMS and converting the LNP data to EAGLE LNP commands

• Connection management to the LSMS

• Support data audit function between EAGLE LNP and the LSMS

The data downloaded to the EAGLE through the EMS is stored in the fixed disks on the TDMs.

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

• 32 megabytes of RAM

• a 1.02 gigabyte hard drive using a SCSI interface

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

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

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

The EMS uses this software to allow the EAGLE to communicate with the LSMS.

• SUN™ Solaris version 2.4 operating system

• SunLink Solaris version 9 for X.25

• The EMS application software.

The EMS is deployed in pairs at each EAGLE LNP for redundancy.

This capability locates the LNP database using 10 digit global title translation. To implement this capability, these features are required.

• Ported NPANXX detection - the EAGLE LNP maintains a list of all ported NPANXXs for each translation type that the node must perform 10 digit global title translation for. The first pass search shows if the number belongs to a ported NPANXX.

  If the number does not belong to a ported NPANXX, normal global title translation is performed on the number.

  If the number belongs to a ported NPANXX, two options are available for performing LNP global title translation.

  • The EAGLE LNP is not responsible for performing 10 digit LNP global title translation. The EAGLE LNP performs normal global title translation which results in routing the MSU to an external LNP database (for example, an LNP SCP) or another STP.

  • The EAGLE LNP is responsible for performing 10 digit LNP global title translation. This routes the MSU to an internal LNP subsystem for performing 10 digit LNP global title translation.

• Message Relay - This function is required to perform 10 digit LNP global title translation while maintaining backward compatibility with existing non-LNP OSSs. Currently, OSSs (and some switches) use 6 digit global title translation for certain services. To minimize the impact of LNP on these systems, they will continue to route using 6 digit global title translation. If the called party address does not include 10 digits, the 10 digits are extracted from the TCAP portion of the message and are used as a global title address (GTA).

• Prevention of SCCP looping - The complexity of LNP data administration across multiple carrier networks increases the chances of data inconsistencies and may result in SCCP circular looping. The global title translation feature has been enhanced to modify the translation type (TT) and global title address (GTA) as result of translation. The GTA is replaced by the location routing number. This function is optional and can be configured by the user.

• SMS interface - the SMS interface is required for loading LNP global title translation data from an SMS system.

• 10 digit final LNP global title translation - The EAGLE LNP requires that final global title translation is performed on 10 digits. When the STP performs 10 digit final global title translation, it will be capable of supporting routing and management of mated databases. All existing functions (load sharing between databases, primary/backup relationship between databases, remote subsystem management, translation type mapping, translation aliasing, etc.) are performed with the 10 digit final LNP global title translation.

• 6 digit default LNP global title translation - If the 10 digit global title translation does not find a match (for example, when a number is not ported but belongs to a ported NPANXX), the EAGLE LNP performs a 6 digit default global title translation.

The inh-ss command is used to place a mated application subsystem out of service. This command uses two parameters, ssn and force. The ssn parameter specifies the subsystem number of the mated application subsystem to be taken out of service. If the inh-ss command is entered with the force parameter set to yes, the mated application subsystem is forced out of service. When the subsystem has been successfully taken out of service, the primary maintenance state of the specified mated application subsystem is set to OOS-MT-DSBLD (out of service maintenance disabled).

Refer to the Commands Manual for current usage information.

ent-lnp-lrn

The ent-lnp-lrn command is used to add an LNP location routing number (lrn) and its corresponding overriding message relay global title translations (mrgt) to the database.

dlt-lnp-lrn

The dlt-lnp-lrn command is used to remove a location routing number or its corresponding overriding message relay global title translations from the database.

chg-lnp-lrn

The chg-lnp-lrn command is used to change the attributes of an existing LRN and its corresponding overriding message relay global title translations in the database.

rtrv-lnp-lrn

The rtrv-lnp-lrn command displays all the LRNs and their associated final overriding message relay global title translations in the database.

Refer to the Commands Manual for current usage information.

chg-lnp-ttmap

The chg-lnp-ttmap command is used to change globally administered NGT and RGTA indications for each point code and translation type combinations for a group of existing telephone numbers in the database.

rtrv-lnp-ttmap

The rtrv-lnp-ttmap command displays all globally administered NGT and RGTA indications for each point code and translation type combinations for a group of existing telephone numbers in the database.

Message Relay (MR) contains these enhancements to existing global title translation functions.

• Extraction of 10 digit dialed number from the TCAP portion of the message: If the MSU contains a 6 digit called party address, the 10 digit dialed number is extracted from the TCAP portion of the MSU.

• Increased number of translations: For each 10 digit dialed number, up to 6 translations are available. The previous limit was 270,000 total translations. The number of dialed numbers that can be entered depends on the hardware, but the minimum hardware configuration supports 500,000 dialed numbers, so 3 million translations can be entered on the minimum hardware configuration. The maximum hardware configuration supports 2 million dialed numbers, so 12 million message relay translations can be entered on the maximum hardware configuration.

• Replacing the global title address: The global title address in the called party address can be replaced with the LRN associated with the ported dialed number.

Message Relay is performed in three stages:

1. The message arrives at the EAGLE LNP route-on-gt. The EAGLE LNP performs 6 digit (NPANXX) translation. The result of this translation indicates if message relay is required. If it is required, the result of this translation also gives the default data that may be used in stage 3.

2. If the results of stage 1 indicates message relay is required, the EAGLE LNP performs 10 digit message relay. If the 10 digit number is found, the translation data for the 10 digit number is used to route the message.

3. If the 10 digits are not found, the dialed number is not ported, and the default data from stage 1 is used to route the message.

Refer to the Commands Manual for current usage information.

The ent-trace command is a debug command used to trace MSUs sent to SCCP cards.

When the LNP subsystem goes offline, the EAGLE sends SSPs that cause messages with the routing indicator set to SSN to be diverted to the mate subsystem. But these will not cause messages with the routing indicator set to GT to be diverted. In order to make other nodes divert the messages with the routing indicator set to GT to the mate, the EAGLE sends response method TFPs for these messages that require either message relay or LNP query.

There are two reasons the EAGLE generates a response method TFP.

While the LNP subsystem is offline, a message arrives with the routing indicator set to GT for one of EAGLE's capability point codes. The result of the global title translation is the EAGLE's LNP subsystem or that message relay is required on EAGLE.

In both of these cases, the EAGLE generates a TFP concerning the capability point code and sends the TFP to the OPC in the message. This TFP should cause the OPC to divert traffic to the mate. If a message arrives with the routing indicator set to GT for EAGLE's true point code, EAGLE does not generate a TFP. Nodes that send traffic to EAGLE with the routing indicator set to GT should use one of EAGLE's capability point codes, not EAGLE's true point code.

If the EAGLE receives an RSP (Route Set Test Message - Prohibited) for a capability point code that is used for LNP, and the LNP subsystem is offline, the EAGLE does not reply. If the EAGLE receives an RSR (Route Set Test Message - Restricted) for a capability point code for LNP, and the LNP subsystem is offline, the EAGLE replies with a TFP concerning the capability point code. When LNP subsystem is online, the RSRT replies to both RSRs and RSPs for a capability point code that is used for LNP with a TFA.

The LNP commands described in the New Commands section are assigned to three new command classes: LNP Basic, LNP Database Administration, and LNP Subscription. To allow users to execute these commands, three new parameters have been added to the ent-user, chg-user, and chg-secu-trm commands: lnpbas, lnpdb, and lnpsub. To show the values assigned to these parameters, the lnpbas, lnpdb, and lnpsub fields have been added to the rtrv-secu-user, rtrv-user, and rtrv-secu-trm command outputs.

Two new unsolicited output message groups have been added to support the LNP feature: LNP Database Administration and LNP Subscription. To allow these types of messages to be output on a specific terminal, the lnpdb and lnpsub parameters have been added to the chg-trm command. To show the values assigned to these parameter, the LNPDB and LNPSUB fields have been added to the rtrv-trm command output.

Refer to the Commands Manual for current usage information.

ent-lnp-npanxx

The ent-lnp-npanxx command is used to add an LNP NPANXX (area code and office prefix) and its associated default global title translations to the database.

pdlt-lnp-npanxx

The dlt-lnp-npanxx command is used to remove an LNP NPANXX or its associated default global title translations from the database.

chg-lnp-npanxx

The chg-lnp-npanxx command is used to change the attributes of an existing LNP NPANXX and its associated default global title translations in the database.

This is a case where the LNP query is routed as a non-final global title translation MSU. The EAGLE STP first performs the regular 6 digit global title translation. If the result of the global title translation is an internal LNP query application, the LNP query is processed and the response is sent to the originating switch. This example illustrates both normal 6 digit global title translation and LNP query processing are done on the same STP. The originating switch uses a separate capability point code (different from capability point code used for non-LNP global title translation) to route LNP global title translation traffic. The advantage of using a separate capability point code is that Level 3 network management can be performed independently for LNP global title translation traffic and non-LNP traffic, such as 800 global title translation traffic. For example, if the LNP application is manually taken out of service, the STP can divert the LNP traffic to the mate by sending a TFR concerning the LNP capability point code. The EAGLE LNP continues to process 800 global title translation traffic.

Figure 4-18 LNP Query Routed as a Non-Final Global Title Translation

1. Line A (708-224-1111) dials Line B (708-713-2222).

2. The originating switch performs digit analysis on the dialed digits to determine how to route the call. The switch determines that B is in a portable NPANXX (708-713) and the line does not reside on the switch.

3. The switch sends an AIN (Info_Analyzed) or IN (InstructionStart) query based on the dialed digits to the capability point code of the EAGLE STP pair. Different capability point codes are used for LNP and non-LNP global title translation.

4. The EAGLE STP performs global title translation on the query and sends the query to a local LNP subsystem. The local LNP subsystem finds the telephone number in its LNP database and sends an AIN (Analyze_Route) or IN (ControlConnect) response containing the location routing number (LRN) (312 979) of the recipient switch.

5. The originating switch receives the LNP response and analyzes the data. The LRN is translated in the LNP routing tables and an ISUP route out of the switch is determined. The LRN is stored in the called party number parameter and the dialed digits are stored in the generic address parameter of the ISUP IAM message. The FCI translated called number indicator is set to indicate a query has been done (set to “translated number”).

6. The call is routed to the recipient switch based on the LRN.

7. The recipient switch receives and processes the contents of the IAM message. The switch determines that an LRN is received and that it is the switch’s LRN, and the switch replaces the called party number parameter's contents with the dialed digits stored in the generic address parameter. The switch does digit analysis on the dialed digits and finds the subscriber on the switch.

8. The recipient switch completes the call to the subscriber.

The rept-stat-lnp command displays the current status of LNP. This command uses the two parameters, loc and card.

The loc parameter is used to display a detailed status of LNP information for the TSM specified by the card location. This detailed report includes information for each of the global title translation (GTT), LNP message relay (LNPMR), LNP query service (LNPQS) and automatic call gapping (ACG) functions.

The card parameter has only one value, sccp-all. When card=sccp-all parameter is specified, a detailed status of LNP information for all SCCP cards is provided.

When the rept-stat-lnp command is entered with no parameters, a summary of the LNP status of all equipped TSMs is provided. This summary includes global title translation (GTT) and LNP function status for every TSM as well as LNPQS system information. The possible states of the global title translation status are ACTIVE and SWDL (software loading). The possible states of LNP Status are ACTIVE, OFFLINE and SWDL.

Refer to the Commands Manual for current information on this command.

If the local LNP subsystem is unavailable and the mated subsystem is available, EAGLE uses the routing indicator to determine whether to reroute the message.

If the routing indicator of the message is SSN, EAGLE does not reroute the message to the mate. In this case, EAGLE is acting as an end node, and end nodes do not reroute. If the return on error option is set, EAGLE will generate a UDTS, otherwise it discards the message

If the routing indicator of the message is GT, EAGLE reroutes the message to the mated subsystem.

The rtrv-lnp-dbts command displays the LNP database time stamp corresponding to the latest LNP Database update applied by the LSMS.

The time stamp displayed by this command is updated when an LNP database is downloaded from the LSMS with the chg-db:action=import command or when a command updating a 10 digit telephone number subscription is received from the LSMS.

Refer to the Commands Manual for current information on this command.

SCCP Management (SCMG) on the LIM is used when the LIM does not have an SCCP card assigned to it. The following figure shows the message flow for SCMG. If an SCCP message arrives destined for EAGLE, the cluster manager (CM) attempts to send the message to an SCCP card. If the LIM is not assigned to an SCCP card, the cluster manager sends the message to SCMG on the LIM.

Figure 4-19 SCMG on the LIM

SCMG on the LIM first determines if all SCCP cards have failed. It performs the following functions when all SCCP cards are unavailable:

1. Generate response method SSPs if the routing indicator in the message is SSN for a local subsystem, other than SCMG.

2. Notify MTP to generate response method TFPs if the routing indicator of the message is GT and is destined for an EAGLE capability point code that is used for LNP.

3. Generate UDTS messages if the incoming message is a UDT with the return on error option.

If some SCCP cards are available, SCMG does not send SSPs or TFPs. In this case, the SCCP cards are available, but are overloaded. This is a partial failure: some LIMs have been denied service, but other LIMs have SCCP service. SCMG on the LIM still generates UDTS messages if the incoming message is a UDT with the return on error option.

The following table shows what actions the EAGLE takes when SCCP cards are unavailable and a message arrives requiring LNP.

Refer to the Commands Manual for current information on the following commands.

ent-lnp-serv

The ent-lnp-serv command is used to assign an LNP translation type to a unique LNP service.

Refer to the Commands Manual for current information on this command.

Refer to the Commands Manual for current information on the following commands.

ent-lnp-sp

The ent-lnp-sp command is used to assign an LNP service provider to the database. The ent-lnp sp command uses only one parameter, sp—4 alphanumeric characters identifying the service provider.

dlt-lnp-sp

The dlt-lnp-sp command is used to remove an LNP service provider from the database. The dlt-lnp-sp command uses only one parameter, sp—4 alphanumeric characters identifying the service provider.

rtrv-lnp-sp

The rtrv-lnp-sp command displays the LNP service provider information in the database.

Refer to the Commands Manual for current information on the following commands.

By splitting the NPANXX, the user can force 2 different NPANXXs to reference the same last 4 digits of a 10 digit ported telephone number in the database. When either NPANXX is updated, the 10 digit ported telephone numbers in each NPANXX with the same last 4 digits are updated. When the NPANXX is split, all existing NPANXX data for the NPANXX being split is copied to the new NPANXX.

ent-split-npa

The ent-split-npa command is used to add a split NPANXX to the database.

dlt-split-npa

The dlt-split-npa command is used to remove a split NPANXX from the database. The dlt-split-npa command uses only one parameter, npanxx - the split NPANXX, the value in either the NPANXX or NEW NPANXX fields of the rtrv-split-npa command output.

rtrv-split-npa

The rtrv-split-npa command displays all split NPANXXs in the database. Displaying the split NPANXX is done from the perspective of the old NPANXX, the NPANXX which contains default data.

Refer to the Commands Manual for current information on the following commands.

ent-ss-appl

The ent-ss-appl command is used to reserve a subsystem number for the LNP application and place the LNP application either online or offline using the ent-ss-appl command.

dlt-ss-appl

The dlt-ss-appl command is used to remove a subsystem application from the database using the dlt-ss-appl command. The dlt-ss-appl command uses only one parameter, :appl = the subsystem application,. The EAGLE LNP contains only one subsystem application, the LNP subsystem application.

chg-ss-appl

The chg-ss-appl command is used to set an existing subsystem application either online or offline using the chg-ss-appl command.

rtrv-ss-appl

The rtrv-ss-appl command is used to display all of the applications from the database. The command displays the application type, subsystem number, and application status.

Refer to the Commands Manual for current information on the following commands.

chg-lnpopts

The chg-lnpopts command is used to change the LNP specific options.

rtrv-lnpopts

The rtrv-lnpopts command displays the LNP specific system options in the database.

The LOCREQ Query Response feature allows the EAGLE 5 ISS to respond to LOCREQ queries with a LOCREQ response message for both ported and non-ported subscribers.

The LOCREQ Query Response feature populates the RN of the ReturnResult message. Service Portability (S-Port) processing is used to control whether Generic Routing Number (GRN) or default RN digits are used for the RN in the ReturnResult message.

When a user attempts to log in to the EAGLE and enters either an invalid user ID or password, the EAGLE currently responds with the following message.

Error Messages

E2264 Cmd Rej: Password verification failed

Error message E2264 is the same message that is issued when the new and verify passwords entered during a password change do not match.

When this message is issued after a failed login attempt, it implies that only password was invalid, when an invalid user ID was entered with a correct password, or both the user ID and password were invalid.

Now, after a failed login attempt, the EAGLE responds with a new message,

E2757 Cmd Rej: Invalid userID/password combination.

When this message is received, the user should verify both user ID and password.

Error message E2264 is still issued when the new and verify passwords entered during a password change do not match.

When a user has successfully logged on to the EAGLE, a message is displayed followed by 2 lines of login history information. The login history information contains the number of login failures that have occurred since the last time the user successfully logged in to the EAGLE and the date and time of the user’s last successful login and the terminal that the user logged in to the EAGLE on. At each successful login, the login history messages are displayed to the user in the scroll area.

xxxx LOGIN failures since last successful LOGIN
Last successful LOGIN was on port zz on yy-mm-dd @ hh:mm:ss

where:

xxxx—the number of unsuccessful login failures since the last successful login

zz—the number (1 - 16) of the port on which the last successful login occurred.

yy-mm-dd—the date of the last successful login

hh:mm:ss—the time of the last successful login

An unsuccessful login attempt is any use of the login command, while not already logged on, that does not result in the user getting logged on to the EAGLE. Some examples of an unsuccessful login in which the failure count maintained for the user ID is incremented are:

• user ID valid, password invalid

• user ID valid, password valid, user ID is already logged on at some other port.

• user ID valid, password valid, user ID has been suspended

• user ID valid, password valid, a password change is required and the new password is not valid

• user ID valid, password valid, the password is older than allowed by the page parameter of either the ent-user, chg-user, or chg-secu-dflt commands, the new password is not valid.

• user ID valid, password valid, the user ID has been inactive for a period of time that is greater than the value of the uout parameter of either the ent-user, chg-user, or chg-secu-dflt commands.

Login attempts that are rejected while a terminal port is temporarily locked out due to excessive login failures are not counted. While the terminal port is temporarily locked out, the EAGLE immediately rejects all login attempts regardless of the user ID specified on the login command and makes no attempt to verify that the specified user ID.

Whenever communications is lost between the EAGLE and a terminal, the user logged on to that terminal will be automatically logged off. Some examples of communications loss are:

• terminal is powered off

• telephone connection between dial-up terminal and EAGLE is disrupted

• directly-connected terminal is unplugged from the backplane.

When communications between EAGLE and the terminal are re-established, the user must login on the terminal again to access the EAGLE on that terminal.

This does not apply to SEAS terminals. SEAS terminals are considered to be connected to the EAGLE by secure lines and the login command cannot be entered on that terminal.

When a user is logged off of a terminal because of a communications loss, the following message is displayed to all terminals that are able to receive unsolicited system administration messages in addition to the affected terminal.

User xxxxxxxx auto logged out (communications failure) on port yy.

Where:

xxxxxxxx = the user ID that was logged off

yy = the affected terminal port (1 - 16)

If a user is logged off a terminal when the system is in the middle of processing a command that gathers passwords (for example, the chg-pid, chg-user, or ent-user commands), any prompt that is being displayed is removed and the character echo (which was disabled so that the password could be entered) is re-enabled. If the communications loss occurs while the system is in the middle of processing other types of commands (such as a database backup or restore), the user is logged off the terminal, but the command will continue to be executed until it has completed.

If the communications loss occurs while displaying the password prompt while the login command is being executed, the command is not interrupted since while the login command is in progress, the user is not yet logged in.

If the keyboard is locked when the communications loss occurs, the user is logged off and the keyboard is unlocked.

If a communication failure occurs while a file transfer is in progress, the user is logged off the terminal, but the file transfer continues. The communications failure may or may not affect the successful transfer of the file.

This feature increases the size of the LRN table within EAGLE from 30000 LRN entries to 100000 LRN entries. It provides the user the ability to administer up to 100,000 LRN entries at the EAGLE STP. This number was selected because there are possibly 25,000 end offices, with two LRNs per office (2X maximum capacity).

The enlarged number of LRN entries applies to the OAM and SCCPs GPLs.

The MTP Level 2 Peer to Peer Adaptation Layer (M2PA) is a protocol used between the SCTP and the MTP Level 3 that enables SS7 links to run over IP.

M2PA provides a mechanism to transport SS7 MTP2 user signaling (e.g., MTP3 messages) over IP using SCTP. M2PA enables seamless operation between MTP2 user peers in the SS7 and IP space.

The M2PA RFC Support feature adds functionality to support the M2PA RFC implementation while continuing to support earlier (Draft 6) implementations.

To aid the transition from Draft 6 to RFC, the following changes are implemented:

1. 20 new M2PA timer sets are created for M2PA RFC associations.

2. Existing associations are changed to have ver=d6 during upgrade.

3. M2PA Draft 6 timer set values were not changed during upgrade (T16 changed from ms to s, hence table values are multiplied by 1000).

4. M2PA Draft 6 associations use the d6 timers.

5. M2PA RFC adapters use the rfc timers.

   Note:

   It is not necessary to change the m2patset value on the association to retrieve the new timer values.

6. The chg-m2pa-tset command defaults to the rfc values.

7. To change the MP2A Draft 6 timers, a new ver=d6 parameter is specified.

This feature allows GTT Action Services to work together with the RTDB Split Feature (120M DN and 120M IMSIs via split database). The SCCP card selection on LIM cards is done on the basis of the Opcodes from the MAP layer. If the Opcode is not supported, selection is then done on the basis of the SNP parameter. For the GTT Actions table, the dependency to activate "EPAP Data Split" and GFLEX MLR is removed and the user can use the functionality of both features together. This compatibility occurs when GTT Action is executed on GTT enabled LIM cards (in cooperation with the Add GTT on SLIC IPSG (6500 TPS) enhancement).

The Services in GTT Action can also be configured if the 240 Million SPLIT DB feature is enabled, and vice versa.

In Release 21.0, the EAGLE maintains the date and time that each user ID last successfully logged on to the EAGLE. During the login process, the system computes how many days have elapsed since the last successful login. If the number of elapsed days exceeds the value of the uout parameter, used with either the ent-user, chg-user, or chg-secu-dflt commands, access to the EAGLE is denied, and the following message is displayed to the user.

Error Message

E2752 Cmd Rej: UserID has become obsolete and cannot be used

This test for inactivity is performed after the user ID and password combination has been validated, and before any of the password aging tests.

The rstlsl=yes parameter with the chg-user command resets the last successful login date associated with the user to the current date. This allows that user to login to the system.

When a user ID is initially created, the last successful login date and time that is entered in the database is set to the date and time that the user ID was created. If a user ID is created and never used, it becomes obsolete when the number of days the user ID was inactive, measured from the creation date, is greater than the value of the uout parameter. At that time, the system does not allow a login session to be established with that user ID.

This feature does not apply to all user IDs assigned to the Security Administration command class. If the EAGLE detects that all user IDs have been inactive longer than value of the uout parameter (for example, the system administrator mis-typed the date 10 years in the past with the set-date command resulting in all user IDs appearing obsolete to the system), no one would have access to the EAGLE and the EAGLE would be un-administrable. Since the EAGLE requires at least one user ID to be assigned to the Security Administration command class, by having this feature not apply to any user IDs assigned to the Security Administration command class ensures that at least one user will always have access to the EAGLE.

This feature makes the EPAP GUI Banner independent of Java. The Java Applet plugin is no longer needed to launch the EPAP GUI Banner. See "EPAP GUI Main Screen" in Administration Guide for me details on the updated EPAP Banner Components.

When a destination for a route becomes restricted or prohibited, the EAGLE starts sending signaling route set test (SRST) messages for that destination. This feature allows a user to manually stop sending signaling route set test messages for a specific destination on a specific route using the dact-rstst command. The destination of the route must be either the DPC of the route, a cluster point code of a route, or an entry on the cluster routing exception list. The route’s status is changed to allowed.

If the SRST messages for a particular destination have been manually deactivated and that destination becomes restricted or prohibited again, the dact-rstst command must be issued again to manually stop sending the SRST messages for that destination.

These new measurements are being added to the EAGLE.

• The GTWY measurement report type.

• The RBASE measurement report type.

• These measurements in the daily reports (MTCD and MTCDTH): OCTRETRN, TLNKACTV and MSURCERR.

• The MTCH measurement report type for the LNP entity. This report contains measurements that apply to the LNP feature. The details of this report are discussed in the LNP Feature Notice.

The GTWY measurement report collects and reports gateway-related data from the STP. The gateway related data collected for this report is the network management and global title translation load on the EAGLE, and the source of this load. The level and source of pass through TCAP traffic is also collected. In previous releases, the MTP cards in the EAGLE did not measure the data required to be reported for the GTWY measurement report. In release 22.0, the MTP cards measure this data which is reported when requested. The MTP cards are polled every 30 minutes for the gateway-related data. The gateway-related data is retained by the EAGLE for 24 hours.

The addition of the GTWY measurements increases the amount of measurements data collected and reported. To make sure that no measurements data is lost when the data is printed on a printer, Release 22.0 requires that the minimum baud rate of the printer is 9600 bps and that the printer must be able to print at a minimum at 1200 characters per second.

The RBASE measurement report reports various data related to the configuration or status of the EAGLE’s major configurable components. The data that appears in this report could be obtained in an existing system by issuing a variety of rtrv-xxxx and rept-stat-xxxx commands. In release 22.0, this information can be obtained by entering a single command and can be displayed in a single report. The data in this measurement report is obtained from either the database or from maintenance tasks performed on the EAGLE. The data is not periodically collected and stored in same the manner of other measurements data, but it is collected on demand when a RBASE measurement report is requested.

The Measurements Platform Filename with CLLI feature allows Measurement Platform processors on several EAGLEs to send their measurements reports to a single directory on a centralized FTP server without duplicate file name problems or overwritten files caused by multiple EAGLEs writing to the directory.

The Measurements Platform Filename with CLLI function is controlled. Feature ON/OFF status is controlled by a measurements option. when the option is turned ON, the unique CLLI field for each EAGLE is prepended to the beginning of the measurements report file name.

The only other major impact of this feature on the filenames generated to the FTP server is that when the option is ON the year is not included as a part of the name.

Message Flow Control (MFC) provides a framework to control the flow of data between cards based on the capacity of the services provided by the cards. The MFC framework can be used to replace the Group Ticket Voucher (TVG) framework.

When a server card determines that the capacity for a service is reached, the service is considered to be 'in flow control'. The server card broadcasts a message to all cards indicating that the service is not available for the remainder of a configured time slice and specifies the interval that defines the remainder of the time slice. When the time slice expires, the service is automatically marked available again on all client cards, and the server card is considered to be 'out of flow control'.

MFC supports two service types:

• Card Services are provided by a card, and the capacity stated by that card service only affects the usage of that card. If the capacity of a card service is exhausted, only that service on that card is affected. The client card can obtain the service from another card. A card service is used for features with an ‘N+1’ configuration.
• System Services are provided by the system as a whole. Several cards can provide the same system service, and each card can have a different rated capacity. A service request that is sent to a system service is sent to all cards that provide the service. If the capacity of the system service is exhausted on one card, the service for the whole system group is in flow control. A system service is used when the available pool of resources must be limited by the weakest link (the card with the lowest rated capacity).

When an application that is using the MFC framework needs to use a service, the application looks through a list of cards or services and makes a service request. For card services, if the desired card is in flow control, the application selects a different card and uses MFC to qualify its flow control status. For system services, if any card providing a system service is in flow control, the application has to wait until the system service is out of flow control.

Message Flow Control (MFC) can be used to control EROUTE traffic from the MTP/OAM application to the EROUTE application. If MFC is off, then TVG is used for flow control (for cards that support TVG).

See Message Flow Control Replacement for TVG (Release 44.0) for additional information about MFC, including Feature Control and Hardware Requirements.

Message Flow Control (MFC) can be used to control the flow for INM and SNM MSUs and MTP layer 3 routing. If MFC is off, then TVG is used for flow control for INM and SNM (for cards that support TVG), and for the linkset rerouting that is used in MTP Layer 3 routing.

See Message Flow Control Replacement for TVG (Release 44.0) for additional information about MFC, including Feature Control and Hardware Requirements.

Message Flow Control (MFC) can be used to control the flow of SCCP traffic between LIM cards and Service Module cards. If MFC is off, then TVG is used for flow control (for cards that support TVG).

See Message Flow Control Replacement for TVG (Release 44.0) for additional information about MFC, including Feature Control and Hardware Requirements.

Message Flow Control (MFC) can be used to control STP LAN service requests. If MFC is off, then TVG is used for flow control (for cards that support TVG).

See Message Flow Control Replacement for TVG (Release 44.0) for information on MFC, including Feature Control and Hardware Requirements.

Refer to the Commands Manual for current command usage information.

Activate Echo to a Terminal

Customers want the ability to echo a terminal to another terminal(s), in addition to a printer. This capability will allow customers to monitor terminal command input and output from another terminal. This will also allow Tekelec’s Technical Services group to monitor customer terminal activity while dialed in on a customer's switch.

Also, during upgrades, this feature will allow Technical services to monitor what the customer is entering into the terminal, step-by-step.

Note that unsolicited output (alarm and network messages) still require the chg-trm command to be sent to the screen.

The terminal receiving the echo must be logged on.

Figure 4-21 Echoing Remote Terminal Input/Output

Customers desire multiple enhancements to the administration functionality for the OAM. The following sections describe the enhancements implemented for Release 26.1.

**     Alarm Summary: Card database is inconsistent   (xxx of yyy shown)
**      --------------------------------------------------------------------------
**      card 1101,  card 1201,  card 1202,  card 1203,  card 3113,  card 
1314,   
**      card 4101,  card 4102,  card 4103,  card 4104,  card 4105,  card 
4106,

Ent-/Chg-GTT Failure Message Should Show Overlap (PR28909)

When customers enter or modify GTT's, they are able to do so for a range of Global Title Addresses. If GTT entries already exist within that range, the command is rejected and displayed in the scroll area. Customers want the ability to see the actual condition that caused the command to fail, instead of having to execute a rtrv-gtt or rtrv-gta command on that range.

This enhancement affects the ent-gtt/-gta, chg-gtt/-gta, and dlt-gtt/-gta commands.

For ent-gtt, the scroll area message shows the first instance of an overlap for an entry/range.

For chg-gtt, the scroll area message shows the first instance of the two existing entries/ranges that the user attempted to change.

Examples: VGTT feature is off:

The command ent-gtt:gta=3037073333 would display an E2401 message, and the scroll area message would be displayed, since there is an overlapping range.

The command chg-gtt:gta=3037072000:egta=3037074000 would display an E2401 message, and the scroll area message would be displayed, since the change covers two entries. (See the examples below.)

chg-gtt

This example shows what happens when the database contains point codes within the range of 800555000 to 800555999, and the user attempts to change a point code that overlaps that range. In this situation. error message E2401 is generated:

Error Message

E2401 Cmd Rej: GTA range overlaps a current range

Output Example

Enter UI command or 'exit':
chg-gtt:type=2:gta=8005550000:egta=8005555999:pc=5-5-2
chg-gtt:type=2:gta=8005550000:egta=8005555999:pc=5-5-2
Command entered at terminal #4.
    The following GTA ranges overlap the input GTA range
    START GTA             END GTA
    8005550000            8005551999
    8005552000            8005553999
    8005554000            8005555999
E2401 Cmd Rej: GTA range overlaps a current range

        CHG-GTT: MASP A - Command Aborted

dlt-gtt

This example shows what happens when the database contains point codes within the range of 800555000 to 800555999, and the user attempts to change a point code that overlaps that range. In this situation. error message E2401 is generated:

E2401 Cmd Rej: GTA range overlaps a current range

Output Example

Enter UI command or 'exit':
dlt-gtt:type=2:gta=8005550020:egta=8005555900
dlt-gtt:type=2:gta=8005550020:egta=8005555900
Command entered at terminal #4.
    The following GTA ranges overlap the input GTA range
    START GTA             END GTA
    8005550000            8005551999
    8005552000            8005553999
    8005554000            8005555999
E2401 Cmd Rej: GTA range overlaps a current range

        DLT-GTT: MASP A - Command Aborted

The MO-Based GSM SMS NP feature provides network information to the short message service center (SMSC) for subscribers using the GSM network. This information allows the SMSC to select a protocol to deliver SMS messages to the called party.

The MO-Based GSM SMS NP feature:

• Intercepts SMS messages after they have undergone Prepaid SMS (PPSMS) and Portability Check for Mobile Originated SMS (MNPSMS) processing and before they reach the SMSC.

  Note:

  The MO-Based GSM SMS NP feature does not require the PPSMS or MNPSMS features to be enabled.
• Decodes the TCAP/MAP message destination address and performs lookup in the number portability (NP) database
• Modifies the destination address in the TCAP message with directory number (DN) porting information, and
• Relays the message to the SMSC

The SMSC uses the DN porting information to determine whether to forward the message to other operators or to process the message for an in-network subscriber.

The MO-Based GSM SMS NP feature applies to ForwardSM SMS MSUs with ITU TCAP/MAP for either ITU or ANSI MTP messages.

The MO-based IS41 SMS NP feature provides network information to the Short Message Service Center (SMSC) for subscribers using the IS41 network. This information allows the SMSC to select a protocol to deliver Short Message Service Delivery Point-to-Point (SMDPP) messages to the called party.

The MO-Based IS41 SMS NP feature:

• Intercepts SMDPP messages after they have undergone Prepaid SMS (PPSMS) and Portability Check for Mobile-Originated SMS (MNPSMS) processing and before they reach the SMSC.

  Note:

  The MO-Based IS41 SMS NP feature does not require the PPSMS or MNPSMS features to be enabled.
• Decodes the TCAP/MAP message destination address and performs lookup in the number portability (NP) database
• Modifies the destination address in the TCAP message with Directory Number (DN) porting information, and
• Relays the message to the SMSC

The SMSC uses the DN porting information to determine whether to forward the message to other operators or to process the message for an in-network subscriber.

The MO-Based IS41 SMS NP feature applies to ANSI TCAP/MAP and ANSI transport (MTP and SCCP) messages.

The MO SMS B-Party Routing feature allows global translation type (GTT) routing to be performed on IS41 MO SMDPP and GSM MO_FSM messages based on the SMS B-party digits from the MAP layer of the message.

If the B number is a short code, then a short message service (SMS) can be directed to a specific short message service center (SMSC) based on the short code dialed by the SMS sender. If the B number is the MSISDN/MDN of the SMS recipient, then the SMS can be directed to a specific SMSC based on subscriber groupings or types.

The MO SMS Migration Enhancements feature includes the addition of a new MO SMS IS41-to-GSM Migration feature and enhancements to existing MO SMS features. The addition and enhancements are discussed below.

The MO SMS NPP feature applies comprehensive Numbering Plan Processor (NPP) number conditioning and service logic execution to the following existing features:

• MO SMS B-Party Routing
• MO SMS IS41-to-GSM Migration
• MO SMS Prepaid Intercept on B-Party
• MO-based GSM SMS NP
• MO-based IS41 SMS NP
• Portability Check for MO SMS
• Prepaid SMS Intercept Phase 1 (PPSMS)

The MO SMS NPP feature causes execution of all of the above features to be controlled by NPP, whether the feature is turned on or off.

This feature also adds new MO SMS ASD and MO SMS GRN features, which are used to support Additional Subscriber Data and Generic Routing Number information, respectively.

The MO SMS NPP feature supports GMS and IS41 protocols and IS41 SMDPP and GSM Forward SM Mobile Originated messages.

The MO SMS Prepaid Intercept on B-Party feature allows the existing Prepaid Intercept Phase 1 feature to redirect MO SMS messages based on whether the B-Party of the subscriber is prepaid. This enhancement allows MO SMS messages for prepaid subscribers to be redirected to a different short message service center (SMSC) than postpaid subscribers.

This feature also allows the Prepaid Intercept Phase 1 feature to support ANSI MTP/SCCP messages.

Service Portability support for the MO-based SMS features determines whether Service Portability processing applies to SMDPP or MO-FSM messages for own-network subscribers. This support applies to the MO-based IS41 SMS NP and MO-based GSM SMS NP features. When Service Portability is applied, the GRN is used to prefix the Destination address in outgoing messages.

The CDPNNP NPP Service Action verifies that RTDB lookup using the conditioned digits is successful based on the GSM or IS41 MOSMSTYPE configuration option value. Service Portability processing can populate the NPP RN Formatting Action value with the GRN digits provisioned for the dialed number (DN), populate the SP Formatting Action value with RN/SP entity digits, and populate the SRFIMSI Formatting Action value with SRFIMSI digits from the RN/SP entity. The populated values depend on RTDB lookup and configuration option values.

The Move GLS to EPM feature moves the existing Gateway Screening Binder/Generic Loading Services software to an EPM-based hardware module. This feature introduces a new E5-TSM card (870-2943-03), which is used to download the Gateway Screening database to all cards running the ss7 or sccp applications. This card can be hot-swapped with the TSM-256 cards and does not support network traffic.

The E5-TSM card is provisioned using the ent-card:type=tsm:appl=gls command. The card supports the new glshc GPL.

In some networks, the SRI-ack response returned by G-Port includes the Routing Number (RN) associated with a ported out number prefixed to the International MSISDN in the MAP MSRN parameter. Depending on the number of digits in the MSISDN and the RN, this prefixing could result in the MSRN parameter exceeding 15 digits. This can cause problems with certain MSCs. Therefore, a new option for G-Port allows a certain specified number of digits to be deleted from the beginning of the National MSISDN (MSISDN without Country Code) prior to formulating the MSRN parameter of the SRI-ack response. (This feature does not affect the encoding of any other parameters or any other messages processed by G-Port.)

A new option for G-Port allows a specified number of digits to be deleted from the beginning of the National MSISDN (MSISDN without Country Code) prior to formulating the MSRN parameter of the SRI-ack response.

The MT-Based GSM MMS NP feature allows the EAGLE 5 ISS to intercept non-call related messages and reply with routing information for out-of-network destination subscribers using the following process:

1. An SRI_SM message is intercepted from the MMSC before the message reaches the home location register (HLR).
2. The message destination address (SCCP Called Party GTA), is extracted, the digits are conditioned, and lookup is performed in the NP database.
3. If the destination address/subscribers belongs to a foreign network, then a reply message is sent to the MMSC with routing information. If the destination address/subscribers belongs to a local network, then the SRI_SM message is relayed to the HLR.

The feature provides the following configurable options for controlling processing of SRI_SM messages and the content of the response:

• Selecting the MMSC response message type and digit format
• Specifying when an NP database lookup is considered to be successful
• Specifying the format of digits encoded in the response message.

The Mobile Terminated (MT)-Based GSM SMS NP feature allows number portability (NP) database lookup to be performed on SRI_SM messages. These messages are normally generated from the short message service center (SMSC) to determine the destination for a short message service (SMS) message.

The MT-Based GSM SMS NP feature allows the EAGLE 5 ISS to intercept non-call related messages and reply with routing information for out-of-network destination subscribers using the following process:

1. An SRI_SM message is intercepted from the SMSC before the message reaches the home location register (HLR).
2. The message destination address (SCCP Called Party GTA), is extracted, the digits are conditioned, and lookup is performed in the NP database.
3. If the destination address/subscribers belongs to a foreign network, then a reply message is sent to the SMSC with routing information. If the destination address/subscribers belongs to a local network, then the SRI_SM message is relayed to the HLR.

The feature provides configurable options for controlling processing of SRI_SM messages and the content of the response:

• Selecting the SMSC response message type and digit format
• Specifying when an NP database lookup is considered to be successful
• Specifying the format of digits encoded in the response message.

The Mobile Terminated (MT)-Based IS41 SMS NP feature enhances the A-Port feature to allow wireless operators to route short message service (SMS) messages within a number portability (NP) environment. If the MT-Based IS41 SMS NP feature is not enabled and turned on, then messages are processed by the A-Port feature.

This feature provides the following configurable options for controlling processing of SMS routing request messages and the content of the response:

• Selecting the short message service center (SMSC) response message type and digit format
• Specifying when an NP database lookup is considered to be successful
• Specifying the format of digits encoded in the response message.

The MT-Based IS41 SMS NP feature acts as follows:

1. Intercepts an SMSREQ message from the SMSC before the message reaches the home location register (HLR).
2. Extracts the message destination address (SCCP Called Party GTA), conditions the digits, and performs lookup in the NP database.
3. If the destination address/subscribers belongs to a foreign network, then a reply message is sent to the SMSC with routing information. If the destination address/subscribers belongs to a local network, then the SMSREQ message is relayed to the HLR.

The following table shows the MRNs that have been added to Release 21.0.

The following table shows the MRNs that have been changed from Release 20.0 to Release 21.0.

The EAGLE automatically tests for circular routing when congestion occurs on an ANSI signaling link. If the routing data were provisioned incorrectly, or were corrupted, MSUs could be routed in an endless circular route. The incorrect routing data could be on the EAGLE or at a remote STP. With the addition of cluster routing and E links, the danger of circular routing is greater.

The EAGLE starts the test when a signaling link reaches onset congestion threshold 1. The EAGLE only runs the test for one signaling link per linkset. If a second signaling link in the same linkset goes into congestion, the EAGLE does not start a new test. Each time the signaling link’s congestion level increases, the test is restarted. The link interface module (LIM) that terminates to the congested signaling link determines which DPCs have the most MSUs transmitted on the signaling link. The LIM then transmits a circular routing test message to the DPCs that have been sent the most MSUs. The circular route test message can be sent to a maximum of 10 DPCs. This value is configured by the chg-stpopts command with the mtpltctdpcq parameter. A circular routing test message is a routeset congestion test message with priority of 3.

If any LIM receives one of the test messages before the circular route test timer expires, the EAGLE performs the following actions.

• Marks the destination as prohibited due to circular routing.

• Broadcasts TFPs for the destination.

• Reports that circular routing was detected for the destination.

• Raises a critical alarm.

The circular route test timer can be configured by the user using the chg-stpopts command with the mtpltst parameter. The mtpltst parameter value is between 10 and 20 seconds, with 10 seconds being the default value. The DPC remains prohibited until it is manually allowed using the rst-dstn (reset destination) command.

If the destination is a cluster point code entry in the routing table, then an exception list (x-list) entry is created for the destination. If the cluster has the exception list exclusion indicator set to yes (meaning do not create x-lists for that cluster), then an x-list is not created, UAM 319 is generated, and a critical alarm is raised for the cluster. The critical alarm can be cleared by entering the rst-dstn command for the cluster. The following is an example of UAM 319.

UAMs

    RLGHNCXA03W 96-04-16 16:28:08 EST Rel 21.0.0
*C  0101.0319 *C DPC 011-210-*         REPT-MTPLP-DET: Circ rte det(cong)
                 XMIT LSN=ls01   RC=10
                 RCV LSN=ls14
                 MEMBER=011-210-007

If the number of entries in the x-list has exceeded the maximum allowed for the x-list and circular routing is detected, then additional entries to the x-list are not added. In addition to UAM 319 being generated, UAM 321 is also generated. The following is an example of UAM 321.

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

When a point code is prohibited due to circular routing, the EAGLE ignores TFx/TCx management messages for that point code. The EAGLE does not send routeset test messages for the point code. The EAGLE discards any MSUs received for the point code and sends response method TFPs or TCPs.

When EAGLE detects circular routing for a destination, it sets the circular routing flag for the destination in the routing table. The rst-dstn command clears this flag. Once the circular routing flag is cleared, the status of the destination depends on what type of entry is used.

• If the destination is a member of a cluster for which EAGLE performs full point code routing only, all routes to the destination are marked as allowed and the destination’s status is allowed. The EAGLE broadcasts TFAs for the destination.

• If the destination has a full point code entry in the routing table, and there is also an entry for the point code’s cluster, then each route used by the point code that is also used by the cluster entry assumes the status of the route for the cluster entry. The EAGLE then determines the point codes route set status and broadcasts TFA/TFR if the point code becomes allowed or restricted.

If the rst-dstn command is entered for an x-list entry with the circular routing flag set, the x-list entry is deleted. The point code’s status becomes the same as the cluster entry’s status.

The circular route detection test feature can be turned on or off with the mtplti parameter of the chg-stpopts command.