3 SS7 Configuration
Chapter 3, SS7 Configuration, describes the procedures necessary to configure the EAGLE 5 ISS to support the SS7 network.
Introduction
This chapter contains the procedures necessary to configure the EAGLE to support the SS7 network. These items are configured to support the SS7 network.
- Linksets, including linksets for these features:
- MTP restart
- 5-Bit to 8-Bit SLS conversion
- ITUSLS enhancement
- Configuring the option for determining how the EAGLE routes messages over restricted linksets and routes - the restricted linkset option.
- Configuring the options for determining how the EAGLE handles TFC messages from ITU-I and ITU-N networks.
- Signaling links
- Routes
- Level 2 timers
- Level 3 timers
- Signaling link test messages
- The rate that TFA and TFP messages are sent
- Circular route detection
- The frequency that signaling-route-set-test (RST) messages are sent for lower priority routes
- Remote loopback points for the link fault sectionalization feature
- Options for the TDM Global Timing Interface
- Changing the high-capacity card temperature alarm thresholds.
Enabling the Large System # Links Controlled Feature
This procedure is used to enable the Large System # Links controlled feature using the feature’s part number and a feature access key.
The feature access key for the Large System # Links controlled feature is based on the feature’s part number and the serial number of the EAGLE, making the feature access key site-specific.
This feature allows the EAGLE to contain a maximum of either 1500, 2000, or 2800 signaling links.
The enable-ctrl-feat command enables the controlled feature by inputting the controlled feature’s access key and the controlled feature’s part number with these parameters:
:fak – The feature access key provided by Oracle. The feature access key contains 13 alphanumeric characters and is not case sensitive.
:partnum – The Oracle-issued part number associated with the signaling link quantity being enabled:
- 893005901 for the 1500 signaling link quantity
- 893005910 for the 2000 signaling link quantity.
- 893005911 for the 2800 signaling link quantity.
The enable-ctrl-feat command requires that the database contain a valid serial number for the EAGLE, and that this serial number is locked. This can be verified with the rtrv-serial-num command. The EAGLE is shipped with a serial number in the database, but the serial number is not locked. The serial number can be changed, if necessary, and locked once the EAGLE is on-site, by using the ent-serial-num command. The ent-serial-num command uses these parameters.
:serial – The serial number assigned to the EAGLE. The serial number is not case sensitive.
:lock – Specifies whether or not the serial number is locked. This parameter has only one value, yes, which locks the serial number. Once the serial number is locked, it cannot be changed.
Note:
To enter and lock the EAGLE’s serial number, theent-serial-num command must be entered twice, once to add the correct serial number to the database with the serial parameter, then again with the serial and the lock=yes parameters to lock the serial number. You should verify that the serial number in the database is correct before locking the serial number. The serial number can be found on a label affixed to the control shelf (shelf 1100).
This feature cannot be temporarily enabled (with the temporary feature access key).
Once this feature is enabled with the enable-ctrl-feat command, the feature is also activated. The chg-ctrl-feat command is not necessary to activate the feature.
This feature cannot be turned off with the chg-ctrl-feat command and the status=off parameter.
Hardware Supported for Signaling Link Quantities Greater than 2000
This hardware is the only hardware that is supported for an EAGLE containing 2001 to 2800 signaling links.
- HC-MIM
- E5-E1/T1
- E5-ATM
- E5-SM4G
- E5-ENET
- E5-based control cards
- E5-STC card for the EAGLE 5 Integrated Monitoring Support feature
To increase the signaling link quantity to more than 2000 signaling links, HIPR2 cards must be installed into card locations 9 and 10 in each shelf in the EAGLE. Enter the rept-stat-gpl:gpl=hipr2 command to verify whether or not HIPR2 cards are installed in the EAGLE shelves.
Adding an SS7 Linkset
This procedure is used to add SS7 linksets to the EAGLE using the ent-ls command and the following parameters shown in Table 3-1.
Table 3-1 Linkset Parameters
| lsn |
apc/apca/apci/ apcn/apcn24 |
ppc/ppca/ppci/ ppcn/ppcn24 |
spc/spca/spci/ spcn/spcn24 |
apcntype |
| lst | clli | sltset | l3tset | scrn |
| gwsa | gwsm | gwsd | bei | nis |
| itutfr | mtprse | slsci | asl8 | slsrsb |
| slsocbit | multgc | gttmode | randsls | cgttmode |
|
islsrsb |
ent-ls command contains other optional parameters that are not used this procedure. These parameters are discussed in more detail in Commands User's Guide or in these sections.
- The "Configuring a Linkset for the GSM MAP Screening Feature" procedure in Database Administration - Features User's Guide.
- These procedures in Database Administration - IP7 User's Guide.
- Configuring an IPGWx Linkset
- Adding a Mate IPGWx Linkset to another IPGWx Linkset
- Adding an IPSG M3UA Linkset
- Adding an IPSG M2PA Linkset
:lsn – The name of the linkset. The linkset name can contain up to 10 characters, with the first character being a letter. However, the SEAS interface supports only eight characters. If this linkset is displayed on the SEAS interface and the linkset name contains more than eight characters, only the first eight characters in the linkset name are shown. If this linkset name contains more than eight characters, and is specified with the linkset commands on the SEAS interface, only the first eight characters can be specified.
:apc/apca/apci/apcn/apcn24 – Adjacent point code – the point code identifying the node that is next to the EAGLE. The adjacent point code can be one of the following types of point codes:
:ppc/ppca/ppci/ppcn/ppcn24 – Proxy point code used for proxy linksets. Proxy point codes can be used only if a quantity of proxy point codes (shown in the rtrv-ctrl-feat output) is enabled. The proxy point code can be one of the following types of point codes:
:spc/spca/spci/spcn/spcn24 – Secondary point code used for multiple linksets that have the same APC. Secondary point codes can be used only if the Multiple Linksets to Single Adjacent PC feature is enabled and turned on (shown in the rtrv-ctrl-feat output. The secondary point code can be one of the following types of point codes:
Note:
Refer to Point Code Formats for a definition of the point code types that are used on the EAGLE and for a definition of the different formats that can be used for ITU national point codes. Private point codes can be assigned only to IPGWx linksets. The procedures for configuring IPGWx linksets are in Database Administration - IP7 User's Guide.:apcntype – Specifies whether or not the linkset containing either a 14-bit ITU-N adjacent point code or a 24-bit ITU-N adjacent point code is being used in China (apcntype=itunchina) or in countries other than China (apcntype=itun). Signaling links in linksets with the apcntype=itunchina parameter are handled according to the specifications in YD/N 068-1997, Technical Specification of National No.7 Signaling System - Message Transfer Part (MTP). Signaling links in linksets with the apcntype=itun parameter are handled according to the specifications in ITU-T Q.2210 (07/96), Switching and Signaling, Broadband ISDN- Signaling Network Protocols. The default value for the apcntype parameter is itun.
- Linksets shown in section of the
rtrv-lsoutput with theLSN (CHINA)column (and with either theAPCNorAPCN24column) have theacpntype=itunchinaparameter assigned to them. - Linksets shown in section of the
rtrv-lsoutput with theLSNcolumn (and with either theAPCNorAPCN24column) have theacpntype=itunparameter assigned to them.
:lst – The linkset type of the specified linkset
:clli – The Common Language Location Identifier assigned to this point code. The value of the clli parameter is only displayed in the rtrv-ls command output when a specific linkset is being displayed with the rtrv-ls:lsn=<linkset name> command.
:sltset – The signaling link test message record to be associated with the linkset.
:l3tset – The level 3 timer set table. This parameter identifies which level three timer set is to be assigned to this linkset.
:scrn – The name of the screenset to be assigned to this linkset if gateway screening is to be used.
:gwsa – Gateway screening action determines whether gateway screening (GWS) is on or off for the specified link set.
:gwsm – Gateway screening messaging is used to turn on or off the display of messages generated for each screened message. When an MSU is rejected by gateway screening, a message is output to alert personnel of the event.
:gwsd – Gateway screening MSU discard is used to turn on or off the discarding of MSUs that bypass the gateway screening function due to load shedding. Also use this parameter with the redirect function; MSUs that cannot be screened are discarded if you specify gwsd=on.
:bei – The broadcast exception indicator. This parameter indicates whether TFP (transfer prohibited) messages are allowed to be broadcast on the linkset. The yes parameter means TFPs are not broadcast. The no parameter means TFPs are broadcast.
:nis – specifies whether the National Spare for Network Indicator feature is on or off for the specific linkset. This feature allows the linkset to use the national spare value (3) for the network indicator code field in the service information octet (SIO) of the MSU for ANSI linksets and ITU national linksets (linksets containing either 14-bit ITU-N point codes or 24-bit ITU-N point codes). This parameter cannot be specified for ITU international linksets. The default value for the nis parameter is off.
- For MSUs on incoming linksets, only those MSUs having the network indicator code values shown in Table 3-2 are allowed into the EAGLE.
- For MSUs on outgoing linksets, the network indicator code value in the MSU is changed to either the national network indicator code value (2) or the national spare network indicator code value (3). If the
nisparameter is set tooff, the network indicator code value is set to 2. - These actions are summarized in Table 3-2.
- The actions described for this parameter apply only if the ITU National and International Spare Point Code Support feature is not enabled.
- If the ITU National and International Spare Point Code Support feature is enabled, the
nisparameter value is ignored for ITU-I and 14-bit ITU-N linksets. All the network indicator values are permitted on ITU-I and ITU-N linksets, and the network indicator value for transmission is based on the International/National and Spare/Non-Spare status of the DPC of the message. - Having the ITU National and International Spare Point Code Support feature enabled has no effect on ANSI and 24-bit ITU-N linksets. The
nisparameter value determines which incoming network indicator spare bit values to permit, and what network indicator spare bit value should be transmitted.
Table 3-2 Actions of the National Spare for Network Indicator Feature
| Linkset Type | Feature Disabled | Feature Enabled |
|---|---|---|
|
Incoming ANSI Linkset |
MSUs containing the national network indicator code (2) are allowed into the EAGLE. |
MSUs containing these network indicator code values are allowed into the EAGLE. • National Network Indicator Code (2) • National Spare Network Indicator Code (3) |
|
Outgoing ANSI Linkset |
The network indicator code value in the MSU is set to the national network indicator code (2). |
The network indicator code value in the MSU is set to the national spare network indicator code (3). |
|
Incoming ITU National Linkset |
MSUs containing these network indicator code values are allowed into the EAGLE. • International Network Indicator Code (0) • National Network Indicator Code (2) |
MSUs containing these network indicator code values are allowed into the EAGLE. • International Network Indicator Code (0) • National Network Indicator Code (2) • National Spare Network Indicator Code (3) |
|
Outgoing ITU National Linkset |
The network indicator code value in the MSU is set to the national network indicator code (2). |
The network indicator code value in the MSU is set to the national spare network indicator code (3). |
:itutfr – specifies whether or not ITUTFR (transfer restricted) procedures are being used on the linkset. This parameter applies only to linksets with ITU national adjacent point codes (linksets containing either 14-bit ITU-N point codes or 24-bit ITU-N point codes) and can be specified only for linksets with ITU national adjacent point codes. TFR procedures are used to redirect traffic away from a node that is having problems routing traffic to a destination. When a node determines that a destination is restricted, the node sends a TFR message informing the adjacent nodes about the destination’s status. When a destination is restricted, the node should not be used to route messages to the destination even though it still has limited capability to do so. The values for this parameter are either on (ITUTFR procedures are enabled) or off (ITUTFR procedures are disabled). For more information about using the itutfr parameter, refer to ITU TFR Procedures.
:mtprse – shows if the node adjacent to the EAGLE is equipped with the MTP restart capability. The mtprse=yes parameter can only be specified if the MTP restart feature is turned on for ANSI linksets (MTPRS = on in the rtrv-feat command output), or if the ITUMTP restart is on for ITU linksets (ITUMTPRS=on in the rtrv-feat command output). If the MTP restart feature is not turned on, the value of the mtprse parameter defaults to no. The value of the mtprse parameter value is not dependent on the value of the mtprsi parameter (the MTP restart indicator) in the chg-stpopts command. The value of the mtprse parameter is only displayed in the rtrv-ls command output when a specific linkset is being displayed with the rtrv-ls:lsn=<linkset name> command. For more information on MTP Restart feature, refer to Configuring the MTP Restart Feature.
:slsci – indicates whether the 5-bit to 8-bit SLS conversion feature is used to select signaling links for outgoing messages on the specified link set. If the slsci=yes parameter is specified, the EAGLE replaces any 5-bit SLS values contained in received messages with a random 8-bit value before they are used by the EAGLE to select the outgoing signaling link in that linkset. The 5-bit to 8-bit SLS conversion is also controlled by the slscnv parameter of the chg-stpopts command. The slscnv parameter of the chg-stpopts command has three values: on, off, and perls. The slsci parameter can only be specified for linksets with ANSI SS7 adjacent point codes.
:asl8 – shows if the node adjacent to the EAGLE is sending MSUs with 8-bit SLSs. If the asl8=yes parameter is specified with the lst=a parameter (a linkset containing access signaling links), this indicates that the originator of the MSUs is generating 8-bit SLSs. For other linkset types, the asl8=yes parameter indicates that the adjacent node is converting 5-bit SLSs to 8-bit SLSs. The SLS in MSUs received by the EAGLE on a linkset that has the asl8=yes parameter assigned to it will not be converted. These MSUs are assumed to contain 8-bit SLSs. If the asl8=no parameter is specified for the linkset, the SLS will be converted to an 8-bit SLS. The asl8 parameter can only be specified for linksets with ANSI SS7 adjacent point codes. The value of the asl8 parameter is only displayed in the rtrv-ls command output when a specific linkset is being displayed with the rtrv-ls:lsn=<linkset name> command. For more information on the slsci and asl8 parameters and 5-bit to 8-bit SLS conversion, refer to Configuring the 5-Bit to 8-Bit SLS Conversion Feature.
:slsrsb – selects which bit (1 - 4) of the SLS field to use as the least significant bit for signaling link selection in the link set for all messages on outgoing ITU linksets.
:islsrsb – selects which bit of the SLS field, 1 - 5 for an ANSI linkset or 1 - 4 for an ITU linkset, to use as the least significant bit for signaling link selection in the link set for all messages on ANSI and ITU linksets on incoming linksets. The :islsrsb value for an ANSI linkset can be 1 - 8, but can be only 1 - 5 when adding an ANSI linkset. If you wish to use the values 6, 7, or 8 for the islsrsb parameter, the rsls8 value for the linkset must be yes. Perform these procedures after adding the linkset.
- Configuring the RSLS8 Value for ANSI Linksets – to change the
rsls8value for the linkset toyes. - Changing an SS7 Linkset – to change the
islsrsbvalue.
:slsocbit – selects which bit (5 - 16) of the SLS field to use as the most significant bit for signaling link selection in the link set for all ITU messages.
Note:
For more information on theslsrsb, islsrsb, and slsocbit parameters and ITUSLS enhancement, refer to ITU SLS Enhancement.
:multgc – specifies whether multiple group codes (for 14-bit ITU-N point codes) are supported for the linkset. When this parameter value is yes, secondary adjacent point codes whose group codes are different from the adjacent point code of the linkset can be assigned to the linkset. If the parameter value is no, the group code of the secondary adjacent point code must be the same as the group code of the linkset’s adjacent point code. For more information on secondary adjacent point codes, refer to Configuring an ITU Linkset with a Secondary Adjacent Point Code (SAPC).
- This parameter only applies to linksets whose adjacent point codes are either ITU international point codes or ITU national point codes. All the signaling links in this linkset must be assigned to cards running the IPLIMI application. For more information on assigning signaling links to cards running the IPLIMI application, go to the “Adding an IPSignaling Link” procedure in the Database Administration - IP7 User's Guide.
- The ITU duplicate point code feature must be on before this parameter can be specified. Verify this with the
rtrv-featcommand. If the ITU duplicate point code feature is turned on, theITUDUPPCfield should be set toon. If the ITU duplicate point code feature is not turned on, enter thechg-feat:ituduppc=oncommand.
Note:
Once the ITU duplicate point code feature is turned on with thechg-feat command, it cannot be turned off.
The ITU duplicate point code feature must be purchased before you turn the feature on with the chg-feat command. If you are not sure if you have purchased the ITU duplicate point code feature, contact your Oracle Sales Representative or Account Representative.
:gttmode – The GTT mode assigned to the linkset when performing global title translation on the specified linkset. The values for this parameter are:
sysdflt– the value of thedfltgttmodeparameter shown in thertrv-sccpoptscommand output.cd- CdPA GTT onlycg- CgPA GTT onlyacdcd- Advanced CdPA GTT, CdPA GTTacdcgcd- Advanced CdPA GTT, CgPA GTT, CdPA GTTacdcdcg- Advanced CdPA GTT, CdPA GTT, CgPA GTTcgacdcd- CgPAGTT, Advanced CdPA GTT, CdPA GTTcgcd- CgPAGTT, CdPA GTTcdcg- CdPA GTT, CgPA GTTfcd- Flexible Linkset Optional Based Routing (FLOBR) CdPA onlyfcg- FLOBR CgPA onlyfcdfcg- FLOBR CdPA, FLOBR CgPAfcgfcd- FLOBR CgPA, FLOBR CdPA
- The default value for this parameter is
sysdflt. For more information on using thegttmodeparameter, refer to the Origin-Based SCCP Routing Feature section or the Flexible Linkset Optional Based Routing section in Database Administration - GTT User's Guide. - To use the values
cg,acdcd,acdcgcd,acdcdcg,cgacdcd, orcgcdfor thegttmodeparameter, the Origin-Based SCCP Routing feature must be enabled and turned on. - To use the values
fcd,fcg,fcdfcg, orfcgfcdfor thegttmodeparameter, the Flexible Linkset Optional Based Routing feature must be enabled and turned on.
:randsls – The random SLS value assigned to the linkset. This parameter is used to apply random SLS generation for the specified linkset. The randsls parameter has three values:
off– Random SLS generation is not applied to the specified linkset.class0– Random SLS generation is applied to only Class 0 SCCP messages on either incoming ANSI or outgoing ITU linksets.all– Random SLS generation is applied to both Class 0 and Class 1 SCCP messages on outgoing ITU linksets, or to Class 0 SCCP messages and ISUP messages on ANSI linksets.
- For more information about random SLS generation on a specific linkset, refer to Per-Linkset Random SLS.
:cggtmod - The calling party GT modification indicator. This parameter specifies whether or not calling party global title modification is required. The values for this parameter are yes (calling party global title modification is required) or no (calling party global title modification is not required). The default value for the cggtmod parameter is no. This parameter can be specified only if the AMGTT or AMGTT CgPA Upgrade feature is enabled. Enter the rtrv-ctrl-feat command to verify that either the AMGTT or AMGTT CgPA Upgrade feature is enabled. If the AMGTT or AMGTT CgPA Upgrade feature is not enabled, perform the "Activating the Advanced GT Modification Feature" procedure in Database Administration - GTT User's Guide procedure to enable the required feature. For more information about the Advanced GT Modification feature, refer to the "Advanced GT Modification Feature" section in Database Administration - GTT User's Guide.
The linkset also contains the tfatcabmlq parameter, whose value is shown in the rtrv-ls:lsn=<linkset name> command. The tfatcabmlq parameter exists only in the chg-ls command and not the ent-ls command, because no links are assigned to the linkset when the linkset is first created with the ent-ls command. The default value for the tfatcabmlq parameter (tfatcabmlq=0) is entered for the linkset, and shown in the rtrv-ls output as 1, when a new linkset is added to the database.
The EAGLE can contain 1024 linksets, with a maximum of 255 of these linksets being gateway linksets. A gateway linkset is a linkset that contains routes to a different network.
The linkset to be added cannot be in the database. This can be verified in step 1 of this procedure.
The adjacent point code (APC) must be defined in the database, must be in the SS7 domain and cannot match the point code or capability point code of the EAGLE. This can be verified in steps 2 and 3 of this procedure. The domain of the point code is shown in the DMN field in the output of the rtrv-dstn command (step 3). The point code of the EAGLE is shown in the PCA, PCN, PCN24, or PCI fields and the capability point code of the EAGLE are shown in the CPCA, CPCN, CPCN24, or CPCI fields in the output of the rtrv-sid command (step 2). The adjacent point code must be a full point code and cannot be a cluster point code or a network routing point code.
If the APC is not in the destination point code table, perform Adding a Destination Point Code and add the APC to the destination point code table.
The ent-ls command has a parameter, gwsd, that can allow the discarding of messages that should have gone through the gateway screening process, but did not. The gwsd parameter is only intended to be used with the Database Transport Access (DTA) feature. If you are not using the DTA feature, the gwsd parameter should not be specified or should be set to no (gwsd=no).
The gwsa, gwsm, and gwsd parameters can only be specified if the scrn parameter is specified. If the scrn parameter is specified, the gateway screening screen set name specified by this parameter must also be defined as a gateway screening screen set entity. This can be verified with the rtrv-scrset command.
Caution:
When Gateway Screening is in the screen test mode, as defined by the linkset parametersgwsa=off and gwsm=on, the gateway screening action in the gateway screening stop action set specified by the actname parameter of the gateway screening screen set at the end of the gateway screening process will be performed.
To help manage congestion on signaling links, the EAGLE starts the level 3 T31 timer whenever a signaling link goes into congestion level 1 or congestion level 2. The congestion level that is associated with the level 3 T31 timer is set using the chg-stpopts command with the mtpt31ctl parameter and is displayed with the MTPT31CTL field in the rtrv-stpopts command output. When the level 3 timer T31 and the chg-stpopts command are first introduced to the EAGLE, the system default value for the mtpt31ctl parameter of the chg-stpopts command is 1, for congestion level 1, and the system default value for the level 3 T31 timer is 60 seconds. To change the value of the level 3 T31 timer, perform Changing Level 3 Timers. To change value of the mtpt31ctl parameter, enter the either chg-stpopts:mtpt31ctl=1 or the chg-stpopts:mtpt31ctl=2 command, depending on the current value of the mtpt31ctl parameter.
To help prevent the signaling link in the linkset from oscillating in out of service, the EAGLE starts the level 3 T32 timer. When the EAGLE begins restoring an out of service signaling link, the EAGLE starts the level 3 T32 timer. If the signaling link fails again before the level 3 T32 expires, the EAGLE does not attempt to continue to bring the signaling link into service until the level 3 T32 timer expires. Once the level 3 T32 timer expires, the EAGLE attempts to restore the signaling link into service. When the level 3 timer T32 is first introduced to the EAGLE, the default value for the level 3 T32 timer is 60 seconds. To change the value of the level 3 T32 timer, perform Changing Level 3 Timers.
The word SEAS cannot be used as a value for the scrn parameter of the ent-ls command. The word SEAS is used in the rtrv-ls command output, in the SCRN field, to show gateway linksets created on the SEAS interface. A gateway linkset combines the functions of a gateway screening screen set and an SS7 linkset specifying the gwsa=on and scrn parameters. Like a EAGLE gateway screening screen set, a gateway linkset defines the screening references that are to be used to screen the messages on the linkset. It also defines the linkset whose messages are to be screened. A gateway linkset can only be configured from a SEAS terminal and not from a EAGLE terminal.
If the clli parameter is specified with the ent-ls command, the value of the clli parameter must match the CLLI value of the adjacent point code of the linkset. The CLLI value of the adjacent point code is shown in the CLLI field of the rtrv-dstn command.
If the randsls parameter of the chg-stpopts command is set to either all or class0, a maximum of 16 links continues to be supported in a single linkset to a destination. However, it is now possible to have up to 32 links in a combined linkset to a destination, with a maximum of 16 links per linkset. The 32 links is a change from the current EAGLE maximum of only 16 links per combined linkset, which is due to ITU protocol restrictions. If more than 16 links are used in a combined linkset, the operator needs to be aware that a maximum of 16 links can be used by non-Random SLS traffic over the linkset. The non-Random SLS traffic continues to operate under the rules of the ITU protocol. For more information on the Random SLS Generation feature, perform Configuring the System for Random SLS Generation.
Canceling the RTRV-LS and RTRV-DSTN Commands
Because the rtrv-ls and rtrv-dstn commands used in this procedure can output information for a long period of time, the rtrv-ls and rtrv-dstn commands can be canceled and the output to the terminal stopped. There are three ways that the rtrv-ls and rtrv-dstn commands can be canceled.
- Press the
F9function key on the keyboard at the terminal where thertrv-lsorrtrv-dstncommands were entered. - Enter the
canc-cmdwithout thetrmparameter at the terminal where thertrv-lsorrtrv-dstncommands were entered. - Enter the
canc-cmd:trm=<xx>, where<xx>is the terminal where thertrv-lsorrtrv-dstncommands were entered, from another terminal other that the terminal where thertrv-lsorrtrv-dstncommands were entered. To enter thecanc-cmd:trm=<xx>command, the terminal must allow Security Administration commands to be entered from it and the user must be allowed to enter Security Administration commands. The terminal’s permissions can be verified with thertrv-secu-trmcommand. The user’s permissions can be verified with thertrv-userorrtrv-secu-usercommands.
For more information about the canc-cmd command, go to Commands User's Guide.
Figure 3-1 Adding a SS7 Linkset
ITU SLS Enhancement
The ITU SLS Enhancement gives customers the ability to modify the method the EAGLE distributes traffic across SS7 links.
The EAGLE uses the least significant bit of the SLS to load share between linksets of a combined linkset. ITU ISUP messages use a SLS that is obtained from the lower 4 bits of the CIC field representing the circuit being used. Figure 3-2 shows the ITU ISUP routing label with the CIC field.
Figure 3-2 ITU ISUP Routing Label with CIC
CIC selection can be determined based on an odd or even method where a SSP uses either all odd CICs, or all even CICs, to help prevent “glaring” (that is, 2 SSPs attempting to seize the same trunk at the same time). This causes the least significant bit of the SLS to be fixed. If the least significant bit is fixed, inadequate load sharing occurs for the SS7 network. This situation can also occur within a single linkset (international), since the EAGLE also uses the lower 4 bits of the SLS (containing a fixed least significant bit) to select a link within a linkset.
This enhancement provides the user three options for addressing the problem:
- Bit Rotation – The EAGLE rotates the 4 bits of the SLS, thus changing the least significant bit of the SLS. If selected, this option is applied to all ITU messages. This option is set with the
slsrsbparameter of either theent-lsorchg-lscommands. This action takes place on the outgoing linkset. More information on this option can be found in Bit Rotation. - Use of Other CIC Bit – The EAGLEderives the SLS from the bits 2 through 4 of the CIC to serve as the three lower bits of SLS, and one other bit of the CIC to serve as the most significant bit of the SLS. If selected, this option is only applied to ITU ISUP messages. This option is set with the
slsocbitparameter of either theent-lsorchg-lscommands. More information on this option can be found in Use of the Other CIC Bit.Before the Use of the Other CIC Bit option can be set, the Other CIC Bit Used feature must be turned on with the
chg-featcommand and theslsocb=onparameter. This can be verified with theSLSOCB = onentry of thertrv-featcommand output.The
slsrsbandslsocbitparameters can only be specified for linksets that contain either an ITU international or ITU national adjacent point code (either a 14-bit or 24-bit ITU-N adjacent point code).The value of the
slsrsbandslsocbitparameters are only displayed in thertrv-lscommand output when a specific linkset is being displayed with thertrv-ls:lsn=<linkset name>command.Note:
When two linksets are used as a combined linkset, both linksets should use the sameslsrsbandslsocbitvalues.Note:
If therandslsparameter of thechg-stpoptscommand, a system-wide option, is set to eitherallorclass0, the EAGLE uses the Random SLS Generation feature to perform load sharing between ITU linksets. Theslsrsbparameter value is ignored. However, theent-lsandchg-lscommands allow theslsrsbparameter value to be specified. For more information on the Random SLS Generation feature, refer to Configuring the System for Random SLS Generation. - Incoming Bit Rotation - The EAGLE changes the least significant bit of the SLS on ANSI and ITU messages on incoming linksets by rotating the 4 bits of the SLS. This option is set with the
islsrsbparameter of either theent-lsorchg-lscommands. More information on this option can be found in Incoming Bit Rotation.
Only the link selection algorithm is modified by this feature, not the actual SLS field of the message (that is, the SLS value received by the EAGLE is the SLS value sent by the EAGLE).
Bit Rotation
To alleviate the situation of the EAGLE selecting the same linkset of a combined linkset, the customer can apply the bit rotation option. Bit rotation can be used, on a per linkset basis, to ensure the EAGLE does not use the static least significant bit (always 0 or always 1) in the received SLS for linkset selection.
When defining a link set using the ent-ls or chg-ls commands, the customer will be able to select which bit (1-4) of the SLS field to use as the least significant bit for link set selection. This rotation only affects the 4 bits of the SLS during linkset selection, as follows:
- If bit 4 is selected, bit locations 4 3 2 1 will be rotated to 3 2 1 4.
For example: SLS = 0110 becomes Rotated SLS = 1100. SLS = 1011 becomes Rotated SLS = 0111
- If bit 3 is selected, bit locations 4 3 2 1 will be rotated to 2 1 4 3.
For example: SLS = 0110 becomes Rotated SLS = 1001. SLS = 1011 becomes Rotated SLS = 1110
- If bit 2 selected, bit locations 4 3 2 1 will be rotated to 1 4 3 2.
For example: SLS = 0110 becomes Rotated SLS = 0011. SLS = 1011 becomes Rotated SLS = 1101
- If bit 1 is selected, no rotation is performed, since bit 1 is the existing least significant bit. Bit 1 is the default value.
Figure 3-3 shows an example of bit rotation.
Figure 3-3 Example of Bit Rotation
After the SLS is rotated, the existing algorithm for selecting a linkset and signaling link is performed, and the message is sent out the selected link. Note that the SLS is modified only for the link selection algorithm, and is not modified in the outgoing message.
Use of bit rotation alone does not guarantee an even distribution of ITU-ISUP messages across all links within a linkset. The EAGLE uses all 4 bits of the SLS to determine the actual link to route messages. Since the static bit is simply rotated within the SLS, all possible values of the SLS field will still not be realized. A second option, Use of the Other CIC Bit, must be applied to guarantee even distribution across all links within the linkset.
Use of the Other CIC Bit
The Use of the Other CIC Bit option can be applied by the customer to alleviate the problem of the EAGLE not load sharing between all links within a linkset. When defining a linkset with the chg-ls or ent-ls command, the user can specify whether the Use of the Other CIC Bit option is to be used during link selection. If the option is to be used, the customer can also specify which bit (bits 5 through 16 of CIC) is to be used as the “other CIC bit”.
During link selection, the specified bit acts as the most significant bit of the new SLS, and bits 2 through 4 of the received CIC become the least significant bits of the new SLS.
Figure 3-4 shows how the new SLS field is generated using the “other CIC bit.”
Figure 3-4 SLS creation Using “Other CIC Bit”
After the SLS is generated using the “other CIC bit”, the existing algorithm for selecting a linkset and signaling link is performed, and the message is sent out from the selected link. Note that the SLS is modified only for the link selection algorithm, and is not modified in the outgoing message.
Incoming Bit Rotation
Incoming Bit Rotation is set on the incoming linkset, where the existing SLS bit rotation option is set on the outgoing linkset. The algorithm used for rotating the SLS bits on outgoing linksets is also used on incoming linksets. This method provides additional capability to fairly distribute traffic across links and linksets, however it still does not guarantee an even distribution of messages for all set of input SLS values. Rotating SLS Bits on outgoing linksets is supported only for ITU linksets. Rotating SLS bits on incoming linksets is supported for ANSI and ITU linksets. For ITU linksets, the SLS value is only four bits and all four bits are considered for bit rotation. Table 3-4 shows examples of bit rotation for ITU linksets.
Table 3-4 ITU SLS Bit Rotation
| Incoming ITU SLS Value | Least Significant Bit Being Rotated | Rotated SLS Value |
|---|---|---|
| 0110 | 2 | 0011 |
| 1110 | 3 | 1011 |
| 0010 | 1 | 0010 |
| 1101 | 4 | 1011 |
For ANSI linksets, which may have a five or eight bit SLS value, the full five or eight bits are considered for link and linkset selection. Table 3-5 shows the rules that apply to rotating the SLS bit value in an ANSI linkset.
Table 3-5 ANSI Linkset Incoming Bit Rotation Rules
| Rule | Incoming Linkset ASL8 Value | Incoming Linkset RSLS8 Value | ISLSRSB Values | SLSCNV/ Outgoing Linkset SLSCI Value | Incoming SLS Bit Rotation (ISLSBR) |
|---|---|---|---|---|---|
| 1 | No | No | 1 - 5 | No | The least significant 5 bits of the SLS are considered for rotation. |
| 2 | No | No | 1 - 5 | Yes | The least significant 5 bits of the SLS are considered for rotation. |
| 3 | No | Yes | 1 - 8 | No | No incoming SLS bit rotation is performed. The 5-Bit to 8-Bit SLS Conversion feature must be turned on to perform incoming SLS bit rotation. |
| 4 | No | Yes | 1 - 8 | Yes | The 8 bit SLS value is obtained after the 5-bit to 8-bit SLS conversion is performed is considered for rotation. |
| 5 | Yes | No | 1 - 5 | N/A | The least significant 5 bits of the SLS are considered for rotation. |
| 6 | Yes | Yes | 1 - 8 | N/A | The 8-bit SLS value is considered for rotation. |
Rotating the SLS bits on ANSI linksets is based on the combination of the ASL8, RSLS8, SLSCNV/SLSCI, and ISLSRSB parameter values.
The ASL8 parameter value for the incoming linkset specifies whether the adjacent node is sending messages with a 5-bit SLS or an 8-bit SLS.
If the ASL8 parameter value for the incoming linkset is No, and the global SLSCNV/SLSCI parameter value for the outgoing linkset is Yes, the 5-Bit to 8-Bit SLS Conversion feature is applied to the incoming 5-bit SLS value.
The RSLS8 parameter value for the incoming linkset specifies the number of SLS bits to be considered for rotation. If the RSLS8 value is Yes, 8 bits are considered for rotation. If the RSLS8 value is No, the least significant 5 bits of the SLS are considered for rotation. If the ASL8 value is No, the RSLS8 value is Yes, and the STPCNV/SLSCI value is No, then no rotation is performed. See Table 3-6.
Table 3-6 ANSI SLS Bit Rotation
| Incoming ANSI SLS | Incoming Linkset RSLS8 Value | Least Significant Bit Being Rotated | Outgoing ANSI SLS | Rotated SLS | Rule Applied |
|---|---|---|---|---|---|
| 11000110 | No | Bit 2 | 11000110 | 11000011 | 5 |
| 01011110 | Yes | Bit 7 | 01011110 | 01111001 | 6 |
| 10010 | No | Bit 4 | 10110010 | 10101010 | 2 |
| 10010 | Yes | Bit 8 | 10110010 | 01100101 | 4 |
| 01101 | No | Bit 4 | 01101 | 10101 | 1 |
| 01101 | Yes | Bit 7 | 01101 | No Rotation | 3 |
- All the bits to the right side of the bit chosen to the least significant bit are removed as a block.
- The remaining bits are right justified.
- The block of digits that was removed in step 1 is inserted to the left of the bits that were right justified in step 2.
The new SLS value created after the SLS bits have been rotated is used for linkset and signaling link selection.
Combining the Bit Rotation, Use of the Other CIC Bit, Incoming Bit Rotation, and Random SLS Options
- If the RANDSLS value (system-wide or on the incoming linkset) is
on, then an 8-bit random SLS value is generated. - If the Random SLS option is applied and the system-wide SLSREPLACE value is
on, the randomly generated SLS value is replaced. Go to step 5. - If the global SLSCNV/SLSCI value for the outgoing linkset is
on, the 5-bit ANSI SLS value is converted to an 8-bit SLS value using the 5-Bit to 8-bit SLS Conversion feature. - If the Random SLS option is not applied, the converted SLS value is modified using the Incoming Bit Rotation option.
- The modified SLS value is used by the existing linkset and signaling link selection algorithm to select a linkset and a signaling link.
- If the linkset type of the outgoing linkset is C (
lst=c), the SLS value is modified using the standard fifth bit rotation, replaced in the MSU, and sent to the selected signaling link.
ITU TFR Procedures
Receiving TFR Messages
If ITU TFR procedures have been enabled for the linkset and a TFR message is received on that linkset, the EAGLE marks the route to the destination as restricted and performs controlled rerouting of the messages that are destined for the destination specified in the TFR message.
If ITU TFR procedures have not been enabled for the linkset and a TFR message is received on that linkset, the TFR message is converted to a TFA (transfer allowed) message and traffic is routed to the destination specified in the TFR message. When this condition is present and a TFR is received on this linkset, UIM 1233 is displayed showing that a TFR was received on a linkset that does not support the TFR procedure.
When a TFR message is received for a route that is already prohibited, and no alternative route exists, the traffic to the concerned node is restarted toward the signaling point from which the TFR message was received.
Invalid TFR messages
The TFR message is ignored under any of these conditions:
- The TFR message is not from an adjacent point code.
- The point code specified in the TFR message is being sent from that same point code.
- The TFR message is from an unknown destination.
- The TFR message is from an adjacent point code, but the adjacent point code is not the route for concerned point code.
- If the route to the concerned point code is already restricted.
- The route to concerned point code not found or is unavailable.
Sending TFR Messages
The EAGLE must send a TFR message containing the affected point code (restricted destination) to all accessible adjacent nodes, whose linkset has the TFR procedure enabled, when the following conditions are in effect:
- When long term failure occurs on the ITU-N linkset (primary) used to route messages to the affected point code. Long term failure occurs when all links of a linkset remain unavailable for more than the amount of time specified by level 3 timer T11.
- While waiting for “long term failure” to be determined, if congestion (or “danger of congestion”) is detected on an alternate linkset used to route messages to the affected point code, then TFRs are sent immediately without waiting for level 3 timer T11 to expire. For example: level 3 timer T11 is set to 30 seconds, the links of the linkset to the adjacent node fail and MSUs are now sent out the alternate linkset. Within 10 seconds of the failure, congestion is detected on the alternate linkset, so TFR messages are sent to each adjacent point code (if linkset has ITUTFR procedures enabled) for each destination (affected point code) routed through that node.
- When an adjacent node becomes accessible by an alternate route, the EAGLE sends a TFR for each destination that is restricted to the node.
- During restarts, TFRs are broadcast to all accessible adjacent nodes for each restricted destination.
Unlike the ANSI network, the ITU national network does not use response method TFR messages. The ITU national network only uses broadcast method TFR messages that are sent to all adjacent nodes under the conditions described above.
Note:
In ANSI networks, response method TFRs are sent to adjacent nodes in response to a MSU, when that node continues to send MSUs after a broadcast method TFR has already been sent.The EAGLE maintains the status (allowed, restricted, or prohibited) for all destinations. XREF shows the type of message sent when a destination transitions from one status to another.
Table 3-7 Route Management Messages Sent on Status Transition
| Status Transition | ITUTFR Procedures Enabled | ITUTFR Procedures Disabled |
|---|---|---|
|
Prohibited to Restricted |
TFR |
TFA |
|
Allowed to Restricted |
TFR |
None |
|
Restricted to Prohibited |
TFP |
TFP |
|
Restricted to Allowed |
TFA |
None |
Per-Linkset Random SLS
To achieve load balancing of outgoing traffic on ITU linksets, linksets that have either an ITU-I, 14-bit ITU-N, or 24-bit ITU-N adjacent point code assigned, the EAGLE 5 ISS currently uses the Random SLS option to generate a new SLS (signaling link selector) value. The randomly generated SLS value is used to select an outgoing signaling link and linkset. Random SLS generation applies to either Class 0 SCCP messages or to both Class 0 and Class 1 SCCP messages. The Random SLS option is configured using the randsls parameter of the chg-stpopts command. Refer to Configuring the System for Random SLS Generation for more information on configuring the Random SLS option.
This method of selecting outgoing signaling links and linksets is applied system-wide to all ITU linksets. This may cause problems for some end nodes that may have specific requirements for handling incoming SCCP messages, such as sequencing of Class 1 SCCP messages.
The Per-Linkset Random SLS feature provides the ability to apply Random SLS generation to Class 0 and Class 1SCCP messages on specific outgoing ITU linksets and to Class 0 SCCP messages and ISUP messages on specific incoming ANSI linksets. The randsls parameter of either the ent-ls or chg-ls command applies this feature to the linkset. The randsls parameter has three values:
off– Random SLS generation is not applied to the specified linkset.class0– Random SLS generation is applied to only Class 0 SCCP messages.all– Random SLS generation is applied to both Class 0 and Class 1 SCCP messages on a specific outgoing ITU linksets, and to both Class 0 SCCP and ISUP messages on specific ANSI linksets.
When per-linkset random SLS is applied to ANSI linksets, linksets that have ANSI adjacent point codes, the SLS of the message is replaced with a randomly generated SLS, only if the slsreplace parameter value is set to yes. The slsreplace parameter value is shown in the rtrv-ss7opts output. If the slsreplace parameter value is no, the EAGLE 5 ISS uses the randomly generated SLS to select the signaling link, but the message retains the original SLS. If the linkset’s asl8 or slsci parameter value is off, or the chg-stpopts slscnv parameter is off, a 5-bit SLS is placed in the message. The three most significant bits of the SLS are zeroes. If the linkset’s asl8 or slsci parameter value is on, or the slscnv parameter of the chg-stpopts command is on, an 8-bit SLS is placed in the message. The linkset’s asl8 parameter value is not used for internal linkset and signaling link selection. The linkset's asl8 parameter applies only to incoming linksets. The linkset's slsci parameter applies only to outgoing linksets. The randomly generated SLS value is used for internal linkset and signaling link selection. When an ANSI to ITU conversion takes place, the randomly generated SLS value for the incoming ANSI linkset is used for internal linkset and signaling link selection and Random SLS generation on outgoing linkset is not performed.
The randsls parameter is optional. If the randsls parameter is not specified when adding a linkset with the ent-ls command, the value of the randsls parameter is off. If the randsls parameter is not specified when changing a linkset with the chg-ls command, the value of the randsls parameter is not changed.
The value of the randsls parameter assigned to the linkset is displayed in the RANDSLS column of the rtrv-ls command output. The RANDSLS column is displayed only when a specific linkset is being displayed with the rtrv-ls:lsn=<linkset name> command. All linksets having a particular randsls value can be displayed by entering the rtrv-ls command with the randsls parameter with one of these values:
off– Displays the linksets where random SLS generation is disabled.class0– Displays the linksets where random SLS generation for Class 0 SCCP traffic is enabled.all– Displays the linksets where random SLS generation for Class 0 and Class 1 SCCP traffic on a specific outgoing ITU linksetsis enabled, and Class0 SCCP and ISUP messages on specific incoming ANSI linksets is enabled..
For random SLS generation to be performed on a specific linkset, the randsls parameter value for that linkset must be set to either class0 or all. The system-wide random SLS STP option randsls must be set to perls using the chg-stpopts command with the randsls=perls parameter. Refer to Configuring the System for Random SLS Generation for more information on configuring the system-wide Random SLS option, and, if Random SLS is applied to ANSI linksets, to configure the SS7 option for replacing the SLS in the message with the randomly generated SLS.
It is recommended that when configuring randsls values on two linksets that are in a combined linkset that the randsls values for these linksets are the same. If these values are not the same, undesired SLS distribution of the traffic on these linksets may result.
Verifying the Gateway Screening Configuration for a Linkset
This procedure is used to verify that the screen set that will be assigned to the linkset, and its associated screens, is in the database.
Figure 3-5 Verifying the Gateway Screening Configuration for a Linkset
Configuring the MTP Restart Feature
chg-feat-mtprs=on(to turn on MTP Restart for ANSI signaling links) anditumtprs=on(to turn on MTP Restart for ITU signaling links)-
chg-stpopts-
on=mtprsi- to enable the MTP Restart process, oroff=mtprsi, to disable the MTP Restart process. When theon=mtprsiparameter is specified for thechg-stpoptscommand, the valueyesis shown in theMTPRSIfield of thertrv-stpoptsoutput. When theoff=mtprsiparameter is specified for thechg-stpoptscommand, the valuenois shown in theMTPRSIfield of thertrv-stpoptsoutput. The system default value for this option isno. mtprsit- the MTP restart isolation timer - 2000 to 900000 milliseconds. The system default value is 5000 milliseconds.
-
The MTP restart feature is applied to the signaling links in a linkset by specifying the mtprse=yes parameter of the ent-ls or chg-ls commands. Perform Adding an SS7 Linkset or Changing an SS7 Linkset to specify the mtprse value for a linkset.
If the MTP restart feature is turned on, the alignment of all signaling links is delayed until all the LIMs containing signaling links are in service. This allows the EAGLE to be restored to network service in an orderly fashion and allows all the LIMs containing signaling links to participate in the MTP restart process. The amount of time that the alignment of the signaling links is delayed is dependent on the number of LIMs and DCMs in the EAGLE and is shown in Table 3-8. Table 3-8 shows and example of MTP signaling link alignment delay for LIMs.
Note:
The MTP restart feature can be used on linksets containing non-IP signaling links, IP signaling links with theipliml2=m2pa parameter, or IPSG signaling links with the ipsg=yes and adapter=m2pa parameters.
Table 3-8 MTP Restart Signaling Link Alignment Delay
| Number of LIMs Containing Signaling Links | Signaling Link Alignment Delay |
|---|---|
|
1 to 64 |
62 seconds |
|
64 to 127 |
97 seconds |
|
128 to 191 |
132 seconds |
|
192 or more |
167 seconds |
If the ANSI MTP restart feature is on (MTPRS = on in the rtrv-feat command output), the mtprsi parameter is set to yes, and at least one ANSI linkset has the mtprse parameter set to yes, the EAGLE starts these level 3 timers; T22, T23, T24, T25, T26, T28, T29, and T30 to control the behavior of the MTP restart feature. These timers control when the TRA and TRW network management messages are sent to the nodes adjacent to the EAGLE when the EAGLE is going through the MTP restart process. When these timers are first introduced to the EAGLE, the system default values for these timers are:
- T22 - 10 seconds
- T23 - 10 seconds
- T24 - 10 seconds
- T25 - 30 seconds
- T26 - 12 seconds
- T28 - 3 seconds
- T29 - 60 seconds
- T30 - 30 seconds.
To change the values of these timers, perform Changing Level 3 Timers.
If the ITU MTP restart feature is on (ITUMTPRS = on in the rtrv-feat command output), the mtprsi parameter is set to yes, and at least one ITU linkset has the mtprse parameter set to yes, the EAGLE starts these level 3 timers; IT18, IT19, IT20, and IT21 to control the behavior of the ITU MTP restart feature. These timers control when the TRA and TRW network management messages are sent to the nodes adjacent to the EAGLE when the EAGLE is going through the MTP restart process. When these timers are first introduced to the EAGLE, the default values for these timers are:
- IT18 - 50 seconds
- IT19 - 67 seconds
- IT20 - 59 seconds
- IT21 - 63 seconds.
To change the values of these timers, perform Changing Level 3 Timers.
If both the ANSI and ITU MTP restart features are on, the mtprsi parameter is set to yes, and at least one ANSI and ITU linkset has the mtprse parameter set to yes, the EAGLE starts the level 3 timers for both the ANSI and ITU MTP restart features to control the behavior of both the ANSI and ITU MTP restart features.
Figure 3-6 Configuring the MTP Restart Feature
Configuring the 5-Bit to 8-Bit SLS Conversion Feature
This procedure is used to configure the 5-Bit to 8-Bit SLS Conversion feature using the chg-stpopts command with the slscnv parameter.
The slscnv parameter of the chg-stpopts command has three values: on, off, and perls.
slscnv=on– 5-bit to 8-bit conversion is performed on all linksets in the EAGLE, regardless of what the value of theslsciparameter of theent-lsorchg-lscommand is for the specific linkset. If theasl8=yesparameter of either theent-lsorchg-lscommands is assigned to the linkset, no SLS conversion is performed.slscnv=off– 5-bit to 8-bit conversion is not performed on the linksets in the EAGLE, regardless of what the value of theslsciparameter of theent-lsorchg-lscommand is for the specific linkset.slscnv=perls– 5-bit to 8-bit SLS conversion is only performed on the MSUs arriving at the EAGLE on linksets that have theasl8=noparameter assigned to them, and leaving the EAGLE on linksets that have theslsci=yesparameter assigned to them. Theasl8andslsciparameters are configured with either theent-lsorchg-lscommands.
5-Bit to 8-Bit SLS conversion is performed based on the values assigned to the slsci and asl8 parameters for the linkset and the slscnv parameter of the chg-stpopts command.
Note:
Theslsci and asl8 parameters can be specified only for linksets containing ANSI adjacent point codes.
The slsci parameter indicates whether the 5-bit to 8-bit SLS conversion feature is used to select signaling links for outgoing messages on the specified link set. If the slsci=yes parameter is specified, the EAGLE replaces any 5-bit SLS values contained in received messages with a random 8-bit value before they are used by the EAGLE to select the outgoing signaling link in that linkset. The 5-bit to 8-bit SLS conversion is also controlled by the slscnv parameter of the chg-stpopts command.
The asl8 parameter shows if the node adjacent to the EAGLE is sending MSUs with 8-bit SLSs. If the asl8=yes parameter is specified with the lst=a parameter (a linkset containing access signaling links), this indicates that the originator of the MSUs is generating 8-bit SLSs. For other linkset types, the asl8=yes parameter indicates that the adjacent node is converting 5-bit SLSs to 8-bit SLSs. The SLS in MSUs received by the EAGLE on a linkset that has the asl8=yes parameter assigned to it will not be converted. These MSUs are assumed to contain 8-bit SLSs. If the asl8=no parameter is specified for the linkset, the SLS will be converted to an 8-bit SLS. The value of the asl8 parameter is only displayed in the rtrv-ls command output when a specific linkset is being displayed with the rtrv-ls:lsn=<linkset name> command.
The interaction between the slsci and asl8 parameters of the ent-ls command and the slscnv parameter of the chg-stpopts command is shown in Table 3-9.
Table 3-9 Signaling Link Selector (SLS) Conversion (ANSI Linksets Only)
| CHG-STPOPTSSLSCNV Parameter Value | Outgoing Linkset SLSCI Parameter Value | Incoming Linkset ASL8 Parameter Value | Result |
|---|---|---|---|
|
ON |
Not Applicable |
YES |
The adjacent node is sending 8-bit SLSs. No SLS conversion is performed on MSUs received on this linkset. |
|
ON |
Not Applicable |
NO |
The adjacent node is not sending 8-bit SLSs. 5-bit to 8-bit SLS conversion on MSUs received on this linkset. |
|
OFF |
Not Applicable |
YES |
The adjacent node is sending 8-bit SLSs. No SLS conversion is performed on any linksets. |
|
OFF |
Not Applicable |
NO |
The adjacent node is not sending 8-bit SLSs. 5-bit to 8-bit SLS conversion is not performed on all linksets. |
|
PERLS* |
YES |
YES |
The adjacent node is sending 8-bit SLSs. No SLS conversion is performed. |
|
PERLS* |
YES |
NO |
The adjacent node is not sending 8-bit SLSs. 5-bit to 8-bit SLS conversion is performed. |
|
PERLS* |
NO |
YES |
The adjacent node is sending 8-bit SLSs. No SLS conversion is performed. |
|
PERLS* |
NO |
NO |
The adjacent node is not sending 8-bit SLSs. 5-bit to 8-bit SLS conversion is not performed. |
|
*When the |
|||
When a 5-bit ANSI SLS is converted to an 8-bit ANSI SLS, the three most significant bits of the SLS are set using a function of originating point code and incoming signaling link. This ensures that MSUs with the same originating point code, SLS, and incoming signaling link will always have the same SLS after the conversion, guaranteeing that the MSUs arrive at the destination in the same sequence that they were sent.
5-bit to 8-bit SLS conversion is performed under these conditions.
- The incoming linkset is an ANSI linkset, a linkset containing an ANSI adjacent point code.
- The
asl8=noparameter of theent-lsorchg-lscommand is assigned to the incoming linkset. - The outgoing linkset is an ANSI linkset.
- The
slscnv=onparameter of thechg-stpoptscommand is specified - The
slscnv=perlsparameter of thechg-stpoptscommand is specified andslsci=yesparameter of theent-lsorchg-lscommand assigned to the outgoing linkset. - The three most significant bits of the SLS in the MSU are zero.
All ANSI MSUs originating from the EAGLE have an 8-bit SLS.
The EAGLE also converts ANSI SLSs to ITU SLSs, and ITU SLSs to ANSI SLSs.
When an ITU SLS is converted to an ANSI SLS, the ITU SLS is always converted to an ANSI 5-bit SLS. If the MSU containing the converted SLS is rerouted because of a link outage, the SLS may be converted from a 5-bit SLS to an 8-bit SLS.
When an ANSI SLS is converted to an ITU SLS, the ANSI SLS is always converted to an ITU 4-bit SLS.
The EAGLE does not convert a 4-bit ITU SLS to an 8-bit ANSI SLS.
The 5-bit to 8-bit SLS conversion takes place during the routing process, after the linkset is selected, but before the signaling link is selected. The ITU to ANSI SLS conversion takes place during the ANSI to ITU MSU conversion and after the outgoing signaling link is chosen.
Figure 3-7 Configuring the 5-Bit to 8-Bit SLS Conversion Feature
Using Proxy Point Codes and Secondary Point Codes when Adding a Linkset
- Proxy point codes for adding proxy linksets
- Secondary point codes for adding multiple linksets with the same adjacent point code.
To add a proxy linkset, a proxy point code must be assigned to the APC of the linkset, a proxy point code must be assigned to the linkset with the ppc/ppca/ppci/ppcn/ppcn24 parameter, and the linkset type must be prx. A quantity of proxy point codes must be enabled with the enable-ctrl-feat command before a proxy point code and a proxy linkset can be added. The first time a proxy linkset is added, the proxy point code that is assigned to the linkset must be the same proxy point code that is assigned to the APC of the proxy linkset. A maximum of 10 linksets can be added using the same proxy point code. For more information on proxy point codes, refer to Proxy Point Codes.
To add more than one linkset with the same APC, the Multiple Linksets to Single Adjacent PC feature must be enabled and turned on. The database can contain a maximum of six linksets that have the same APC. If the linkset is not a proxy linkset (linkset types A, B, C, D, or E), a secondary point code (shown in the rtrv-spc output) must be specified with the linkset. The network type and format of the secondary point code must be the same as the APC of the linkset. Secondary point codes can also be assigned to the APC of the linkset when the point code is added in the database with the ent-dstn or chg-dstn commands. The secondary point code that is assigned to the linkset with the spc/spca/spci/spcn/spcn24 parameter cannot be the same secondary point code that is assigned to the APC of the linkset.
If the linkset is a proxy linkset (linkset type PRX), a proxy point code (shown in the rtrv-dstn output) must be specified with the linkset. The proxy point code is assigned to the linkset with the ppc/ppca/ppci/ppcn/ppcn24 parameter. The network type and format of the proxy point code must be the same as the APC of the linkset. If proxy linksets are added, the database must contain one proxy linkset with a proxy point code assigned to the APC of the linkset and the same proxy point code must be assigned to the linkset. The proxy point code that is assigned to the other proxy linksets using this APC cannot be the same as the proxy point code that is assigned to the APC of the linkset.
Figure 3-8 Using Proxy Point Codes and Secondary Point Codes when Adding a Linkset
Activating the SLS Bit Rotation by Incoming Linkset Feature
This procedure is used to enable and turn on the SLS Bit Rotation by Incoming Linkset feature using the feature's part number and a feature access key.
The feature access key for the SLS Bit Rotation by Incoming Linkset feature is based on the features part number and the serial number of the EAGLE, making the feature access key site-specific.
The enable-ctrl-feat command enables the feature by inputting the feature access key and the feature part number with these parameters:
:fak – The feature access key provided by Oracle.
:partnum – The Oracle-issued part number of the SLS Bit Rotation by Incoming Linkset feature, 893026501.
Once this feature is enabled, it is permanently enabled. This feature cannot be enabled with a temporary feature access key.
The enable-ctrl-feat command requires a valid serial number for the EAGLE to be configured in the database, and that this serial number is locked. This can be verified with the rtrv-serial-num command. The EAGLE is shipped with a serial number in the database, but the serial number is not locked. The serial number can be changed, if necessary, and locked once the EAGLE is on-site, by using the ent-serial-num command. The ent-serial-num command uses these parameters.
:serial – The serial number assigned to the EAGLE. The serial number is not case sensitive.
:lock – Specifies whether or not the serial number is locked. This parameter has only one value, yes, which locks the serial number. Once the serial number is locked, it cannot be changed.
Note:
To enter and lock the EAGLE’s serial number, theent-serial-num command must be entered twice, once to add the correct serial number to the database with the serial parameter, then again with the serial and the lock=yes parameters to lock the serial number. You should verify that the serial number in the database is correct before locking the serial number. The serial number can be found on a label affixed to the control shelf (shelf 1100).
The chg-ctrl-feat command uses these parameters:
:partnum – The Oracle-issued part number of the SLS Bit Rotation by Incoming Linkset feature, 893026501.
:status=on – used to turn the SLS Bit Rotation by Incoming Linkset feature on.
Once the SLS Bit Rotation by Incoming Linkset feature has been turned on, it cannot be turned off.
The status of the SLS Bit Rotation by Incoming Linkset feature is shown with the rtrv-ctrl-feat command.
Figure 3-9 Activating the SLS Bit Rotation by Incoming Linkset Feature
Configuring the RSLS8 Value for ANSI Linksets
This procedure is used to configure the RSLS8 value for ANSI linksets feature using the chg-lsopts command with the lsn and rsls8 parameters.
rsls8 parameter specifies how many bits of the SLS for messages on ANSI linksets are considered for bit rotation. The rsls8 parameter of the chg-lsopts command has two values.
yes- 8 bits of the SLS are considered for bit rotation.no- 5 bits of the SLS are considered for bit rotation.
The lsn parameter specifies the name of the linkset that is being changed, specified in either Adding an SS7 Linkset or Changing an SS7 Linkset.
The rsls8 parameter can be specified only if the SLS Bit Rotation by Incoming Linkset feature is enabled. Perform Activating the SLS Bit Rotation by Incoming Linkset Feature to enable the SLS Bit Rotation by Incoming Linkset feature.
The value of the rsls8 parameter is shown in the RSLS8 column of the rtrv-ls output. The RSLS8 column is shown when the lsn parameter is specified with the rtrv-ls command, and is displayed only for ANSI linksets.
Refer to ITU SLS Enhancement for information on how the rsls8 parameter value is used with SLS bit rotation.
Figure 3-10 Configuring the RSLS8 Value for ANSI Linksets
Removing a Linkset Containing SS7 Signaling Links
This procedure is used to remove a
linkset containing
SS7
signaling links from the database using the
dlt-ls command.
The
dlt-ls command has only one
parameter,
lsn, which is the name of the
linkset to be removed from the database.
The linkset to be removed must exist in the database.
To remove a linkset, all links associated with the linkset must be removed.
The linkset to be removed cannot be referenced by a routeset.
If the Flexible Linkset Optional Based Routing feature is enabled and turned on, and the linkset is referenced by a GTT selector, the linkset cannot be removed.
To remove an IPGWx linkset, a linkset containing signaling links assigned to cards running either the SS7IPGW or IPGWI applications, the IPGWx linkset cannot be the mate of another IPGWx linkset.
A proxy linkset whose APC is assigned
to more than one proxy linkset cannot be removed if the linkset contains the
proxy point code (shown in the
PPCA/PPCI/PPCN/PPCN24 field in the
rtrv-ls:apc/apca/apci/apcn/apcn24=<APC of the
linkset> output) that is also assigned to the APC of the linkset.
The proxy point code assigned to the APC of the linkset is shown in the
rtrv-dstn:dpc/dpca/dpci/dpcn/dpcn24=<APC of
the linkset> output. The linksets that do not contain the proxy
point code that is assigned to the APC of the linkset must be removed before
the linkset containing proxy point code that is assigned to the APC of the
linkset can be removed.
Canceling the
RTRV-LS Command
Because the
rtrv-ls command used in this
procedure can output information for a long period of time, the
rtrv-ls command can be canceled
and the output to the terminal stopped. There are three ways that the
rtrv-ls command can be
canceled.
- Press the
F9function key on the keyboard at the terminal where thertrv-lscommand was entered. - Enter the
canc-cmdwithout thetrmparameter at the terminal where thertrv-lscommand was entered. - Enter the
canc-cmd:trm=<xx>, where<xx>is the terminal where thertrv-lscommand was entered, from another terminal other that the terminal where thertrv-lscommand was entered. To enter thecanc-cmd:trm=<xx>command, the terminal must allow Security Administration commands to be entered from it and the user must be allowed to enter Security Administration commands. The terminal’s permissions can be verified with thertrv-secu-trmcommand. The user’s permissions can be verified with thertrv-userorrtrv-secu-usercommands.
For more information about the
canc-cmd command, go to
Commands User's Guide.
Figure 3-11 Removing a Linkset Containing SS7 Signaling Links
Changing an SS7 Linkset
This procedure is used to change the attributes of a SS7 linksets to the EAGLE using the chg-ls command and the following parameters shown in Table 3-10.
Table 3-10 Linkset Parameters
| lsn | nlsn |
apc/apca/apci/ apcn/apcn24 |
spc/spca/spci/ spcn/spcn24 |
apcntype | lst |
| clli | sltset | l3tset | scrn | gwsa | gwsm |
| gwsd | bei | tfatcabmlq | nis | itutfr | mtprse |
| slsci | asl8 | slsrsb | slsocbit | multgc | gttmode |
| randsls | cggtmod |
islsrsb |
:lsn – The name of the linkset
:nlsn – The new name of the linkset
- The linkset name can contain up to 10 characters, with the first character being a letter. However, the SEAS interface supports only eight characters. If this linkset is displayed on the SEAS interface and the linkset name contains more than eight characters, only the first eight characters in the linkset name are shown. If this linkset name contains more than eight characters, and is specified with the linkset commands on the SEAS interface, only the first eight characters can be specified.
:apc/apca/apci/apcn/apcn24 – Adjacent point code – the point code identifying the node that is next to the EAGLE. The adjacent point code can be one of the following types of point codes:
:spc/spca/spci/spcn/spcn24 – Secondary point code used for multiple linksets that have the same APC, or the value none. If the value none is specified, the existing secondary point code that is assigned to the linkset is removed. Secondary point codes can be used only if the Multiple Linksets to Single Adjacent PC feature is enabled and turned on (shown in the rtrv-ctrl-feat output. The secondary point code can be one of the following types of point codes:
Note:
Refer to Point Code Formats for a definition of the point code types that are used on the EAGLE and for a definition of the different formats that can be used for ITU national point codes. Private point codes can be assigned only to IPGWx linksets. The procedures for configuring IPGWx linksets are in Database Administration - IP7 User's Guide.:apcntype – Specifies whether or not the linkset containing either a 14-bit ITU-N adjacent point code or a 24-bit ITU-N adjacent point code is being used in China (apcntype=itunchina) or in countries other than China (apcntype=itun). Signaling links in linksets with the apcntype=itunchina parameter are handled according to the specifications in YD/N 068-1997, Technical Specification of National No.7 Signaling System - Message Transfer Part (MTP). Signaling links in linksets with the apcntype=itun parameter are handled according to the specifications in ITU-T Q.2210 (07/96), Switching and Signaling, Broadband ISDN- Signaling Network Protocols. The default value for the apcntype parameter is itun.
- Linksets shown in section of the
rtrv-lsoutput with theLSN (CHINA)column (and with either theAPCNorAPCN24column) have theacpntype=itunchinaparameter assigned to them. - Linksets shown in section of the
rtrv-lsoutput with theLSNcolumn (and with either theAPCNorAPCN24column) have theacpntype=itunparameter assigned to them.
:lst – The linkset type of the specified linkset
:clli – The Common Language Location Identifier assigned to this point code. The value of the clli parameter is only displayed in the rtrv-ls command output when a specific linkset is being displayed with the rtrv-ls:lsn=<linkset name> command.
:sltset – The signaling link test message record to be associated with the linkset.
:l3tset – The level 3 timer set table. This parameter identifies which level three timer set is to be assigned to this linkset. Currently, only one is supported.
:scrn – The name of the screenset to be assigned to this linkset if gateway screening is to be used.
:gwsa – Gateway screening action determines whether gateway screening (GWS) is on or off for the specified link set.
:gwsm – Gateway screening messaging is used to turn on or off the display of messages generated for each screened message. When an MSU is rejected by gateway screening, a message is output to alert personnel of the event.
:gwsd – Gateway screening MSU discard is used to turn on or off the discarding of MSUs that bypass the gateway screening function due to load shedding. Also use this parameter with the redirect function; MSUs that cannot be screened are discarded if you specify gwsd=on.
:bei – The broadcast exception indicator. This parameter indicates whether TFP (transfer prohibited) messages are allowed to be broadcast on the linkset. The yes parameter means TFPs are not broadcast. The no parameter means TFPs are broadcast.
tfatcabmlq – the TFA/TCA broadcast minimum link quantity shows the minimum number of signaling links in the given link set (or in the combined link set in which it resides) that must be available for traffic. When the number of signaling links in the specified linkset is equal to or greater than the value of the tfatcabmlq parameter, the status of the routes that use the specified linkset is set to allowed and can carry traffic. Otherwise, these routes are restricted. The value of the tfatcabmlq parameter cannot exceed the total number of signaling links contained in the linkset. The system default value for the tfatcabmlq parameter is 0.
- The value of the
tfatcabmlqparameter is only displayed in thertrv-lscommand output when a specific linkset is being displayed with thertrv-ls:lsn=<linkset name>command. - The
tfatcabmlqparameter exists only in thechg-lscommand and not theent-lscommand, because no links are assigned to the linkset when the linkset is first created with theent-lscommand. The default value for thetfatcabmlqparameter (tfatcabmlq=0) is entered for the linkset, and shown in thertrv-lsoutput as 1, when a new linkset is added to the database. - When the
tfatcabmlqparameter value is 0, the EAGLE 5 ISS broadcasts TFAs/TCAs only when 1/2 of the links in the linkset (or in the combined link set in which it resides) become available. Thetfatcabmlqparameter value displayed in thertrv-lsoutput is 1/2 of the number of signaling links contained in the linkset. If the number of signaling links in the linkset is an odd number, thetfatcabmlqparameter value is rounded up to the next whole number. As signaling links are added or removed from the linkset, thetfatcabmlqparameter value will be changed automatically. - When the
lst=cparameter is specified, or when the current (unchanged)LSTvalue isC, thetfatcabmlqparameter cannot be specified unless theLSRESTRICTSS7 option ison. The state of theLSRESTRICTSS7 option is shown in thertrv-ss7optsoutput.
:nis – specifies whether the National Spare for Network Indicator feature is on or off for the specific linkset. This feature allows the linkset to use the national spare value (3) for the network indicator code field in the service information octet (SIO) of the MSU for ANSI linksets and ITU national linksets (linksets containing either 14-bit ITU-N point codes or 24-bit ITU-N point codes). This parameter cannot be specified for ITU international linksets. The default value for the nis parameter is off.
- For MSUs on incoming linksets, only those MSUs having the network indicator code values shown in Table 3-11 are allowed into the EAGLE 5 ISS.
- For MSUs on outgoing linksets, the network indicator code value in the MSU is changed to either the national network indicator code value (2) or the national spare network indicator code value (3). If the
nisparameter is set tooff, the network indicator code value is set to 2. - These actions are summarized in Table 3-11.
- The actions described for this parameter apply only if the ITU National and International Spare Point Code Support feature is not enabled.
- If the ITU National and International Spare Point Code Support feature is enabled, the
nisparameter value is ignored for ITU-I and 14-bit ITU-N linksets. All the network indicator values are permitted on ITU-I and ITU-N linksets, and the network indicator value for transmission is based on the International/National and Spare/Non-Spare status of the DPC of the message. - Having the ITU National and International Spare Point Code Support feature enabled has no effect on ANSI and 24-bit ITU-N linksets. The
nisparameter value determines which incoming network indicator spare bit values to permit, and what network indicator spare bit value should be transmitted.
Table 3-11 Actions of the National Spare for Network Indicator Feature
| Linkset Type | Feature Disabled | Feature Enabled |
|---|---|---|
|
Incoming ANSI Linkset |
MSUs containing the national network indicator code (2) are allowed into the EAGLE. |
MSUs containing these network indicator code values are allowed into the EAGLE. • National Network Indicator Code (2) • National Spare Network Indicator Code (3) |
|
Outgoing ANSI Linkset |
The network indicator code value in the MSU is set to the national network indicator code (2). |
The network indicator code value in the MSU is set to the national spare network indicator code (3). |
|
Incoming ITU National Linkset |
MSUs containing these network indicator code values are allowed into the EAGLE. • International Network Indicator Code (0) • National Network Indicator Code (2) |
MSUs containing these network indicator code values are allowed into the EAGLE. • International Network Indicator Code (0) • National Network Indicator Code (2) • National Spare Network Indicator Code (3) |
|
Outgoing ITU National Linkset |
The network indicator code value in the MSU is set to the national network indicator code (2). |
The network indicator code value in the MSU is set to the national spare network indicator code (3). |
:itutfr – specifies whether or not ITU TFR (transfer restricted) procedures are being used on the linkset. This parameter applies only to linksets with ITU national adjacent point codes (linksets containing either 14-bit ITU-N point codes or 24-bit ITU-N point codes) and can be specified only for linksets with ITU national adjacent point codes. TFR procedures are used to redirect traffic away from a node that is having problems routing traffic to a destination. When a node determines that a destination is restricted, the node sends a TFR message informing the adjacent nodes about the destination’s status. When a destination is restricted, the node should not be used to route messages to the destination even though it still has limited capability to do so. The values for this parameter are either on (ITU TFR procedures are enabled) or off (ITU TFR procedures are disabled). For more information on the itutfr parameter and ITUTFR procedures, refer to ITU TFR Procedures.
:mtprse – shows if the node adjacent to the EAGLE is equipped with the MTP restart capability. The mtprse=yes parameter can only be specified if the MTP restart feature is turned on for ANSI linksets (MTPRS = on in the rtrv-feat command output), or if the ITU MTP restart is on for ITU linksets (ITUMTPRS=on in the rtrv-feat command output). If the MTP restart feature is not turned on, the value of the mtprse parameter defaults to no. The value of the mtprse parameter value is not dependent on the value of the mtprsi parameter (the MTP restart indicator) in the chg-stpopts command. The value of the mtprse parameter is only displayed in the rtrv-ls command output when a specific linkset is being displayed with the rtrv-ls:lsn=<linkset name> command. For more information on the mtprse parameter and MTP restart, refer to Configuring the MTP Restart Feature.
:slsci – indicates whether the 5-bit to 8-bit SLS conversion feature is used to select signaling links for outgoing messages on the specified link set. If the slsci=yes parameter is specified, the EAGLE replaces any 5-bit SLS values contained in received messages with a random 8-bit value before they are used by the EAGLE to select the outgoing signaling link in that linkset. The 5-bit to 8-bit SLS conversion is also controlled by the slscnv parameter of the chg-stpopts command. The slscnv parameter of the chg-stpopts command has three values: on, off, and perls. The slsci parameter can only be specified for linksets with ANSI SS7 adjacent point codes.
:asl8 – shows if the node adjacent to the EAGLE 5 ISS is sending MSUs with 8-bit SLSs. If the asl8=yes parameter is specified with the lst=a parameter (a linkset containing access signaling links), this indicates that the originator of the MSUs is generating 8-bit SLSs. For other linkset types, the asl8=yes parameter indicates that the adjacent node is converting 5-bit SLSs to 8-bit SLSs. The SLS in MSUs received by the EAGLE on a linkset that has the asl8=yes parameter assigned to it will not be converted. These MSUs are assumed to contain 8-bit SLSs. If the asl8=no parameter is specified for the linkset, the SLS will be converted to an 8-bit SLS. The asl8 parameter can only be specified for linksets with ANSI SS7 adjacent point codes. The value of the asl8 parameter is only displayed in the rtrv-ls command output when a specific linkset is being displayed with the rtrv-ls:lsn=<linkset name> command.
For more information on the slsci and asl8 parameters and 5-bit to 8-bit conversion, refer to Configuring the 5-Bit to 8-Bit SLS Conversion Feature.
:slsrsb – selects which bit (1 - 4) of the SLS field to use as the least significant bit for signaling link selection in the link set for all ITU messages on outgoing ITU linksets.
:islsrsb – selects which bit of the SLS field, 1 - 8 for an ANSI linkset or 1 - 4 for an ITU linkset, to use as the least significant bit for signaling link selection in the link set for all messages on ANSI and ITU linksets on incoming linksets. If you wish to use the values 6, 7, or 8 for the islsrsb parameter of a ANSI linkset, the rsls8 value for the linkset must be yes. Perform Configuring the RSLS8 Value for ANSI Linksets to change the rsls8 value for the linkset to yes.
:slsocbit – selects which bit (5 - 16) of the SLS field to use as the most significant bit for signaling link selection in the link set for all ITU messages.
For more information on the slsrsb, islsrsb, and slsocbit parameters and ITU SLS enhancement, refer to ITU SLS Enhancement.
:multgc – specifies whether multiple group codes are supported for the linkset. When this parameter value is yes, secondary adjacent point codes whose group codes are different from the adjacent point code of the linkset can be assigned to the linkset. If the parameter value is no, the group code of the secondary adjacent point code must be the same as the group code of the linkset’s adjacent point code. For more information on secondary adjacent point codes, go to the Configuring an ITU Linkset with a Secondary Adjacent Point Code (SAPC) procedure.
- This parameter only applies to linksets whose adjacent point codes are either ITU international point codes or 14-bit ITU national point codes. All the signaling links in this linkset must be assigned to cards running the IPLIMI application. For more information on assigning signaling links to cards running the IPLIMI application, perform the Adding an IPLIMx Signaling Link procedure in Database Administration - IP7 User's Guide.
- The ITU duplicate point code feature must be on before this parameter can be specified. Verify this with the
rtrv-featcommand. If the ITU duplicate point code feature is turned on, theITUDUPPCfield should be set toon. If the ITU duplicate point code feature is not turned on, enter thechg-feat:ituduppc=oncommand.
Note:
Once the ITU duplicate point code feature is turned on with thechg-feat command, it cannot be turned off.
The ITU duplicate point code feature must be purchased before you turn the feature on with the chg-feat command. If you are not sure if you have purchased the ITU duplicate point code feature, contact your Oracle Sales Representative or Account Representative.
:gttmode – The GTT mode assigned to the linkset when performing global title translation on the specified linkset. The values for this parameter are:
sysdflt– the value of thedfltgttmodeparameter shown in thertrv-sccpoptscommand output.cd- CdPAGTT onlycg- CgPA GTT onlyacdcd- Advanced CdPA GTT, CdPA GTTacdcgcd- Advanced CdPA GTT, CgPA GTT, CdPA GTTacdcdcg- Advanced CdPA GTT, CdPA GTT, CgPA GTTcgacdcd- CgPA GTT, Advanced CdPA GTT, CdPA GTTcgcd- CgPA GTT, CdPA GTTcdcg- CdPA GTT, CgPA GTTfcd- Flexible Linkset Optional Based Routing (FLOBR) CdPA onlyfcg- FLOBR CgPA onlyfcdfcg- FLOBR CdPA, FLOBR CgPAfcgfcd- FLOBR CgPA, FLOBR CdPA
- For more information on using the
gttmodeparameter, refer to the Origin-Based SCCP Routing Feature section or the Flexible Linkset Optional Based Routing section in Database Administration - GTT User's Guide. - To use the values
cg,acdcd,acdcgcd,acdcdcg,cgacdcd, orcgcdfor thegttmodeparameter, the Origin-Based SCCP Routing feature must be enabled and turned on. - To use the values
fcd,fcg,fcdfcg, orfcgfcdfor thegttmodeparameter, the Flexible Linkset Optional Based Routing feature must be enabled and turned on.
:randsls – The random SLS value assigned to the linkset. This parameter is used to apply random SLS generation for the specified linkset.
randsls parameter has three values:
off– Random SLS generation is not applied to the specified linkset.class0– Random SLS generation is applied to only Class 0 SCCP messages on either incoming ANSI or outgoing ITU linksets.all– Random SLS generation is applied to both Class 0 and Class 1 SCCP messages on outgoing ITU linksets, or to Class 0 SCCP messages and ISUP messages on ANSI linksets.
For more information about random SLS generation on a specific linkset, refer to Per-Linkset Random SLS.
:cggtmod - The calling party GT modification indicator. This parameter specifies whether or not calling party global title modification is required. The values for this parameter are yes (calling party global title modification is required) or no (calling party global title modification is not required). This parameter can be specified only if the AMGTT or AMGTT CgPA Upgrade feature is enabled. Enter the rtrv-ctrl-feat command to verify that either the AMGTT or AMGTT CgPA Upgrade feature is enabled. If the AMGTT or AMGTT CgPA Upgrade feature is not enabled, perform the "Activating the Advanced GT Modification Feature" procedure in Database Administration - GTT User's Guide procedure to enable the required feature. For more information about the Advanced GT Modification feature, refer to the "Advanced GT Modification Feature" section in Database Administration - GTT User's Guide.
The EAGLE can contain 1024 linksets, with a maximum of 255 of these linksets being gateway linksets. A gateway linkset is a linkset that contains routes to a different network.
The linkset to be changed must exist in the database.
If the adjacent point code (APC) is changed, the new APC must be in the destination point code table and must be defined as a true point code in the destination point code table and cannot be an alias point code. The domain and point code type of the new APC must be the same as the APC being changed. For example, if the current adjacent point code is an ITU-I point code, the new adjacent point code must be an ITU-I point code. The new APC of the linkset cannot match the self ID of the EAGLE. The new APC must be a full point code and cannot be a cluster point code or a network routing point code.
Linksets containing E1 ATM signaling links cannot contain 24-bit ITU-N APCs or SAPCs. E1 ATM signaling links are identified by the value LIME1ATM in the TYPE column of the rtrv-ls:lsn=<linkset name> output.
The signaling link configuration of the linkset can be verified by entering the rtrv-ls:lsn=<linkset name> command.
Use the rtrv-dstn command to verify that the new APC is in the destination point code table and to verify the domain of the new APC. If the new APC is not shown in the rtrv-dstn command output, go to the Adding a Destination Point Code procedure and add the APC to the destination point code table.
To change the APC of a linkset, all signaling links in the linkset must be in the OOS-MT-DSBLD state.
The gwsa, gwsm, and gwsd parameters can only be specified if the scrn parameter is defined. Enter the rtrv-ls command to verify that the scrn parameter is defined for the specified linkset. If the scrn parameter is defined, a gateway screening screen set name is shown in the SCRN field of the output. This gateway screening screen set name must also be defined as a gateway screening screen set entity. This can be verified with the rtrv-scrset command.
Caution:
When Gateway Screening is in the screen test mode, as defined by the linkset parametersgwsa=off and gwsm=on, the gateway screening action in the gateway screening stop action set specified by the actname parameter of the gateway screening screen set at the end of the gateway screening process will be performed.
The chg-ls command has a parameter, gwsd, that can allow the discarding of messages that should have gone through the gateway screening process, but could not. The gwsd parameter is only intended to be used with the database transport access (DTA) feature. If you are not using the DTA feature, the gwsd parameter should not be specified or should be set to no (gwsd=no).
If the gwsa=off parameter is specified, then the gwsd=off parameter must be specified.
To help manage congestion on signaling links, the EAGLE starts the level 3 T31 timer whenever a signaling link goes into congestion level 1 or congestion level 2. The congestion level that is associated with the level 3 T31 timer is set using the chg-stpopts command with the mtpt31ctl parameter and is displayed with the MTPT31CTL field in the rtrv-stpopts command output. When the level 3 timer T31 and the chg-stpopts command are first introduced to the EAGLE, the system default value for the mtpt31ctl parameter of the chg-stpopts command is 1, for congestion level 1, and the system default value for the level 3 T31 timer is 60 seconds. To change the value of the level 3 T31 timer, perform Changing Level 3 Timers. To change value of the mtpt31ctl parameter, enter the either chg-stpopts:mtpt31ctl=1 or the chg-stpopts:mtpt31ctl=2 command, depending on the current value of the mtpt31ctl parameter.
To help prevent the signaling link in the linkset from oscillating in out of service, the EAGLE starts the level 3 T32 timer. When the EAGLE begins restoring an out of service signaling link, the EAGLE starts the level 3 T32 timer.If the signaling link fails again before the level 3 T32 expires, the EAGLE does not attempt to continue to bring the signaling link into service until the level 3 T32 timer expires. Once the level 3 T32 timer expires, the EAGLE attempts to restore the signaling link into service. When the level 3 timer T32 is first introduced to the EAGLE, the system default value for the level 3 T32 timer is 60 seconds. To change the value of the level 3 T32 timer, perform Changing Level 3 Timers.
The word SEAS cannot be used as a value for the scrn parameter of the chg-ls command. The word SEAS is used in the rtrv-ls command output, in the SCRN field, to show gateway linksets created on the SEAS interface. A gateway linkset combines the functions of a gateway screening screen set and an SS7 linkset specifying the gwsa=on and scrn parameters. Like an EAGLE gateway screening screen set, a gateway linkset defines the screening references that are to be used to screen the messages on the linkset. It also defines the linkset whose messages are to be screened. A gateway linkset can only be configured from a SEAS terminal and not from an EAGLE terminal.
If the clli parameter is specified with the chg-ls command, the value of the clli parameter must match the CLLI value of the adjacent point code of the linkset. The CLLI value of the adjacent point code is shown in the CLLI field of the rtrv-dstn command.
The clli parameter can only be specified with the apc or apca parameters.
If the randsls parameter of the chg-stpopts command is set to either all or class0, a maximum of 16 links continues to be supported in a single linkset to a destination. However, it is now possible to have up to 32 links in a combined linkset to a destination, with a maximum of 16 links per linkset. The 32 links is a change from the current EAGLE maximum of only 16 links per combined linkset, which is due to ITU protocol restrictions. If more than 16 links are used in a combined linkset, the operator needs to be aware that a maximum of 16 links can be used by non-Random SLS traffic over the linkset. The non-Random SLS traffic continues to operate under the rules of the ITU protocol. For more information on the Random SLS Generation feature, refer to Configuring the System for Random SLS Generation.
To provision more than one linkset with the same APC, the Multiple Linksets to Single Adjacent PC feature must be enabled and turned on. The database can contain a maximum of six linksets that have the same APC. If the linkset is not a proxy linkset (linkset types A, B, C, D, or E), a secondary point code (shown in the rtrv-spc output) must be specified with the linkset. The network type and format of the secondary point code must be the same as the APC of the linkset. Secondary point codes can also be assigned to the APC of the linkset when the point code is provisioned in the database with the ent-dstn or chg-dstn commands. The secondary point codes that are assigned to the linksets that have the same APC must be unique for each linkset and cannot be the same as the secondary point code that is assigned to the APC of the linksets.
The secondary point code that is assigned to a linkset can be removed from the linkset by specifying the value none for the spc/spca/spci/spcn/spcn24 parameter. A secondary point code can be removed from only one of the linksets in a group of linksets that have the same APC.
If the linkset is a proxy linkset (linkset type PRX), the APC and linkset type of the linkset cannot be changed. A secondary point code and a secondary adjacent point code cannot be specified for a proxy linkset.
Other Optional Parameters
chg-ls command contains other optional parameters that are not used this procedure. These parameters are discussed in more detail in Commands User's Guide or in these sections.
- Configuring an ITU Linkset with a Secondary Adjacent Point Code (SAPC)
- The "Configuring a Linkset for the GSM MAP Screening Feature" procedure in Database Administration - Features User's Guide.
- These procedures in Database Administration - IP7 User's Guide
- Configuring an IPGWx Linkset
- Adding a Mate IPGWx Linkset to another IPGWx Linkset
- Removing a Mate IPGWx Linkset from another IPGWx Linkset
- Changing an IPSG M3UA Linkset
- Changing an IPSG M2PA Linkset
- Changing an IPSG M3UA Linkset
- Changing an IPSG M2PA Linkset
The gsmscrn parameter is used for the GSM MAP Screening feature. To configure an SS7 linkset for the GSM MAP Screening feature, perform the “Configuring a Linkset for the GSM MAP Screening Feature,” in Chapter 5, “GSM MAP Screening Configuration,” in Database Administration - Features User's Guide.
The network indicator (NI) value of messages on ITU-I or ITU-N linksets can be changed to other values by entering the icnimap and ognimap parameters of the chg-lsopts command. Perform Configuring the ITU Linkset NI Mapping Options to change these values for the ITU-I or ITU-N linksets.
Canceling the RTRV-LS Command
Because the rtrv-ls command used in this procedure can output information for a long period of time, the rtrv-ls command can be canceled and the output to the terminal stopped. There are three ways that the rtrv-ls command can be canceled.
- Press the
F9function key on the keyboard at the terminal where thertrv-lscommand was entered. - Enter the
canc-cmdwithout thetrmparameter at the terminal where thertrv-lscommand was entered. - Enter the
canc-cmd:trm=<xx>, where<xx>is the terminal where thertrv-lscommand was entered, from another terminal other that the terminal where thertrv-lscommand was entered. To enter thecanc-cmd:trm=<xx>command, the terminal must allow Security Administration commands to be entered from it and the user must be allowed to enter Security Administration commands. The terminal’s permissions can be verified with thertrv-secu-trmcommand. The user’s permissions can be verified with thertrv-userorrtrv-secu-usercommands.
For more information about the canc-cmd command, go to Commands User's Guide.
Figure 3-12 Changing an SS7 Linkset
Verifying the New Adjacent Point Code or New Secondary Point Code for a Linkset
This procedure is used to verify that the new adjacent point code or new secondary point code for a linkset whose attributes are being changed is in the database.
If the linkset is a proxy linkset (linkset type PRX), the APC and linkset type of the linkset cannot be changed. A secondary point code and a secondary adjacent point code cannot be specified for a proxy linkset.
If the adjacent point code (APC) is changed, the new APC must be in the destination point code table and must be defined as a true point code in the destination point code table and cannot be an alias point code. The domain and point code type of the new APC must be the same as the APC being changed. For example, if the current adjacent point code is an ITU-I point code, the new adjacent point code must be an ITU-I point code. The new APC of the linkset cannot match the self ID of the EAGLE. The new APC must be a full point code and cannot be a cluster point code or a network routing point code.
Linksets containing E1 ATM signaling links cannot contain 24-bit ITU-N APCs or SAPCs. E1 ATM signaling links are identified by the value LIME1ATM in the TYPE column of the rtrv-ls:lsn=<linkset name> output.
Use the rtrv-dstn command to verify that the new APC is in the destination point code table and to verify the domain of the new APC. If the new APC is not shown in the rtrv-dstn command output, perform Adding a Destination Point Code to add the APC to the destination point code table.
To provision more than one linkset with the same APC, the Multiple Linksets to Single Adjacent PC feature must be enabled and turned on. The database can contain a maximum of six linksets that have the same APC. If the linkset is not a proxy linkset (linkset types A, B, C, D, or E), a secondary point code (shown in the rtrv-spc output) must be specified with the linkset. The network type and format of the secondary point code must be the same as the APC of the linkset. Secondary point codes can also be assigned to the APC of the linkset when the point code is provisioned in the database with the ent-dstn or chg-dstn commands. The secondary point codes that are assigned to the linksets that have the same APC must be unique for each linkset and cannot be the same as the secondary point code that is assigned to the APC of the linksets.
The secondary point code that is assigned to a linkset can be removed from the linkset by specifying the value none for the spc/spca/spci/spcn/spcn24 parameter. A secondary point code can be removed from only one of the linksets in a group of linksets that have the same APC.
Canceling the RTRV-LS and RTRV-DSTN Commands
Because the rtrv-ls and rtrv-dstn commands used in this procedure can output information for a long period of time, the rtrv-ls and rtrv-dstn commands can be canceled and the output to the terminal stopped. There are three ways that the rtrv-ls and rtrv-dstn commands can be canceled.
- Press the
F9function key on the keyboard at the terminal where thertrv-lsorrtrv-dstncommands were entered. - Enter the
canc-cmdwithout thetrmparameter at the terminal where thertrv-lsorrtrv-dstncommands were entered. - Enter the
canc-cmd:trm=<xx>, where<xx>is the terminal where thertrv-lsorrtrv-dstncommands were entered, from another terminal other that the terminal where thertrv-lsorrtrv-dstncommands were entered. To enter thecanc-cmd:trm=<xx>command, the terminal must allow Security Administration commands to be entered from it and the user must be allowed to enter Security Administration commands. The terminal’s permissions can be verified with thertrv-secu-trmcommand. The user’s permissions can be verified with thertrv-userorrtrv-secu-usercommands.
For more information about the canc-cmd command, go to the Commands Manual.
Figure 3-13 Verifying the New Adjacent Point Code or New Secondary Point Code for a Linkset
Using the MULTGC Parameter when Changing the Attributes of a Linkset
- The ITU Duplicate Point Code feature is turned on.
- If the
multgcparameter value is being changed tono, and the linkset contains more than one 14-bit ITU-N secondary adjacent point code, all but one of these secondary adjacent point codes must be removed from the linkset.
The multgc parameter only applies to linksets whose adjacent point codes are either ITU international point codes or 14-bit ITU national point codes. All the signaling links in this linkset must be assigned to cards running the IPLIMI or IPGWI applications, or the linkset must be an IPSG M2PA linkset. The linkset cannot be a proxy linkset.
Canceling the RTRV-LS Command
Because the rtrv-ls command used in this procedure can output information for a long period of time, the rtrv-ls command can be canceled and the output to the terminal stopped. There are three ways that the rtrv-ls command can be canceled.
- Press the
F9function key on the keyboard at the terminal where thertrv-lscommand was entered. - Enter the
canc-cmdwithout thetrmparameter at the terminal where thertrv-lscommand was entered. - Enter the
canc-cmd:trm=<xx>, where<xx>is the terminal where thertrv-lscommand was entered, from another terminal other that the terminal where thertrv-lscommand was entered. To enter thecanc-cmd:trm=<xx>command, the terminal must allow Security Administration commands to be entered from it and the user must be allowed to enter Security Administration commands. The terminal’s permissions can be verified with thertrv-secu-trmcommand. The user’s permissions can be verified with thertrv-userorrtrv-secu-usercommands.
For more information about the canc-cmd command, go to the Commands User's Guide.
Figure 3-14 Using the MULTGC Parameter when Changing the Attributes of a Linkset
Configuring an ITU Linkset with a Secondary Adjacent Point Code (SAPC)
This procedure is used to configure a secondary adjacent point code for SS7 ITU linksets using the lsn, sapci, sapcn, sapcn24, and action parameters of the chg-ls command. Only these parameters can be specified in this procedure. The chg-ls command contains other parameters.
- Changing an SS7 Linkset
- The "Configuring a Linkset for the GSM MAP Screening Feature" procedure in Database Administration - Features User's Guide.
- These procedures in Database Administration - IP7 User's Guide.
- Configuring an IPGWx Linkset
- Adding a Mate IPGWx Linkset to another IPGWx Linkset
- Removing a Mate IPGWx Linkset from another IPGWx Linkset
- Adding an IPSG M3UA Linkset
- Addingn IPSG M2PA Linkset
Note:
A secondary adjacent point code cannot be assigned to a proxy linkset. A proxy linkset is a linkset whose linkset type isPRX. A secondary adjacent point code cannot be assigned to a linkset that contains an IPSG-M3UA linkset. An IPSG-M3UA linkset is a linkset that contains the ipsg=yes and adapter=m3ua parameter values.The secondary adjacent point code is used to enhance the network management in the ITU international and ITU national nodes when messages from different countries to be routed over the same linkset.
The lsn parameter specifies the name of the linkset being changed.
The sapci parameter specifies the ITU international secondary adjacent point code.
The sapcn parameter specifies a 14-bit ITU national secondary adjacent point code.
The sapcn24 parameter specifies a 24-bit ITU national secondary adjacent point code.
The action parameter specifies whether the secondary adjacent point code (sacpi, sapcn, or sapcn24) is being added (action=add) to the linkset or removed (action=delete) from the linkset.
While the multgc parameter is not specified with the chg-ls command in this procedure, in addition to specifying whether or not multiple group codes are supported for the linkset, its value does help determine how secondary adjacent point codes are configured in the linkset.
When this parameter value is yes, and the APC of the linkset is a 14-bit ITU national point code, the linkset can contain one 14-bit ITU national secondary adjacent point code for each group code in the EAGLE, and one ITU international secondary adjacent point code. If the APC of the linkset is ITU international, the linkset can contain either one 14-bit ITU national secondary adjacent point code for each group code in the EAGLE, or only one 24-bit ITU national secondary adjacent point code, but no ITU international secondary adjacent point codes.
If the APC of the linkset is a 24-bit ITU national point code, the linkset contains only one ITU international secondary adjacent point code.
If the multgc parameter value is no, the linkset can contain only one secondary adjacent point code. An ITU international linkset can contain either a 14-bit ITU-N point code or a 24-bit ITU-N point code. An ITU national linkset, a linkset containing either a 14-bit APC or a 24-bit APC, can contain only an ITU international secondary adjacent point code.
The secondary adjacent point codes must be defined in the destination point code table and can be assigned only to linksets with ITU international or ITU national adjacent point codes, except linksets containing E1 ATM signaling links cannot contain 24-bit ITU national secondary adjacent point codes. Secondary adjacent point codes can be non-spare, spare, private, or private spare point codes. Private and private spare point codes can be specified only for IPGWI linksets (linksets containing IPGWI signaling links).
The secondary adjacent point code parameters (sacpi, sapcn, or sapcn24) and the action parameter must be specified together.
You cannot delete an SAPC with the action parameter when routes exist for its SS7 domain.
The values of the multgc, sapci, sapcn, and sapcn24 parameters are only displayed in the rtrv-ls command output when a specific linkset is being displayed with the rtrv-ls:lsn=<linkset name> command.
This examples used in this procedure are based on the information shown in Table 3-13.
Table 3-13 Secondary Adjacent Point Code Configuration Table
| Linkset Names | SAPCI | SAPCN | ACTION |
|---|---|---|---|
|
lsi3 |
N/A |
11212-ge |
add |
|
lsn5 |
4-75-7 |
N/A |
add |
|
lsn3 |
3-150-5 |
N/A |
delete |
Canceling the RTRV-LS and RTRV-DSTN Commands
Because the rtrv-ls and rtrv-dstn commands used in this procedure can output information for a long period of time, the rtrv-ls and rtrv-dstn commands can be canceled and the output to the terminal stopped. There are three ways that the rtrv-ls and rtrv-dstn commands can be canceled.
- Press the
F9function key on the keyboard at the terminal where thertrv-lsorrtrv-dstncommands were entered. - Enter the
canc-cmdwithout thetrmparameter at the terminal where thertrv-lsorrtrv-dstncommands were entered. - Enter the
canc-cmd:trm=<xx>, where<xx>is the terminal where thertrv-lsorrtrv-dstncommands were entered, from another terminal other that the terminal where thertrv-lsorrtrv-dstncommands were entered. To enter thecanc-cmd:trm=<xx>command, the terminal must allow Security Administration commands to be entered from it and the user must be allowed to enter Security Administration commands. The terminal’s permissions can be verified with thertrv-secu-trmcommand. The user’s permissions can be verified with thertrv-userorrtrv-secu-usercommands.
For more information about the canc-cmd command, go to Commands User's Guide.
Figure 3-15 Configuring an ITU Linkset with a Secondary Adjacent Point Code (SAPC)
Adding an SS7 Signaling Link
This procedure is used to add an ANSI SS7 low-speed signaling link to an MPL card using the ent-slk command with these parameters shown in Table 3-14.
Table 3-14 Signaling Link Parameters
| loc | link | lsn |
| slc | l2tset | bps |
| ecm | pcrn1 | pcrn2 |
ent-slk command contains other optional parameters that are not used this procedure. These parameters are discussed in more detail in the Commands Manual or in these sections. These sections are also used to configure ITU signaling links.- These procedures in this manual.
- The Adding an E1 Signaling Link procedure
- The Adding a T1 Signaling Link procedure
- The Adding an ATM High-Speed Signaling Link procedure.
- These procedures in Database Administration - IP7 User's Guide
- Adding an IPGWx Signaling Link
- Adding an IPLIMx Signaling Link
- Adding an IPSG M3UA Signaling Link
- Adding an IPSG M2PA Signaling Link
:loc – The card location of the LIM that the SS7 signaling link will be assigned to.
:link – The signaling link on the card specified in the loc parameter.
:lsn – The name of the linkset that will contain the signaling link.
:slc – The signaling link code. The SLC must be unique within the linkset. It must be the same at both the EAGLE location and the distant node.
:l2tset – The level 2 timer set table. A signaling link may be assigned to any of the thirty tables. The type of linkset the signaling link is assigned to and the LIM’s application determines the value of the l2tset parameter. The level 2 timer set tables are defined in Changing Level 2 Timers .
:bps – The transmission rate for the link in bits per second.
:ecm – Error correction method
:pcrn1 – The threshold of the number of MSUs available for retransmission. If the error correction method being used is PCR (:ecm=pcr), and this threshold is reached, no new MSUs or FISUs are sent. The retransmission cycle is continued up to the last MSU entered into the retransmission buffer in the order in which they were originally transmitted.
:pcrn2 – The threshold of the number of MSU octets available for retransmission. If the error correction method being used is PCR (:ecm=pcr), and this threshold is reached, no new MSUs or FISUs are sent. The retransmission cycle is continued up to the last MSU entered into the retransmission buffer in the order in which they were originally transmitted.
These items must be configured in the database before an SS7 signaling link can be added:
- Shelf – see "Adding a Shelf in Database Administration - System Management User's Guide
- Card – see "Adding an SS7 LIM" in Database Administration - System Management User's Guide
- Destination Point Code – see Adding a Destination Point Code
- Linkset – Adding an SS7 Linkset .
Verify that the link has been physically installed (all cable connections have been made).
To configure the EAGLE to perform circular routing detection test on the signaling links, perform the Configuring Circular Route Detection procedure.
Note:
Circular route detection is not supported in ITU networks.To provision a EAGLE with more than 1200 signaling links, the EAGLE must have certain levels of hardware installed. See the Requirements for EAGLEs Containing more than 1200 Signaling Links section for more information on these hardware requirements.
The EAGLE can contain a mixture of low-speed, E1, T1, ATM high-speed, and IP signaling links. The Determining the Number of High-Speed and Low-Speed Signaling Links section describes how to determine the quantities of the different types of signaling links the EAGLE can have.
SS7Signaling Link Parameter Combinations
Table 3-15 shows the parameters and values that can be used to provision an ANSI SS7 signaling link.
Table 3-15 SS7 Signaling Link Parameter Combinations
| MPL Signaling Link (See Note 1) |
|---|
|
Mandatory Parameters |
|
:loc = location of the MPL with the SS7ANSI application and the LIMDS0 card type. |
|
:link = A, A1, A2, A3, B, B1, B2, or B3 (See Note 4) |
|
:lsn = linkset name (See Note 3) |
|
:slc = 0 - 15 |
|
Optional Parameters |
|
:bps = 56000 default value = 56000 |
|
:l2tset = Table 3-16 |
|
:ecm = basic or pcr default value = basic |
|
:pcrn1 = 1 - 127 (See Note 2) default value = 76 |
|
:pcrn2 = 300 - 35500 (See Note 2) default value = 3800 |
|
Notes:
|
Canceling the REPT-STAT-SLK and RTRV-SLK Commands
Because the rept-stat-slk and rtrv-slk commands used in this procedure can output information for a long period of time, the rept-stat-slk and rtrv-slk commands can be canceled and the output to the terminal stopped. There are three ways that the rept-stat-slk and rtrv-slk commands can be canceled.
- Press the
F9function key on the keyboard at the terminal where therept-stat-slkorrtrv-slkcommands were entered. - Enter the
canc-cmdwithout thetrmparameter at the terminal where therept-stat-slkorrtrv-slkcommands were entered. - Enter the
canc-cmd:trm=<xx>, where<xx>is the terminal where therept-stat-slkorrtrv-slkcommands were entered, from another terminal other that the terminal where therept-stat-slkorrtrv-slkcommands was entered. To enter thecanc-cmd:trm=<xx>command, the terminal must allow Security Administration commands to be entered from it and the user must be allowed to enter Security Administration commands. The terminal’s permissions can be verified with thertrv-secu-trmcommand. The user’s permissions can be verified with thertrv-userorrtrv-secu-usercommands.
For more information about the canc-cmd command, go to Commands User's Guide.
Figure 3-16 Adding an SS7 Signaling Link
Removing an SS7 Signaling Link
This procedure is used to remove an SS7 low-speed, ATM, E1, E1 high-speed, or T1 signaling link from the database using the dlt-slk command. To remove other types of signaling links from the database, go to one of these procedures.
The link to be removed must exist in the database. This can be verified in 1 .
The dlt-slk command uses these parameters.
:loc – The card location of the LIM that the SS7 signaling link is assigned to.
:link – The signaling link on the card specified in the loc parameter.
:force – This parameter must be used to remove the last link in a linkset without having to remove all of the routes that referenced the linkset.
The tfatcabmlq parameter (TFA/TCA Broadcast Minimum Link Quantity), assigned to linksets, shows the minimum number of links in the given linkset (or in the combined link set in which it resides) that must be available for traffic. When the number of signaling links in the specified linkset is equal to or greater than the value of the tfatcabmlq parameter, the status of the routes that use the specified linkset is set to allowed and can carry traffic. Otherwise, these routes are restricted. The value of the tfatcabmlq parameter cannot exceed the total number of signaling links contained in the linkset.
If the linkset type of the linkset that contains the signaling link that is being removed is either A, B, D, E, or PRX, the signaling link can be removed regardless of the tfatcabmlq parameter value of the linkset and regardless of the LSRESTRICT option value. When a signaling link in one of these types of linksets is removed, the tfatcabmlq parameter value of the linkset is decreased automatically.
- If the
LSRESTRICToption is off. TheLSRESTRICToption value is shown in thertrv-ss7optsoutput. - If the
LSRESTRICToption is on and the number of signaling links assigned to the linkset will be equal to or greater than the value of thetfatcabmlqparameter value of the linkset after the signaling link is removed.The
tfatcabmlqparameter value of the linkset is shown in theTFATCABMLQcolumn of thertrv-ls:lsn=<linkset name>output. Thetfatcabmlqparameter value can be a fixed value (1 to 16) or 0. If thetfatcabmlqparameter value of the linkset is a fixed value, the number of signaling links that are in the linkset after the signaling link is removed must be equal to or greater than thetfatcabmlqparameter value of the linkset.If the
tfatcabmlqparameter value is 0, the signaling link can be removed. When thetfatcabmlqparameter value is 0, the value displayed in theTFATCABMLQcolumn of thertrv-lsoutput is 1/2 of the number of signaling links contained in the linkset. If the number of signaling links in the linkset is an odd number, thetfatcabmlqparameter value is rounded up to the next whole number. As the signaling links are removed, thetfatcabmlqparameter value of the linkset is decreased automatically.
The signaling link cannot be removed from the database if link fault sectionalization (LFS) tests are being performed on it. This can be verified using the rept-stat-lfs command.
Canceling the RTRV-SLK Command
Because the rtrv-slk command used in this procedure can output information for a long period of time, the rtrv-slk command can be canceled and the output to the terminal stopped. There are three ways that the rtrv-slk command can be canceled.
- Press the
F9function key on the keyboard at the terminal where thertrv-slkcommand was entered. - Enter the
canc-cmdwithout thetrmparameter at the terminal where thertrv-slkcommand was entered. - Enter the
canc-cmd:trm=<xx>, where<xx>is the terminal where thertrv-slkcommand was entered, from another terminal other that the terminal where thertrv-slkcommand was entered. To enter thecanc-cmd:trm=<xx>command, the terminal must allow Security Administration commands to be entered from it and the user must be allowed to enter Security Administration commands. The terminal’s permissions can be verified with thertrv-secu-trmcommand. The user’s permissions can be verified with thertrv-userorrtrv-secu-usercommands.
For more information about the canc-cmd command, go to the Commands Manual.
Figure 3-17 Removing an SS7 Signaling Link
Adding a Route Containing an SS7 DPC
This procedure is used to add a route containing an SS7 DPC to the database using the ent-rte command. The routes configured in this procedure do not contain cluster point codes as DPCs, or IPGWx linksets. These routes are configured in these procedures:
The ent-rte command uses these parameters.
:dpc/dpca/dpci/dpcn/dpcn24 – The destination point code of the node that the traffic is being sent to.
Note:
See Point Code Formats for a definition of the point code types that are used on the EAGLE and for a definition of the different formats that can be used for ITU national point codes.:lsn – The name of the linkset that will carry the traffic to the node specified by the destination point code.
:rc – The relative cost (priority) for this route.
:force – This parameter allows a route to be added to the database even if the linkset to be assigned to the route does not have any signaling links in it.
These items must be configured in the database before a route can be added in this procedure:
- Destination point code (DPC) – see one of these procedures depending on the type of point code required:
- For a Network Routing DPC – see Adding a Network Routing Point Code.
- For all other DPCs – see Adding a Destination Point Code
- Linkset – see Adding an SS7 Linkset
- Link – see Adding an SS7 Signaling Link.
The linkset assigned to this route must have an adjacent point code (APC) in the SS7 domain. The domain of the DPC is shown in the DMN field in the output of the rtrv-dstn command.
The DPC of the route must be of the same format as the APC of the linkset being added to the route. That is, routes containing ANSI DPCs must have linksets with ANSI APCs; routes containing ITU-I DPCs must have linksets with ITU-I APCs; routes containing 14-bit ITU-N DPCs must have linksets with 14-bit ITU-N APCs; routes containing 24-bit ITU-N DPCs must have linksets with 24-bit ITU-N APCs. The DPC of the route must be defined as a true point code in the rtrv-dstn output. Alias point codes and secondary point codes cannot be used. True point codes are shown in the output of the rtrv-dstn command in the DPCA, DPCI, DPCN, or DPCN24 fields. Private point codes cannot be used as the DPC of a route in this procedure. Routes that have private point codes as the DPC of a route can contain only IPGWx linksets. Perform the Adding a Route Containing an IPGWx Linkset procedure to add routes containing IPGWx linksets.
The DPC of the route is the destination point code to be reached by the route and is shown in the output of the rtrv-rte command in the DPCA, DPCI, DPCN, or DPCN24 fields.
The APCA, APCI, APCN, and APCN24 fields in the output of the rtrv-rte command show the point code of the node that is directly adjacent to the node in the route.
A linkset can only be entered once as a route for each DPC.
A maximum of six routes can be defined for each DPC.
If the 6-Way Loadsharing on Routesets feature is enabled and turned on, a maximum of six routes in the routeset can be assigned the same relative cost value. It is recommended that the routeset be provisioned with a group of four routes that have the same relative cost value and another group of two routes that have the same relative cost value. Three or five routes in the routeset that have the same relative cost value can be provisioned, but the odd number makes it more difficult to distribute the route traffic evenly. Six routes in the routeset that have the same relative cost value can be provisioned, but this does not allow for any backup routes and also offers the worst chance for congestion and queuing issues during network failures. If the 6-Way Loadsharing on Routesets feature is not enabled or not turned on, a maximum of two linksets can be assigned the same relative cost value. The relative cost value of the route is defined by the rc parameter of the ent-rte command and is shown in the RC field in the output of the rtrv-rte command.
The force=yes parameter must be specified if the specified linkset has no signaling links assigned to it. Otherwise, each linkset must have at least one signaling link assigned to it.
The ANSI DPC (DPC/DPCA) of the route can use either a full point code or a network routing point code. ITU DPCs (DPCI, DPCN, and DPCN24) must use full point codes. For more information on network routing point codes, go to the Network Routing section.
If the DPC of the route is a network routing point code, only linksets, specified with either the lsn or nlsn parameters, whose linkset type is either B, C, or D can be assigned to the route. The linkset type is shown in the LST field of the rtrv-ls command output. If the linkset type of the desired linkset is either A, E, or PRX, one of three actions must be taken.
- Choose another linkset with the linkset type B, C, or D.
- Change the linkset type of an existing linkset - perform the Changing an SS7 Linkset procedure.
- Add a new linkset to the database with the necessary signaling links and the linkset type B, C, or D.
- Perform the Adding an SS7 Linkset procedure to add the linkset.
- If the necessary signaling links are not in the database, go to the Adding an SS7 Signaling Link procedure and add the signaling links to the database.
If the DPC of the route is a member of a cluster point code, and the nested cluster allowed indicator (ncai parameter of either the ent-dstn or chg-dstn command) is set to no, then the route to the DPC must be the same as the route to the cluster point code. If the nested cluster allowed indicator is set to yes, the route to the member of the cluster does not have to be the same as the route to the cluster point code. For more information, see the Nested Cluster Routing section.
For routes containing 14-bit ITU National DPCs with group codes, if the linkset assigned to the route has the MULTGC value set to yes, then 14-bit ITU National DPCs with group codes that are different from the linkset APC group code can be assigned to the route. If the MULTGC value is set to no, then only 14-bit ITU National DPCs with group codes that are the same as the linkset APC group code can be assigned to the route.
When a new route is being added and the DPC of that route contains a proxy point code, the first route assigned to this DPC must be a linkset whose linkset type is PRX and must have a proxy point code assigned to the linkset. The proxy point code that is assigned to the linkset must be the proxy point code that is assigned to the DPC of the route. After this route has been added, other routes can be added to this DPC. The linksets for these routes can contain proxy point codes, but do not have to contain proxy point codes.
Canceling the RTRV-LS, RTRV-DSTN, and RTRV-RTE Commands
Because the rtrv-ls, rtrv-dstn, and rtrv-rte commands used in this procedure can output information for a long period of time, the rtrv-ls, rtrv-dstn, and rtrv-rte commands can be canceled and the output to the terminal stopped. There are three ways that the rtrv-ls, rtrv-dstn, and rtrv-rte commands can be canceled.
- Press the
F9function key on the keyboard at the terminal where thertrv-ls,rtrv-dstn, orrtrv-rtecommands were entered. - Enter the
canc-cmdwithout thetrmparameter at the terminal where thertrv-ls,rtrv-dstn, orrtrv-rtecommands were entered. - Enter the
canc-cmd:trm=<xx>, where<xx>is the terminal where thertrv-ls,rtrv-dstn, orrtrv-rtecommands were entered, from another terminal other that the terminal where thertrv-ls,rtrv-dstn, orrtrv-rtecommands were entered. To enter thecanc-cmd:trm=<xx>command, the terminal must allow Security Administration commands to be entered from it and the user must be allowed to enter Security Administration commands. The terminal’s permissions can be verified with thertrv-secu-trmcommand. The user’s permissions can be verified with thertrv-userorrtrv-secu-usercommands.
For more information about the canc-cmd command, go to Commands User's Guide.
Figure 3-18 Adding a Route Containing an SS7 DPC
Adding a Route Containing a Cluster Point Code
This procedure is used to add a route to the database containing a cluster point code as the DPC of the route using the ent-rte command. Routes that do not contain a cluster point code as the DPC of the route are configured in these procedures:
The ent-rte command uses these parameters.
:dpc/dpca – The destination point code (cluster point code) of the node that the traffic is being sent to.
Note:
See Point Code Formats for a definition of the point code types that are used on the EAGLE 5 ISS.:lsn – The name of the linkset that will carry the traffic to the node specified by the destination point code.
:rc – The relative cost (priority) for this route.
:force – This parameter allows a route to be added to the database even if the linkset to be assigned to the route does not have any signaling links in it.
These items must be configured in the database before a route can be added:
- Destination point code (DPC) – see Adding a Cluster Point Code
- Linkset – see Adding an SS7 Linkset
- Link – see Adding an SS7 Signaling Link
The linkset assigned to this route must have an adjacent point code (APC) in the SS7 domain. The domain of the DPC is shown in the DMN field in the output of the rtrv-dstn command.
The DPC of the route must be of the same format as the APC of the linkset being added to the route. That is, routes containing ANSI DPCs must have linksets with ANSI APCs; routes containing ITU-I DPCs must have linksets with ITU-I APCs; routes containing 14-bit ITU-N DPCs must have linksets with 14-bit ITU-N APCs; routes containing 24-bit ITU-N DPCs must have linksets with 24-bit ITU-N APCs. The DPC of the route must be defined as a true point code in the rtrv-dstn output. Alias point codes and secondary point codes cannot be used. True point codes are shown in the output of the rtrv-dstn command in the DPCA, DPCI, DPCN, or DPCN24 fields. Private point codes cannot be used as the DPC of a route in this procedure. Routes that have private point codes as the DPC of a route can contain only IPGWx linksets. Perform the Adding a Route Containing an IPGWx Linkset procedure to add routes containing IPGWx linksets.
The DPC of the route is the destination point code to be reached by the route and is shown in the output of the rtrv-rte command in the DPCA, DPCI, DPCN, or DPCN24 fields.
The APCA, APCI, APCN, and APCN24 fields in the output of the rtrv-rte command show the point code of the node that is directly adjacent to the node in the route.
A linkset can only be entered once as a route for each DPC.
A maximum of six routes can be defined for each DPC.
If the 6-Way Loadsharing on Routesets feature is enabled and turned on, a maximum of six routes in the routeset can be assigned the same relative cost value. It is recommended that the routeset be provisioned with a group of four routes that have the same relative cost value and another group of two routes that have the same relative cost value. Three or five routes in the routeset that have the same relative cost value can be provisioned, but the odd number makes it more difficult to distribute the route traffic evenly. Six routes in the routeset that have the same relative cost value can be provisioned, but this does not allow for any backup routes and also offers the worst chance for congestion and queuing issues during network failures. If the 6-Way Loadsharing on Routesets feature is not enabled or not turned on, a maximum of two linksets can be assigned the same relative cost value. The relative cost value of the route is defined by the rc parameter of the ent-rte command and is shown in the RC field in the output of the rtrv-rte command.
The force=yes parameter must be specified if the specified linkset has no signaling links assigned to it. Otherwise, each linkset must have at least one signaling link assigned to it.
If the DPC of the route is a cluster point code, only linksets whose linkset type is either B, C, or D can be assigned to the route. The linkset type is shown in the LST field of the rtrv-ls command output. If the linkset type of the desired linkset is either A, E, or PRX, one of three actions must be taken.
-
Choose another linkset with the linkset type B, C, or D.
- Change the linkset type of an existing linkset – perform the Changing an SS7 Linkset procedure.
- Add a new linkset to the database with the necessary signaling links and the linkset type B, C, or D.
- Perform the Adding an SS7 Linkset procedure to add the linkset.
- If the necessary signaling links are not in the database, perform the Adding an SS7 Signaling Link procedure to add the signaling links to the database.
Canceling the RTRV-LS, RTRV-DSTN, and RTRV-RTE Commands
Because the rtrv-ls, rtrv-dstn, and rtrv-rte commands used in this procedure can output information for a long period of time, the rtrv-ls, rtrv-dstn, and rtrv-rte commands can be canceled and the output to the terminal stopped. There are three ways that the rtrv-ls, rtrv-dstn, and rtrv-rte commands can be canceled.
-
Press the
F9function key on the keyboard at the terminal where thertrv-ls,rtrv-dstn, orrtrv-rtecommands were entered. -
Enter the
canc-cmdwithout thetrmparameter at the terminal where thertrv-ls,rtrv-dstn, orrtrv-rtecommands were entered. -
Enter the
canc-cmd:trm=<xx>, where<xx>is the terminal where thertrv-ls,rtrv-dstn, orrtrv-rtecommands were entered, from another terminal other that the terminal where thertrv-ls,rtrv-dstn, orrtrv-rtecommands were entered. To enter thecanc-cmd:trm=<xx>command, the terminal must allow Security Administration commands to be entered from it and the user must be allowed to enter Security Administration commands. The terminal’s permissions can be verified with thertrv-secu-trmcommand. The user’s permissions can be verified with thertrv-userorrtrv-secu-usercommands.
For more information about the canc-cmd command, go to the Commands Manual.
Figure 3-19 Adding a Route Containing a Cluster Point Code
Adding a Route Containing an IPGWx Linkset
This procedure is used to add a route to the database containing an IPGWx linkset using the ent-rte command. Routes that do not contain IPGWx linksets are configured in these procedures.
The ent-rte command uses these parameters.
:dpc/dpca/dpci/dpcn/dpcn24 – The destination point code of the node that the traffic is being sent to.
Note:
See Point Code Formats for a definition of the point code types that are used on the EAGLE and for a definition of the different formats that can be used for ITU national point codes.:lsn – The name of the linkset that will carry the traffic to the node specified by the destination point code.
:rc – The relative cost (priority) for this route.
:force – This parameter allows a route to be added to the database even if the linkset to be assigned to the route does not have any signaling links in it.
These items must be configured in the database before a route can be added:
- Destination point code (DPC) – see Adding a Destination Point Code. The DPC of the route can be a private point code, but does not have to be.
- Linkset – see the “Configuring an IPGWx Linkset” procedure in Database Administration - IP7 User's Guide.
- Link – see the “Adding an IPGWx Signaling Link” procedure in Database Administration - IP7 User's Guide.
The linkset assigned to this route must have an adjacent point code (APC) in the SS7 domain and must contain the ipgwapc=yes parameter value. The domain of the DPC is shown in the DMN field in the output of the rtrv-dstn command. The ipgwapc parameter value is shown in the output of the rtrv-ls:lsn=<linkset name> command.
The DPC of the route must be the APC of the linkset, or the SAPC assigned to the linkset. The DPC of the route must be of the same format as the APC of the linkset being added to the route. That is, a routes containing ANSI DPC must have a linkset with an ANSI APC; a route containing an ITU-I DPC must have a linkset with an ITU-I APC; a route containing a 14-bit ITU-N DPC must have a linkset with a 14-bit ITU-N APC; a route containing a 24-bit ITU-N DPC must have a linkset with a 24-bit ITU-N APC. The DPC of the route must be defined as a true point code in the rtrv-dstn output. Cluster point codes, network routing point codes, alias point codes, and secondary point codes cannot be used. True point codes are shown in the output of the rtrv-dstn command in the DPCA, DPCI, DPCN, or DPCN24 fields. The DPC of the route cannot be a proxy point code. A proxy point code or secondary point code cannot be assigned to the DPC of the route. A secondary point code cannot be assigned to the linkset.
For a linkset with an ITU APC, if that linkset has an SAPC assigned to it, the SAPC of that linkset can be specified as the DPC of the route. The format of the SAPC can be different from the APC of the linkset. For example, an IPGWx linkset has an ITU-I APC and an ITU-N SAPC is assigned to the linkset. The DPC of the route can be either the ITU-I APC of the linkset or the ITU-N SAPC assigned to the linkset.
The DPC of the route is the destination point code to be reached by the route and is shown in the output of the rtrv-rte command in the DPCA, DPCI, DPCN, or DPCN24 fields.
The APCA, APCI, APCN, and APCN24 fields in the output of the rtrv-rte command show the point code of the node that is directly adjacent to the node in the route.
The route containing an IPGWx linkset can contain only one linkset.
The force=yes parameter must be specified if the specified linkset has no signaling links assigned to it. Otherwise, each linkset must have at least one signaling link assigned to it.
If the DPC of the route is a member of a cluster point code, and the nested cluster allowed indicator (ncai parameter of either the ent-dstn or chg-dstn command) is set to no, then the route to the DPC must be the same as the route to the cluster point code. If the nested cluster allowed indicator is set to yes, the route to the member of the cluster does not have to be the same as the route to the cluster point code. For more information, see the Nested Cluster Routing section.
For routes containing 14-bit ITU National DPCs with group codes, if the linkset assigned to the route has the MULTGC value set to yes, then 14-bit ITU National DPCs with group codes that are different from the linkset APC group code can be assigned to the route. If the MULTGC value is set to no, then only 14-bit ITU National DPCs with group codes that are the same as the linkset APC group code can be assigned to the route.
Canceling the RTRV-LS, RTRV-DSTN, and RTRV-RTE Commands
Because the rtrv-ls, rtrv-dstn, and rtrv-rte commands used in this procedure can output information for a long period of time, the rtrv-ls, rtrv-dstn, and rtrv-rte commands can be canceled and the output to the terminal stopped. There are three ways that the rtrv-ls, rtrv-dstn, and rtrv-rte commands can be canceled.
- Press the
F9function key on the keyboard at the terminal where thertrv-ls,rtrv-dstn, orrtrv-rtecommands were entered. - Enter the
canc-cmdwithout thetrmparameter at the terminal where thertrv-ls,rtrv-dstn, orrtrv-rtecommands were entered. - Enter the
canc-cmd:trm=<xx>, where<xx>is the terminal where thertrv-ls,rtrv-dstn, orrtrv-rtecommands were entered, from another terminal other that the terminal where thertrv-ls,rtrv-dstn, orrtrv-rtecommands were entered. To enter thecanc-cmd:trm=<xx>command, the terminal must allow Security Administration commands to be entered from it and the user must be allowed to enter Security Administration commands. The terminal’s permissions can be verified with thertrv-secu-trmcommand. The user’s permissions can be verified with thertrv-userorrtrv-secu-usercommands.
For more information about the canc-cmd command, go to Commands User's Guide.
Figure 3-20 Adding a Route Containing an IPGWx Linkset
Removing a Route
This procedure is used to remove a route from the database using the dlt-rte command.
The dlt-rte command uses these parameters.
:dpc/dpca/dpci/dpcn/dpcn24 – The destination point code of the node shown in the rtrv-rte output.
Note:
See Point Code Formats for a definition of the point code types that are used on the EAGLE and for a definition of the different formats that can be used for ITU national point codes.:lsn – The name of the linkset that carries the traffic bound for the node specified by the destination point code.
:all – Are all routes associated with the DPC to be removed
The route to be removed must exist in the database. This can be verified in 1.
The last route to a DPC cannot be removed if it is reference by a mated application or concerned signaling point code group. If this condition exists, the command to remove the route from the database is rejected. Before removing the last route to a DPC from the database, enter the rtrv-cspc and rtrv-map commands to verify if the DPC to the route being removed from the database is referenced by either mated applications or concerned signaling point code groups. If rtrv-cspc command output shows a reference to the DPC of the route being removed by this procedure (in the PCA, PCI, PCN, or PCN24 fields), perform the "Removing Concerned Signaling Point Codes" procedure in Database Administration – GTT User's Guide. If the rtrv-map command output shows a reference to the DPC of the route being removed by this procedure (shown in the PCA, PCI, PCN, or PCN24 fields), perform the "Removing a Mated Application" procedure in Database Administration – GTT User's Guide.
The last route to a DPC cannot be removed if it is referenced by a route exception table entry. Use the rtrv-rtx command with the DPC value to display the route exception entries that reference the DPC of the route being removed. If route exception table entries reference the DPC of the route being removed, perform the Removing a Route Exception Entry procedure to remove the route exception table entries that reference the DPC of the route being removed.
The last route to a DPCdestination (Route DPC) cannot be removed if that route is referenced by the gateway screening redirect function’s DPC parameter. Use the rtrv-gws-redirect command to verify the DPC used for the gateway screening redirect function. If the gateway screening redirect function is referencing the destination of the route to be removed from the database, change the gateway screening redirect function’s DPC with the "Changing the Gateway Screening Redirect Parameters" procedures in Database Administration – Features User's Guide. The gateway screening redirect function can also be disabled by using the "Disabling the Gateway Screening Redirect Function" procedure in Database Administration – Features User's Guide.
The last route to a DPC cannot be removed if is referenced in the rtrv-pct output as either a REALPC or FILTPC value. Perform the Removing a Point Code and CIC Translation Entry procedure to remove the point code and CIC entries that reference the DPC of the route.
Either the lsn or all=yes parameters must be specified with the dlt-rte command. If the all=no parameter is specified, the lsn parameter must be specified. If the lsn parameter is specified, the linkset must be defined in the database as a route to the specified route DPC. The linkset name is shown in the LSN field of the rtrv-rte command output.
The route assigned to a full point code DPC cannot be removed from the database if that DPC is a member of a cluster point code in the database if the network cluster allowed indicator (ncai parameter of either the ent-dstn or chg-dstn command) is set to no. If the nested cluster allowed indicator is set to yes, the route to the full point code DPC that is a member of a cluster point code can be removed from the database, but the route to the cluster point code will not be removed from the database, even if the cluster point code and the full point code are assigned to the same route. When the route to the member of the cluster point code is removed from the database, the member of the cluster point code assumes all the attributes of the cluster point code and will use the same routes that are assigned to the cluster point code.
If a route assigned to a cluster point code is removed from the database, all routes to any members of that cluster are also removed from the database if the network cluster allowed indicator is set to no. If the nested cluster allowed indicator is set to yes, the route to the cluster point code can be removed from the database, but any routes to any point codes that are members of the cluster point code remain in the database, even if the cluster point code and its members are assigned to the same route. For more information, refer to the Nested Cluster Routing section.
The destination point code of the route being removed from the database cannot be in the mated relay node (MRN) table. Verify this by entering the rtrv-mrn command, specifying the destination point code of the route being removed from the database. If the destination point code of the route is shown in the rtrv-mrn command output, remove the point code from the MRN table, by performing the "Removing an MRN Group or MRN Group Entry" procedure in Database Administration – GTT User's Guide.
The destination point code of the route being removed from the database cannot be referenced by a global title translation entry shown in the rtrv-gtt or rtrv-gta outputs. Verify this by entering the rtrv-gtt or rtrv-gta command, specifying the destination point code of the route being removed from the database. If the destination point code of the route is shown in the rtrv-gtt output, remove the global title translation entry by performing the "Removing a Global Title Translation" procedure in Database Administration – GTT User's Guide. If the destination point code of the route is shown in the rtrv-gta output, remove the global title translation entry by performing the "Removing Global Title Address Information" procedure in Database Administration – GTT User's Guide.
The destination point code of the route being removed from the database cannot be shown in the rtrv-ppsopts output. Verify this by entering the rtrv-ppsopts command. Any references to the destination point code the rtrv-ppsopts output are removed in 12.
If the APC of the linkset assigned to the route being removed is the same as the DPC of the route, this route cannot be removed if a proxy point code is assigned to the DPC of the route, and the linkset assigned to this route contains these attributes:
- The LST=PRX parameter value
- The proxy point code that is assigned to the DPC of the route is also assigned to the linkset.
If the DPC of the route contains a proxy point code and the linkset contains the value PRX for the linkset type (LST) and the proxy point code value assigned to the route DPC, and there are other routes assigned to this DPC, the other routes to this DPC must be removed before this route can be removed with the dlt-rte command.
The examples in this procedure are used to remove all routes to DPC 003-003-003 from the database.
Canceling the RTRV-RTE Command
Because the rtrv-rte command used in this procedure can output information for a long period of time, the rtrv-rte command can be canceled and the output to the terminal stopped. There are three ways that the rtrv-rte command can be canceled.
- Press the
F9function key on the keyboard at the terminal where thertrv-rtecommand was entered. - Enter the
canc-cmdwithout thetrmparameter at the terminal where thertrv-rtecommand was entered. - Enter the
canc-cmd:trm=<xx>, where<xx>is the terminal where thertrv-rtecommand was entered, from another terminal other that the terminal where thertrv-rtecommand was entered. To enter thecanc-cmd:trm=<xx>command, the terminal must allow Security Administration commands to be entered from it and the user must be allowed to enter Security Administration commands. The terminal’s permissions can be verified with thertrv-secu-trmcommand. The user’s permissions can be verified with thertrv-userorrtrv-secu-usercommands.
For more information about the canc-cmd command, go to Commands User's Guide.
Figure 3-21 Removing a Route
Changing a Route
This procedure is used to change the relative cost of a route or the linkset assigned to a route in the database using the chg-rte command.
The chg-rte command uses these parameters.
:dpc/dpca/dpci/dpcn/dpcn24 – The destination point code of the node that the traffic is bound for.
Note:
See Point Code Formats for a definition of the point code types that are used on the EAGLE and for a definition of the different formats that can be used for ITU national point codes.:lsn – The name of the linkset that is currently assigned to the route.
:rc – The relative cost (priority) for this route.
:nlsn – The name of the new linkset that will carry the traffic bound for the node specified by the destination point code.
The route to be changed must exist in the database. This can be verified in 1.
If the DPC of the route being changed is a private point code, or if the ipgwapc parameter of the linkset assigned to the route is yes, the route is an IPGWx route (a route that contains an IPGWx linkset). The IPGWx route can contain only one linkset. The DPC of an IPGWx route must either be the APC of the IPGWx linkset or the SAPC assigned to the IPGWx linkset. The DPC of the route cannot be changed. The SAPC can be assigned to only one linkset. As a result, the linkset assigned to the IPGWx route cannot be changed. Only the rc parameter value assigned to the route can be changed.
The examples in this procedure are used to change the relative cost assigned to the linkset ls01 for the route to DPC 003-003-003 in the database to change the name of linkset ls01 to lsa2.
Changing Routes Other than IPGWx Routes
If the 6-Way Loadsharing on Routesets feature is enabled and turned on, a maximum of six routes in the routeset can be assigned the same relative cost value. It is recommended that the routeset be provisioned with a group of four routes that have the same relative cost value and another group of two routes that have the same relative cost value. Three or five routes in the routeset that have the same relative cost value can be provisioned, but the odd number makes it more difficult to distribute the route traffic evenly. Six routes in the routeset that have the same relative cost value can be provisioned, but this does not allow for any backup routes and also offers the worst chance for congestion and queuing issues during network failures. If the 6-Way Loadsharing on Routesets feature is not enabled or not turned on, a maximum of two linksets can be assigned the same relative cost value. The relative cost value of the route is defined by the rc parameter of the chg-rte command and is shown in the RC field in the output of the rtrv-rte command.
The ANSI DPC (DPC/DPCA) of the route can use either a full point code, a cluster point code, or a network routing point code. ITU DPCs (DPCI and DPCN - 14-bit or 24-bit DPCNs) must use full point codes. For more information on full and cluster point codes, go to the Cluster Routing and Management Diversity (CRMD) section. For more information on network routing point codes, go to the Network Routing section.
The DPC of the route must be of the same format as the APC of the linkset being added to the route. That is, routes containing ANSI DPCs must have linksets with ANSI APCs; routes containing ITU-I DPCs must have linksets with ITU-I APCs; routes containing 14-bit ITU-N DPCs must have linksets with 14-bit ITU-N APCs; routes containing 24-bit ITU-N DPCs must have linksets with 24-bit ITU-N APCs. The DPC of the route must be defined as a true point code in the rtrv-dstn output. Alias point codes and secondary point codes cannot be used. True point codes are shown in the output of the rtrv-dstn command in the DPCA, DPCI, DPCN, or DPCN24 fields.
Either the nlsn or rc parameters, or both, must be specified with the chg-rte command. If neither of these parameters are specified, the command is rejected.
The linkset specified by the nlsn parameter must be in the database and must contain at least one signaling link. This can be verified with the rtrv-ls command and specifying the name of the linkset with the lsn parameter.
If the DPC of the route is a cluster point code or a network routing point code, only linksets, specified with either the lsn or nlsn parameters, whose linkset type is either B, C, or D can be assigned to the route. The linkset type is shown in the LST field of the rtrv-ls command output. If the linkset type of the desired linkset is either A, E, or PRX, one of three actions must be taken.
- Choose another linkset with the linkset type B, C, or D.
- Change the linkset type of an existing linkset – perform the Changing an SS7 Linkset procedure.
- Add a new linkset to the database with the necessary signaling links and the linkset type B, C, or D.
- Perform the Adding an SS7 Linkset procedure to add the linkset.
- If the necessary signaling links are not in the database, go to the Adding an SS7 Signaling Link procedure and add the signaling links to the database.
If the DPC of the route is a member of a cluster point code, and the nested cluster allowed indicator (ncai parameter of either the ent-dstn or chg-dstn command) is set to no, then all destinations in the cluster have the same route as the cluster point code, with the same attributes as the route to the cluster point code. If the nested cluster allowed indicator is set to yes, then the routes to the members of the cluster point code, and the attributes of these routes, can be different from the route to the cluster point code. For more information, see the Nested Cluster Routing section.
If the APC of the linkset assigned to the route and the DPC of the route are the same, the name of the linkset cannot be changed in this procedure if the linkset and the DPC of the route contain these attributes.
- The DPC of the route contains a proxy point code.
- The linkset type of the linkset is PRX (a proxy linkset) and the proxy point code that is assigned to the DPC of the route is also assigned to the linkset.
These attributes can be verified by entering the rtrv-dstn command with the DPC of the route and the rtrv-ls command with the linkset name assigned to the route. If these attributes are present and you wish to change the name of the linkset, perform the Removing a Route procedure to remove the linkset from the DPC of the route. To remove a proxy linkset from the DPC of the route, all the linksets assigned to the DPC must be removed. After the linksets have been removed from the DPC, Add the new linkset to the DPC of the route by performing the Adding a Route Containing an SS7 DPC procedure.
Canceling the RTRV-LS and RTRV-RTE Commands
Because the rtrv-ls and rtrv-rte commands used in this procedure can output information for a long period of time, the rtrv-ls and rtrv-rte commands can be canceled and the output to the terminal stopped. There are three ways that the rtrv-ls and rtrv-rte commands can be canceled.
- Press the
F9function key on the keyboard at the terminal where thertrv-lsorrtrv-rtecommands were entered. - Enter the
canc-cmdwithout thetrmparameter at the terminal where thertrv-lsorrtrv-rtecommands were entered. - Enter the
canc-cmd:trm=<xx>, where<xx>is the terminal where thertrv-lsorrtrv-rtecommands were entered, from another terminal other that the terminal where thertrv-lsorrtrv-rtecommands were entered. To enter thecanc-cmd:trm=<xx>command, the terminal must allow Security Administration commands to be entered from it and the user must be allowed to enter Security Administration commands. The terminal’s permissions can be verified with thertrv-secu-trmcommand. The user’s permissions can be verified with thertrv-userorrtrv-secu-usercommands.
For more information about the canc-cmd command, go to Commands User's Guide.
Figure 3-22 Changing a Route
Changing Level 2 Timers
This procedure is used to change the
values of a level 2 timer set using the
chg-l2t command.
The
l2tset parameter specifies the
level 2 timer set that is being changed. The
EAGLE contains
35 level 2 timer sets that signaling links can
be assigned to. Level 2 timer sets are assigned to different types of signaling
links as shown in
Table 3-16.
Table 3-16 Level 2 Timer Sets
| Level 2 Timer Set (l2tset Parameter Value) | Default Level 2 Timer Set Value for Signaling Links | Type of Signaling Link |
|---|---|---|
|
1 - 10 |
1 |
Low-speed ANSI signaling links |
|
11 - 20 |
11 |
Low-speed ITU signaling links |
|
21 - 25 |
21 |
ITU-N high-speed signaling links for China |
|
26 - 30 |
26 |
ITU-N high-speed signaling links for areas other than China |
| 31 - 35 |
31 |
Unchannelized T1 high-speed signaling links |
Table 3-17 Level 2 Timer Values - Low-Speed ANSI Signaling Links
| Level 2 Timers | Level 2 Timer Sets 1 - 10 (in milliseconds) |
|---|---|
|
Timer 1 – Aligned ready ( |
5000 - 20000 System Default - 13000 |
|
Timer 2 – Not aligned ( |
5000 - 30000 System Default - 11500 |
|
Timer 3 – Aligned ( |
5000 - 20000 System Default - 11500 |
|
Timer 4 – Normal proving period ( |
500 - 5000 System Default - 2300 |
|
Timer 4 – Emergency proving period
( |
200 - 1000 System Default - 600 |
|
Timer 5 – Sending
SIB ( |
40 - 500 System Default - 100 |
|
Timer 6 – Remote congestion ( |
1000 - 10000 System Default - 4000 |
|
Timer 7 – Excessive delay of acknowledgment
( |
200 - 3000 System Default - 1500 |
| NODATA - See the Notes. |
100 - 500 System Default - 100 |
|
Notes:
|
|
Table 3-18 Level 2 Timer Values - Low-Speed ITU Signaling Links
| Level 2 Timers | Level 2 Timer Sets 11 - 20 (in milliseconds) |
|---|---|
|
Timer 1 – Aligned ready ( |
40000 - 50000 System Default - 40000 |
|
Timer 2 – Not aligned ( |
5000 - 150000 System Default - 30000 |
|
Timer 3 – Aligned ( |
1000 - 2000 System Default - 2000 |
|
Timer 4 – Normal proving period ( |
7500 - 9500 System Default - 8200 |
|
Timer 4 – Emergency proving period
( |
400 - 600 System Default - 500 |
|
Timer 5 – Sending
SIB ( |
80 - 120 System Default - 100 |
|
Timer 6 – Remote congestion ( |
3000 - 6000 System Default - 4000 |
|
Timer 7 – Excessive delay of acknowledgment
( |
500 - 2000 System Default - 1500 |
| NODATA - See the Notes. |
100 - 500 System Default - 100 |
|
Notes:
|
|
Table 3-19 Level 2 Timer Values - ITU-N High-Speed Signaling Links for China
| Level 2 Timers | Level 2 Timer Sets 21 - 25 (in milliseconds) |
|---|---|
|
Timer 1 – Aligned ready ( |
25000 - 350000 System Default - 150000 |
|
Timer 2 – Not aligned ( |
5000 - 150000 System Default - 130000 |
|
Timer 3 – Aligned ( |
1000 - 2000 System Default - 1000 |
|
Timer 4 – Normal proving period ( |
3000 - 70000 System Default - 30000 |
|
Timer 4 – Emergency proving period
( |
400 - 600 System Default - 500 |
|
Timer 5 – Sending
SIB ( |
80 - 120 System Default - 100 |
|
Timer 6 – Remote congestion ( |
3000 - 6000 System Default - 5000 |
|
Timer 7 – Excessive delay of acknowledgment
( |
500 - 2000 System Default - 800 |
Table 3-20 Level 2 Timer Values - ITU-N High-Speed Signaling Links for Areas other than China
| Level 2 Timers | Level 2 Timer Sets 26 - 30 (in milliseconds) |
|---|---|
|
Timer 1 – Aligned ready ( |
25000 - 350000 System Default - 300000 |
|
Timer 2 – Not aligned ( |
5000 - 150000 System Default - 130000 |
|
Timer 3 – Aligned ( |
1000 - 2000 System Default - 1000 |
|
Timer 4 – Normal proving period ( |
3000 - 70000 System Default - 30000 |
|
Timer 4 – Emergency proving period
( |
400 - 600 System Default - 500 |
|
Timer 5 – Sending
SIB ( |
80 - 120 System Default - 100 |
|
Timer 6 – Remote congestion ( |
3000 - 6000 System Default - 5000 |
|
Timer 7 – Excessive delay of acknowledgment
( |
500 - 2000 System Default - 800 |
Table 3-21 Level 2 Timer Values - Unchannelized T1 High-Speed Signaling Links
| Level 2 Timers | Level 2 Timer Sets 31- 35 (in milliseconds) |
|---|---|
|
Timer 1 – Aligned ready ( |
16000 - 151000 System Default - 151000 |
|
Timer 2 – Not aligned ( |
5000 - 14000 System Default - 14000 |
|
Timer 3 – Aligned ( |
5000 - 14000 System Default - 14000 |
|
Timer 4 – Normal proving period ( |
3000 - 30000 System Default - 30000 |
|
Timer 4 – Emergency proving period
( |
3000 - 10000 System Default - 3000 |
|
Timer 5 – Sending
SIB ( |
80 - 120 System Default - 80 |
|
Timer 6 – Remote congestion ( |
3000 - 6000 System Default - 3000 |
|
Timer 7 – Excessive delay of acknowledgment
( |
500 - 2000 System Default - 500 |
The examples in this procedure are used to change the values of the level 2 timer set number 2.
Figure 3-23 Changing Level 2 Timers
Changing Level 3 Timers
This procedure is used to change the values of the level 3 timers using the chg-l3t command. The level 3 timers apply to both ANSI and ITU linksets, except as noted for the specific timer.
Note:
Only one level 3 timer set exists.The level 3 timers are defined as follows:
:t1 – Timer 1 – Delay to avoid message mis-sequencing on changeover. Values - 100-2000 milliseconds; system default value - 800 milliseconds.
:t2 – Timer 2 – Waiting for changeover acknowledgment. Values - 100-3000 milliseconds; system default value - 1400 milliseconds.
:t3 – Timer 3 – Time controlled diversion – delay to avoid mis-sequencing on changeback. Values - 100 - 2000 milliseconds; system default value - 800 milliseconds.
:t4 – Timer 4 – Waiting for changeback acknowledgment (1st attempt). Values - 100-2000 milliseconds; system default value - 800 milliseconds.
:t5 – Timer 5 – Waiting for changeback acknowledgment (2nd attempt). Values - 100-2000 milliseconds; system default value - 800 milliseconds.
:t6 – Timer 6 – Delay to avoid message mis-sequencing on controlled rerouting. Values - 100-2000 milliseconds; system default values - 800 milliseconds. If the 6-Way Loadsharing on Routesets feature is enabled and turned on, it is recommended that the value for this timer is set to 100 milliseconds. Enter the rtrv-ctrl-feat:partnum=893019801 command to verify the status of the 6-Way Loadsharing on Routesets feature.
:t7 – Timer 7 – Waiting for signaling data link connection acknowledgment. Values - 100-3000 milliseconds; system default value - 1000 milliseconds.
:t8 – Timer 8 – Transfer-prohibited (TFP) inhibited timer (transient solution). Values - 500-2000 milliseconds; system default value - 800 milliseconds.
:t10 – Timer 10 – Waiting to repeat signaling-route-set-test (SRST) message. Values - 20000-90000 milliseconds; system default value - 30000 milliseconds.
:t11 – Timer 11 – Transfer-restricted timer. Values - 1000-90000 milliseconds; system default - 30000 milliseconds.
:t12 – Timer 12 – Waiting for uninhibit acknowledgment. Values - 100-2000 milliseconds; system default value - 800 milliseconds.
:t13 – Timer 13 – Waiting for force uninhibit. Values - 100-2000 milliseconds; system default value - 800 milliseconds.
:t14 – Timer 14 – Waiting for inhibition acknowledgment. Values - 200-4000 milliseconds; system default value - 2000 milliseconds.
:t15 – Timer 15 – Waiting to repeat signaling route set congestion test (RSCT). Values - 200-4000 milliseconds; system default value - 3000 milliseconds.
:t16 – Timer 16 – Waiting for route set congestion (RSC) status update. Values - 200-3000 milliseconds; system default value - 1400 milliseconds.
:t17 – Timer 17 – Delay to avoid oscillation of initial alignment failure and link restart. Values - 500-2000 milliseconds; system default value - 800 milliseconds.
:t18 – Timer 18 – ANSI linksets – Repeat TFR once by response method. Values - 2000-20000 milliseconds; system default value - 10000 milliseconds.
:it18 – Timer 18 – ITU linksets – Timer within a signaling point whose MTP restarts to supervise the receipt of routing information and activation of the link and linkset. Values - 19000-50000 milliseconds; system default value - 50000 milliseconds.
:t19 – Timer 19 – ANSI linksets – Failed link craft referral timer. Values - 30000-600000 milliseconds; system default value - 480000 milliseconds.
:it19 – Timer 19 – ITU linksets – Supervision timer during MTP restart to avoid ping of TFP, TFR1, and TRA messages. Values - 67000-69000 milliseconds; system default value - 67000 milliseconds.
:t20 – Timer 20 – ANSI linksets – Waiting to repeat local inhibit test. The value of the t20 parameter overwrites the value of the it22 parameter. Values - 90000-120000 milliseconds; system default value - 90000 milliseconds.
:it20 – Timer 20 – ITU linksets – Overall MTP restart timer at the signaling point whose MTP restarts. Values - 59000-61000 milliseconds; system default value - 59000 milliseconds.
:it20 – Timer 20 – ITU linksets – Waiting to repeat local inhibit test (it22 parameter). Values - 59000-61000 milliseconds; system default value - 59000 milliseconds.
:t21 – Timer 21 – ANSI linksets – Waiting to repeat remote inhibit test. The value of the t21 parameter overwrites the value of the it23 parameter. Values - 90000-120000 milliseconds; system default value - 90000 milliseconds.
:it21 – Timer 21 – ITU linksets – Overall MTP restart timer at a signaling point adjacent to one whose MTP restarts. Values - 63000-65000 milliseconds; system default value - 63000 milliseconds.
:t22 – Timer 22 – ANSI linksets – the amount of time the restarting node waits for the signaling links to become available. This parameter is used when the MTP restart feature is turned on. Values - 10000-60000 milliseconds; system default value - 10000 milliseconds.
:it22 – Timer 22 – ITU linksets – Waiting to repeat local inhibit test. The value of the it22 parameter overwrites the value of the t20 parameter. Values - 180000-360000 milliseconds; system default value - 90000 milliseconds.
:t23 – Timer 23 – ANSI linksets – the amount of time the restarting node waits to receive the TRA message. This parameter is used when the MTP restart feature is turned on. Values - 9000-100000 milliseconds; system default value - 10000 milliseconds.
:it23 – Timer 23 – ITU linksets – Waiting to repeat remote inhibit test. The value of the it23 parameter overwrites the value of the t21 parameter. Values - 180000-360000 milliseconds; system default value - 90000 milliseconds.
:t24 – Timer 24 – ANSI linksets – the amount of time the restarting node waits to broadcast all TRA messages. This parameter is used when the MTP restart feature is turned on. Values - 9000-60000 milliseconds; system default value - 10000 milliseconds.
:t25 – Timer 25 – ANSI linksets – the amount of time the adjacent node waits for the TRA message. This parameter is used when the MTP restart feature is turned on. Values - 30000-35000 milliseconds; system default value - 30000 milliseconds.
:t26 – Timer 26 – ANSI linksets – the amount of time the restarting node waits to repeat the TRW message. This parameter is used when the MTP restart feature is turned on. Values - 12000-15000 milliseconds; system default value - 12000 milliseconds.
:t28 – Timer 28 – ANSI linksets – the amount of time the adjacent node waits for the TRW message. This parameter is used when the MTP restart feature is turned on. Values - 3000-35000 milliseconds; system default value - 3000 milliseconds.
:t29 – Timer 29 – ANSI linksets – this timer is started when a TRA message is sent in response to an unexpected TRA/TRW message or when the MTP restart process has completed. Any TRA/TRW messages received while the T29 timer is running are ignored. This parameter is used when the MTP restart feature is turned on. Values - 60000-65000 milliseconds; system default value - 60000 milliseconds.
:t30 – Timer 30 – ANSI linksets – the amount of time between sending TFPs/TFRs in response to an unexpected TRA/TRW message. This parameter is used when the MTP restart feature is turned on. Values - 30000-35000 milliseconds; system default values - 30000 milliseconds.
:t31 – Timer 31 – ANSI linksets – False link congestion detection timer. Values - 10000-120000 milliseconds; system default value - 60000 milliseconds.
:t32 –Timer 32 – Link oscillation timer - Procedure A. Values - 60000-120000 milliseconds; system default values - 60000 milliseconds.
It is possible that a problem on a signaling link can cause one signaling link in a linkset to go into congestion, even though the traffic on the linkset is not high enough to cause congestion. For example, if a link has a large number of retransmissions, the throughput of the signaling link could drop enough to cause congestion on that signaling link. To help prevent this from happening, the EAGLE starts the level 3 T31 timer whenever a signaling link goes into congestion. If the signaling link remains in the same congestion state until the level 3 T31 timer expires, the signaling link is removed from service. The signaling link becomes unaligned, then the alignment procedure is started.
The congestion level that starts the level 3 T31 timer can be set to either congestion level 1 or congestion level 2 using the chg-stpopts command with the mtpt31ctl parameter. This congestion level can be verified with the rtrv-stpopts command and is shown in the MTPT31CTL field. The level 3 T31 timer is started when the signaling link reaches this congestion level or a higher level. An increase in congestion level or abatement to a lower congestion level restarts the timer. When the congestion level goes below the congestion level configured in the chg-stpopts command, the level 3 T31 timer is stopped. If the level 3 T31 timer expires and the signaling link’s congestion level has not changed, the signaling link is restarted.
For example, if the level 3 T31 timer is set at 60 seconds and a signaling link goes into congestion level 1, the level 3 T31 timer is started. If, after 45 seconds, the signaling link’s congestion increases to level 2, the timer is restarted to 60 seconds. If the signaling link remains at congestion level 2 for 60 seconds, the signaling link is taken out of service and it becomes unaligned. Then the alignment procedure is started, and the EAGLE attempts to realign the signaling link. The level 3 T31 timer can only be assigned to ANSI SS7 linksets and signaling links.
The level 3 T32 timer helps to prevent a signaling link from oscillating in and out of service. When the EAGLE begins restoring an out of service signaling link, the EAGLE starts the level 3 T32 timer. If the signaling link fails again before the level 3 T32 expires, the EAGLE does not attempt to continue to bring the signaling link into service until the level 3 T32 timer expires. Once the level 3 T32 timer expires, the EAGLE attempts to restore the signaling link into service.
The level 3 T32 timer is only started after a signaling link fails, not when a signaling link is manually deactivated. When a signaling link is manually taken out of service using the dact-slk command, the level 3 T32 timer is stopped, if it is running. When the signaling link is brought back into service using the act-slk command, the level 3 T32 timer is not started. The level 3 T32 timer is not started when a new signaling link is first aligned.
The l3tset parameter specifies the level 3 timer set. For any level 3 timer parameters not specified with the chg-l3t command, the values for those parameters are not changed.
Figure 3-24 Changing Level 3 Timers
Changing a Signaling Link Test Message
This procedure is used to change an SLTM (signaling link test message) using the chg-slt command.
The chg-slt command uses these parameters.
:sltset – The signaling link test message record number in the SLTM table.
:t1 – The T1 timer for repeating the SLTM after a failure
:t2 – The T2 timer for the SLTM period
:enabled – Enables the signaling link test message.
:mode – The SLTM mode to be used when sending test messages.
:pattern – The test pattern to be sent with a signaling link test message.
Figure 3-25 Changing a Signaling Link Test Message
Configuring Circular Route Detection
Note:
Circular route detection is not supported in ITU networks.This procedure is used to configure the EAGLE to detect circular routing with the chg-stpopts command. The chg-stpopts command uses these parameters to detect circular routing in the EAGLE.
:on=mtplti - to turn on the circular routing detection feature.
:off=mtplti - to turn off the circular routing detection feature.
:mtpltctdpcq – the number of DPCs that the circular route test message is sent to.
:mtpltst – the duration of the circular route test detection procedures, in milliseconds (the MTPLTST timer).
These parameters are optional. For any parameters not specified with the chg-stpopts command, the values for these parameters are not changed.
When the on=mtplti parameter is specified for the chg-stpopts command, the value yes is shown in the MTPLTI field of the rtrv-stpopts output. When the off=mtplti parameter is specified for the chg-stpopts command, the value no is shown in the MTPLTI field of the rtrv-stpopts output.
rtrv-stpopts output, for these parameters are:
- MTPLTI - yes
- MTPLTCTDPCQ - 3
- MTPLTST - 10000.
For this example, the circular route detection procedures remain enabled, the number of most frequently occurring DPCs is changed from 3 to 6, and the duration of the circular route detection procedures is changed from 10000 milliseconds to 18000 milliseconds.
The EAGLE automatically tests for circular routing when congestion occurs on an ANSI signaling link. The circular route detection test cannot be performed for ITU signaling links. If the routing data is configured incorrectly, or is corrupted, MSUs could be routed in an endless circular route. The incorrect routing data could be on the EAGLE or at a remote node. 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 LIM that contains 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 sent the most MSUs. The number of DPCs that the circular route test message is sent to is from 3 to 10. 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 MTPLTST timer expires, the EAGLE performs these 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 destination 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, an UAM 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.
If an x-list entry needs to be created, but the provisioned number of x-lists are already used, extra buffer space, equal to 100 entries in the routing table, is used to create the x-list. If this extra buffer space is also full, no x-list is created, a UAM is generated, and a critical alarm is raised for the cluster.
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. Each route used by the point code that is not used by the cluster assumes the status of the cluster’s route set. 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.
If Circular Route Auto-Recovery is enabled and turned on, and circular routing because of far-end loopback is detected, the status of the destination marked as prohibited is automatically cleared. Refer to the Activating the Circular Route Auto-Recovery Feature procedure for more information.
Figure 3-26 Configuring Circular Route Detection
Configuring the TFA/TFR Pacing Rate
Note:
The pacing rate feature is not supported in ITU networks.This procedure is used to configure the rate that the EAGLE sends the TFR and TFA messages, or the pacing rate. The pacing rate is configured with the tfatfrpr parameter of the chg-stpopts command. The value of the tfatfrpr parameter is from 0 to 1 second and can be set in 0.1 second intervals. When the chg-stpopts command is first introduced to the EAGLE, the default value for the tfatfrpr parameter is 1 second. A value of 0 for the tfatfrpr parameter indicates that the pacing should stop. The pacing of TFR/TCR is stopped and all remaining TFR/TCR are broadcast at once if the current alternate route used to route traffic to the affected point code is in danger of congestion. The value of the tfatfrpr parameter in the chg-stpopts command is entered and displayed in the rtrv-stpopts command output in milliseconds.
For this example, the TFA/TFR pacing rate is changed from 1 second to 0.5 seconds (1000 milliseconds to 500 milliseconds).
When the status of the route is changed to allowed (when the route was restricted) or restricted (when the route was prohibited), a burst of rerouted traffic can occur on that route, thus congesting the route. To help keep this from happening, the EAGLE can control the rate that it broadcasts TFR and TFA messages to adjacent signaling points. This can regulate the amount of traffic the adjacent signaling points can send to the EAGLE when the route becomes allowed or restricted.
The TFA/TCA and TFR/TCR messages for each affected point code are sent in groups of 20%. For each time period defined by the pacing rate, a group of 20% of the messages that are to be sent to the adjacent signaling points are broadcast to those signaling points.
This feature applies only to ANSI signaling links. The pacing is not done toward ITU networks.
If the destination becomes inaccessible or accessible before all of the TFR/TCR messages are broadcasted, then the remaining TFR/TCR messages are not sent.
TFA/TFC messages for multiple affected destinations are sent in parallel.
Figure 3-27 Configuring the TFA/TFR Pacing Rate
Configuring the Frequency of RST Messages on Low Priority Routes
This procedure is used to configure the frequency that signaling-route-set-test messages are sent for routes of lower priority than the current route. The frequency is configured with these parameters of the chg-stpopts command.
:on=mtplprst - to turn on the routeset test message for lower priority routes capability. The EAGLE sends routeset test messages at intervals specified by the value of the mtpt10alt parameter.
:off=mtplprst - to turn off the routeset test message for lower priority routes capability. The EAGLE does not send routeset test messages for the lower priority routes.
:mtpt10alt – the timer to control the frequency that the routeset test messages are sent. The values for this parameter are from 20000 to 10,000,000 milliseconds (20 - 10,000 seconds).
The value of the mtpt10alt parameter must be equal to or greater than the value of the level 3 T10 timer.
When the on=mtplprst parameter is specified for the chg-stpopts command, the value yes is shown in the MTPLPRST field of the rtrv-stpopts output. When the off=mtplprst parameter is specified for the chg-stpopts command, the value no is shown in the MTPLPRST field of the rtrv-stpopts output.
rtrv-stpopts output, for these parameters are:
- MTPLPRST - yes
- MTPT10ALT - equal to the value of the level 3 T10 timer. The value of the level 3 T10 timer is shown in the
T10field of thertrv-l3tcommand output
If the Origin-Based MTP Routing feature is enabled and turned on, the off=mtplprst parameter cannot be specified with the chg-stpopts command. The status of the Origin-Based MTP Routing feature is shown in the rtrv-ctrl-feat command output.
These parameters of the chg-stpopts command are optional. For any parameters not specified with the chg-stpopts command, the values for these parameters are not changed.
For this example, the sending the signaling-route-set-test messages for the low priority routes is turned on, and the frequency of sending these messages is changed from 30,000 milliseconds to 120,000 milliseconds (30 seconds to 120 seconds).
Figure 3-28 Configuring the Frequency of RST Messages on Low Priority Routes
Adding Remote Loopback Points
This procedure is used to add remote loopback points to be used by the link fault sectionalization feature to the database, using the ent-lbp command. The ent-lbp command uses these parameters.
:loc – The card location of the signaling link to be tested.
:link – The signaling link on the card specified in the loc parameter to be tested.
:lbp – Identifies the far-end loopback point that lies along a SS7 signaling link path between the EAGLE up to and including the target device.
:clli – The CLLI code or other mnemonic identifier used to describe the specified loopback point.
:rle – The remote link element to be looped back for testing.
:rep – The number of link elements of the same type, not including the target device, that lies between the EAGLE and the link element to be tested.
:lfst – The type of link fault sectionalization loopback test to be performed.
To add remote loopback points to the database, the link fault sectionalization feature must be turned on.
The DS0 and network element interface (NEI) link elements do not support non-latching loopbacks
If the remote link element to be tested is a network element interface (NEI), the value of the rep parameter must be zero.
The rep parameter can only be specified for a link fault sectionalization latching loopback test
The signaling link being tested can be assigned to one of these card types as defined by the type parameter of the ent-card command:
-
limds0(multi-port LIM - P/N 870-2061-XX -
limt1(E1/T1 MIM - P/N 870-2198-XX, HC MIM - P/N 870-2671-XX, or E5-E1T1 - P/N 870-1873-XX) -
limch(E1/T1 MIM - configured as a T1 channel card - P/N 870-2198-XX)
Any signaling link can be selected for testing, as long as the signaling link being tested is equipped. The LIMs must be assigned to either the ss7ansi or ccs7itu application. Use the rtrv-card command to verify the card type and the application.
The specified loopback point cannot already be in the database.
The loopback point ID value cannot exceed a previously defined network element interface loopback point value.
Only one network element interface loopback point can be defined for each SS7 signaling link.
A network element interface (NEI) loopback point must be defined as the terminating SS7 signaling link component.
The value specified for the rep parameter must be greater than the value of the rep parameter assigned to the previous loopback point and less than any rep parameter values for any subsequent loopback points, if any are defined. For example, the signaling link on card 1215, link B, has 5 loopback points defined (see the rtrv-lbp command output in step 2). The value of the rep parameter used for loopback point 5 must be greater that the rep parameter value used for loopback point 3, and less than the rep parameter value used for loopback point 7.
The link fault sectionalization feature must be turned on. Verify this by entering the rtrv-feat command. If the link fault sectionalization feature is off, shown by the entry LFS = off in the output of the rtrv-feat command, it can be turned on by entering the chg-feat:lfs=on command.
Note:
Once the link fault sectionalization feature is turned on with thechg-feat command, it cannot be turned off.
The link fault sectionalization feature must be purchased before you turn the feature on with the chg-feat command. If you are not sure if you have purchased the link fault sectionalization feature, contact your Oracle Sales Representative or Account Representative.
Refer to Appendix A of Commands User's Guide for a summary of loopback testing commands and functions.
The examples used in this procedure are based on the example network shown in Table 3-22.
Table 3-22 Loopback Point Configuration Table
| SLK LOC | SLK LINK | LBP | RLE | REP | LFST |
|---|---|---|---|---|---|
|
1204 |
B |
3 |
DS0 |
0 |
LLT |
|
6 |
DS0 |
4 |
LLT |
||
|
9 |
NEI |
0 |
LLT |
Canceling the RTRV-SLK Command
Because the rtrv-slk command used in this procedure can output information for a long period of time, the rtrv-slk command can be canceled and the output to the terminal stopped. There are three ways that the rtrv-slk command can be canceled.
- Press the
F9function key on the keyboard at the terminal where thertrv-slkcommand was entered. - Enter the
canc-cmdwithout thetrmparameter at the terminal where thertrv-slkcommand was entered. - Enter the
canc-cmd:trm=<xx>, where<xx>is the terminal where thertrv-slkcommand was entered, from another terminal other that the terminal where thertrv-slkcommand was entered. To enter thecanc-cmd:trm=<xx>command, the terminal must allow Security Administration commands to be entered from it and the user must be allowed to enter Security Administration commands. The terminal’s permissions can be verified with thertrv-secu-trmcommand. The user’s permissions can be verified with thertrv-userorrtrv-secu-usercommands.
For more information about the canc-cmd command, go to Commands User's Guide.
Figure 3-29 Adding Remote Loopback Points
Removing Remote Loopback Points
This procedure is used to remove remote loopback points used by the link fault sectionalization feature from the database, using the dlt-lbp command. The dlt-lbp command uses these parameters.
:loc – The card location of the signaling link to be tested.
:link – The signaling link on the card specified in the loc parameter.
:lbp – Identifies the far-end loopback point that lies along a SS7 signaling link path between the EAGLE 5 ISS up to and including the target device.
:all – Are all loopback points for the specified signaling link to be removed
The specified loopback point must be in the database.
Either the lbp or all parameters must be specified, but not both.
This examples used in this procedure are used to remove the remote loopback point 5 on the signaling link assigned to card 1215, link B.
Figure 3-30 Removing Remote Loopback Points
Changing Remote Loopback Points
This procedure is used to change the values of the remote loopback points to be used by the link fault sectionalization feature in the database, using the chg-lbp command. The chg-lbp command uses these parameters.
:loc – The card location of the signaling link to be tested.
:link – The signaling link on the card specified in the loc parameter.
:lbp – Identifies the far-end loopback point that lies along a SS7 signaling link path between the EAGLE up to and including the target device.
:clli – The CLLI code or other mnemonic identifier used to describe the specified loopback point.
:rle – The remote link element to be looped back for testing.
:rep – The number of link elements of the same type, not including the target device, that lies between the EAGLE and the link element to be tested.
:lfst – The type of link fault sectionalization loopback test to be performed.
The DS0 and network element interface (NEI) link elements do not support non-latching loopbacks.
If the remote link element to be tested is a network element interface (NEI), the value of the rep parameter must be zero.
The rep parameter can only be specified for a link fault sectionalization latching loopback test.
The specified loopback point must be in the database.
The loopback point ID value cannot exceed a previously defined network element interface loopback point value.
Only one network element interface loopback point can be defined for each SS7 signaling link.
A network element interface (NEI) loopback point must be defined as the terminating SS7 signaling link component.
The value specified for the rep parameter must be greater than the value of the rep parameter assigned to the previous loopback point and less than any rep parameter values for any subsequent loopback points, if any are defined. For example, the signaling link on card 1215, link B, has 5 loopback points defined (see the rtrv-lbp command output in step 1). The value of the rep parameter used for loopback point 5 must be greater that the rep parameter value used for loopback point 3, and less than the rep parameter value used for loopback point 7.
Refer to Appendix A of Commands User's Guide for a summary of loopback testing commands and functions.
Figure 3-31 Changing Remote Loopback Points
Configuring the System for Random SLS Generation
The Random SLS Generation feature can alleviate problems of the EAGLE not load-sharing between all links within a linkset. This feature is available for both ITU and ANSI traffic.
The ITU protocol uses a 4 bit Signaling Link Selection (SLS) field with no modification of SLS values by intermediate nodes and a one-to-one mapping of SLS values to signaling links. These rules can be overly restrictive in situations where they are not necessary.
For both ITU and ANSI, the feature allows the user to have the EAGLE ignore the incoming SLS value and randomly generate a new 8-bit SLS value to select an outgoing linkset and a link. For ITU only, the original 4-bit SLS value is not changed and is still contained in the outgoing message. The newly generated SLS is used for link selection only. For ANSI, the original SLS value in the outgoing MSU can be replaced with the SLS value generated by the feature. This is done by appropriately setting SS7OPTS:SLSREPLACE parameter.
Messages destined for a particular destination are randomly distributed across all the links to that destination using an internally generated random 8-bit SLS. This means that this feature does not follow the ITU protocol requiring that all messages with the same SLS value must use the same signaling link. Also, correct sequencing of Class 1 messages is not guaranteed. Random SLS generation applies to all Class 0 and Class 1 SCCP messages.
This feature is implemented with one of these values for the randsls parameter of the chg-stpopts command.
-
class0– Applies the Random SLS feature to Class 0 ITU SCCP messages and associated service. For example, Random SLS Generation would apply to Class 0 UDT, XUDT, and UDTS, XUDTS messages. Class 1 messages would still use the standard ITU method for link selection. -
all– Applies the Random SLS feature to all ITU SCCP messages -
off– Turns off the Random SLS feature. -
perls– Applies the Random SLS feature on a specific linkset instead of applying the Random SLS feature system-wide. To use the randsls with ANSI, the value for randsls must be specified as perls. For more information about random SLS generation on a specific linkset, refer to Per-Linkset Random SLS.Caution:
If therandslsparameter value of thechg-stpoptscommand isall, thus activating the Random SLS feature for Class 1 ITUSCCP messages, and the value of theclass1seqparameter of thechg-sccpoptscommand ison, there is no guarantee that UDT/XUDTITU Class 1 messages are delivered to the remote node in the order in which they were received. To ensure that Class 1 UDT/XUDTITU messages are delivered to the remote node in the order in which they were received, therandslsparameter value should be set to eitherofforclass0if the value of theclass1seqparameter of thechg-sccpoptscommand ison.
For ITU linksets, this feature is available as a system-wide option as well as on a per-linkset basis. For ANSI linksets, this feature is available only on a per-linkset basis. The Random SLS feature is applied to incoming messages on ITU linksets as shown in Table 3-23.
Table 3-23 ITU Random SLS Rules
| System-Wide RANDSLS Value (in the RTRV-STPOPTS Output) | RANDSLS Value for the Outgoing Linkset | Random SLS Action |
|---|---|---|
| OFF | N/A | The Random SLS feature is not applied on any ITU message. |
| ALL | N/A | The Random SLS feature is applied on all ITU SCCP messages. |
| CLASS0 | N/A | The Random SLS feature is applied on all ITU SCCP CLASS0 messages. |
| PERLS | OFF | The Random SLS feature is not applied on any ITU message on the specified linkset. |
| PERLS | ALL | The Random SLS feature is applied on all ITU SCCP messages on the specified linkset. |
| PERLS | CLASS0 | The Random SLS feature is applied on all ITU SCCP CLASS0 messages on the specified linkset. |
The Random SLS feature is applied to incoming messages on ANSI linksets as shown in Table 3-24.
Table 3-24 ANSI Random SLS Rules
| System-Wide RANDSLS Value (in the RTRV-STPOPTS Output) | RANDSLS Value for the Incoming Linkset | Random SLS Action |
|---|---|---|
| OFF | N/A | The Random SLS feature is not applied on any ANSI message. |
| ALL | N/A | The Random SLS feature is not applied on any ANSI message. |
| CLASS0 | N/A | The Random SLS feature is not applied on any ANSI message. |
| PERLS | OFF | The Random SLS feature is not applied on any ANSI message on the specified linkset. |
| PERLS | ALL | The Random SLS feature is applied on ANSI SCCP and ISUP messages on the specified linkset. |
| PERLS | CLASS0 | The Random SLS feature is applied on all ANSI SCCP CLASS0 messages on the specified linkset. |
The settings for this feature are independent of the ITU SLS Enhancement feature settings for individual linksets. These settings are defined by the slsocbit (Use of the Other CIC BIT capability) and slsrsb (SLS Bit Rotation capability) parameters of the ent-ls and chg-ls commands. The randsls parameter, however, overrides the slsrsb parameter for SCCP messages. If the randsls parameter value is perls, the randsls parameter also overrides the islsrsb (SLS Bit Rotation on Incoming Linksets) parameter of the ent-ls and chg-ls commands for Class 0 SCCP messages and ISUP messages on ANSI linksets. These parameters are described in greater detail in Commands User's Guide and in ITU SLS Enhancement. Note that the ent-ls or chg-ls commands do not prevent the user from provisioning the slsrsb or islsrsb parameters.
With the implementation of this feature, a maximum of 16 links continues to be supported in a single linkset to a destination. However, it is now possible to have up to 32 links in a combined linkset to a destination, with a maximum of 16 links per linkset. The 32 links is a change from the current EAGLE maximum of only 16 links per combined linkset, which is due to ITU protocol restrictions. If more than 16 links are used in a combined linkset, the operator needs to be aware that a maximum of 16 links can be used by non-Random SLS traffic over the linkset. The non-Random SLS traffic continues to operate under the rules of the ITU protocol.
Figure 3-32 shows an example of a combined linkset from node A to nodes B and C, with 8 links per linkset. Since 8 bits allows for values 0-255 (decimal), the figure shows how these values are internally mapped to the links of the combined linkset. For ease of reading, not all values are shown.
Figure 3-32 Random SLS Mapping to a Combined Linkset
Figure 3-33 shows the mapping for a 4-link single linkset between nodes D and E. When an MSU is to be transmitted, a random 8 bit SLS is generated internally and a link is selected according to this predetermined mapping.
Figure 3-33 Random SLS Mapping to a Single Linkset
The 4 bit SLS in the outgoing message is equal to the SLS that the EAGLE received. There is no change to the SLS value in the SS7 message.
In a non-failure condition, the process for mapping the internally generated SLS values to SLC (Signaling Link Code) values for specific links is as follows:
- A “random” 8-bit SLS value is generated. In reality, a single table of 256 unique SLS values, initially generated in random order, exists in the EAGLE. A counter is maintained for each linkset in the EAGLE that causes the linkset to cycle through the random values in the table as messages are routed out on that linkset. For a combined linkset, the counter for the first linkset in the EAGLE's linkset table is used.
- For a combined linkset, the first bit is used to select the linkset and then is ignored when selecting the SLC. For a single linkset, the first bit is used when selecting the SLC. In all cases, the fifth bit is ignored when selecting the SLC. This is due to internal ANSI-based processing in the EAGLE.
- The changed SLS value (with fifth and possibly also first bits ignored) is then divided by the number of links in the linkset (not a combined linkset) and the remainder gives the SLC value. For example, in Figure 3-32, the SLS value 78 is mapped to SLC 7 in linkset LS1 as follows:
- The binary equivalent for decimal number 78 is 01001110.
- The fifth bit is ignored leaving the binary number 0101110.
- The least significant bit is used to select linkset LS1 and is then ignored, leaving the binary number 010111.
- The decimal equivalent of the binary number 010111 is 23. When the number 23 is divided by the number of links in the linkset, in this example, eight, a remainder of seven remains, thus SLC 7 on linkset LS1 is chosen for the outgoing message.
In the example shown in Figure 3-33, the SLS value 78 is mapped to SLC 2 in LS1 (the only linkset) as follows:
- The binary equivalent for decimal number 78 is 01001110.
- The fifth bit is ignored leaving the binary number 0101110.
- The decimal equivalent of the binary number 0101110 is 46. When the number 46 is divided by the number of links in the linkset, in this example, four, a remainder of two remains, thus SLC 2 on linkset LS1 is chosen for the outgoing message.
Table 3-25 shows the mapping for a combined linkset with 16 links in each linkset. This table is discussed in more detail in the next section.
Link failure scenarios
In any situation where a link is failed, SLS values that were mapped to that link are remapped to other links of the linkset or combined linkset. This is done in the reverse order that the SLS values were originally mapped to links, of course skipping the failed link. Subsequent link failures will have their SLS values, along with SLS values from the prior failures, remapped in the same way. The odd/even mapping rule for combined linksets does not apply to the remapped SLS values under failure conditions. This is to continue to achieve the best possible load balance across all links. No MSUs should be discarded in any case.
For example, Table 3-25 shows how the internal 8-bit SLS values are distributed for a combined linkset with 16 links per linkset. It also shows what happens when one or two of the links fail. As this example shows, the SLS values that are identical after the fifth bit is dropped (for example, 0 and 16, 192 and 208, etc.) are remapped to the same link. This is why in this example the 8 different SLS values from the first failed link are remapped to only 4 links and not 8.
Table 3-25 Failure Scenarios for a 32-Link Combined Linkset
| Linkset/SLC | Normal SLS Mapping | SLS Mapping for Single Link Failure | SLS Mapping for Dual Link Failure |
|---|---|---|---|
|
LS1/0 |
0 16 64 80 128 144 192 208 |
Failed |
Failed |
|
LS1/1 |
2 18 66 82 130 146 194 210 |
Same as Normal SLS Mapping |
Same as Normal SLS Mapping |
|
LS1/7 |
14 30 78 94 142 158 206 222 |
Same as Normal SLS Mapping |
Same as Normal SLS Mapping |
|
LS1/8 |
32 48 96 112 160 176 224 240 |
Same as Normal SLS Mapping |
Same as Normal SLS Mapping |
|
LS1/9 |
34 50 98 114 162 178 226 242 |
Same as Normal SLS Mapping |
Same as Normal SLS Mapping |
|
LS1/12 |
40 56 104 120 168 184 232 248 |
Same as Normal SLS Mapping |
40 56 … 248 225 241 |
|
LS1/13 |
42 58 106 122 170 186 234 250 |
Same as Normal SLS Mapping |
42 58 … 250 161 177 |
|
LS1/14 |
44 60 108 124 172 188 236 252 |
44 60 … 252 192 208 |
44 60 … 252 97 113 |
|
LS1/15 |
46 62 110 126 174 190 238 254 |
46 62 … 254 64 80 |
46 62 … 254 33 49 |
|
LS2/0 |
1 17 65 81 129 145 193 208 |
Same as Normal SLS Mapping |
Same as Normal SLS Mapping |
|
LS2/7 |
15 31 79 95 143 159 207 223 |
Same as Normal SLS Mapping |
Same as Normal SLS Mapping |
|
LS2/8 |
33 49 97 113 161 177 225 241 |
Same as Normal SLS Mapping |
Failed |
|
LS2/12 |
41 57 105 121 169 185 233 249 |
Same as Normal SLS Mapping |
41 57 … 249 192 208 |
|
LS2/13 |
43 59 107 123 171 187 235 251 |
Same as Normal SLS Mapping |
43 59 … 251 128 144 |
|
LS2/14 |
45 61 109 125 173 189 237 253 |
45 61 … 253 128 144 |
45 61 … 253 64 80 |
|
LS2/15 |
47 63 111 127 175 191 239 255 |
47 63 … 255 0 16 |
47 63 … 255 0 16 |
Because of the large number of internal SLS values being remapped across the relatively small number of links, traffic is essentially evenly distributed across the remaining links. This is true in all cases, regardless of the original number of links or the number of failed links.
Figure 3-34 Configuring the System for Random SLS Generation
Configuring the Options for the TDM Global Timing Interface
This procedure is used to configure the options for the TDM Global Timing Interface using the chg-clkopts command with the following parameters.
:clock - the clock that is being updated. This parameter has three values.
primary- the primary clocksecondary- the secondary clockall- both the primary and secondary clocks
:hsclksrc – the source of the high-speed master clock.
rs422– T1 (1544 KHz) or E1 (2048 KHz) RS-422 clock interfacet1framed– T1 framed clocking as defined in ANSIT1.101, Synchronization Interface Standard, 1999.t1unframed– T1 unframed clocking as defined in ANSIT1.102, Digital Hierarchy Electrical Signals, 1987.e1framed– E1 framed clocking as defined in section 9 of ITU-T Recommendation G.703, Physical/Electrical Characteristics of Hierarchical Digital Interfaces, October 1998.e1unframed– E1 unframed clocking as defined in section 13 of ITU-T Recommendation G.703, Physical/Electrical Characteristics of Hierarchical Digital Interfaces, October 1998.
:hsclkll – sets the gain of the LIU (line interface unit) of the TDM when the hsclksrc parameter value is either t1framed, t1unframed, e1framed, or e1unframed.
longhaul– high gain for the LIUshorthaul– low gain for the LIU
Caution:
Changing these options changes the external master clock source for all E1, T1, ANSIATM, or E1ATM high-speed signaling links using external timing.:force - allows the hsclksrc parameter to be changed if the status of the high-speed clocks is valid. The force parameter must be specified when the EAGLE contains valid high-speed clocks. The force parameter can be specified only if the hsclksrc parameter is specified. The force parameter has only one value - yes. The status of the high-speed clocks is shown by the rept-stat-clk command.
When the EAGLE is delivered to the user, the values of the hsclksrc and hsclkll parameters are set to these values:
hsclksrc–rs422hsclkll–longhaul
Either of these values can be changed only if the part number of both TDMs in card locations 1114 and 1116 is 870-0774-15 or later. If the part numbers of the TDMs are not correct, the TDMs with the incorrect part numbers must be replaced with TDM part number 870-0774-15 or later. If the TDM is being replaced with the E5-TDMs, the GPSM-II cards in card locations 1113 and 1115 and the TDMs in card locations 1114 and 1116 must be replaced with E5-MASP cards.
Caution:
Contact the Customer Care Center, Refer to My Oracle Support (MOS) for the contact information, before replacing the TDMs.If the EAGLE does not contain LIMDS0 cards, but contains TDM part numbers 870-0774-15 or later, the clock source for the TSC (Time Slot Counter) synchronization feature used by the EAGLE 5 Integrated Monitoring Support feature can be generated from the high-speed master clock source. An external BITS clock is not required.
If an external BITS clock is connected to a EAGLE without LIMDS0 cards, but with TDM part numbers 870-0774-15 or later, the external BITS clock is used as the clock source for the TSC (Time Slot Counter) synchronization feature. If the external BITS clock fails, the clock source for the TSC synchronization feature is generated from the high-speed master clock source.
If LIMDS0 cards are present in the EAGLE, the external BITS clock is required for timing of the DS0 signaling links and for TSC (Time Slot Counter) synchronization used by the Integrated Sentinel . If the EAGLE also contains TDM part numbers 870-0774-15 or later along with the LIMDS0 cards, this procedure can be used to select the source of the high-speed master clock for the high-speed links using external timing. The high-speed master clock source cannot be used to generate the clock source for any low-speed links and for the TSC (Time Slot Counter) synchronization feature.
Figure 3-35 Configuring the Options for the TDM Global Timing Interface
Configuring the Restricted Linkset Option
This procedure is used to configure the restricted linkset option using the chg-ss7opts command with the lsrestrict parameter. The lsrestrict parameter has two values:
When a large linkset (a linkset containing more than three links) first becomes available, there may not be enough available links to carry the normal amount of traffic on the linkset. The EAGLE sends response method TFA/TFRs when the number of links within a linkset, specified by the tfatcabmlq parameter for that linkset, are active and available to carry traffic. This was designed to prevent congestion on the newly available linksets. Internally in the EAGLE, if a single link within a lower cost route is active, the EAGLE attempts to route traffic over the lower cost route. If no traffic or small amounts of traffic are arriving due to the issuance of a TFR, then no congestion should occur.
However, this behavior applies only to traffic destined for remote nodes and not to traffic destined for the EAGLE itself. Typically, messages that are global title routed are destined for the EAGLE's true, secondary or capability point code. The existing congestion prevention mechanism does not prevent traffic destined for EAGLE to be controlled by the linkset’s tfatcabmlq parameter. This is because TFx messages have an affected point code field that is the far end destination point code and not the EAGLE's point code, so traffic destined for EAGLE continues to arrive for the restricted destination. It is not feasible to place EAGLE's point code in the affected destination field as this would affect all traffic destined for EAGLE and not just traffic over a specific route.
With the lsrestrict=off option, the EAGLE continues to route traffic in this manner.
The lsrestrict=on option enhances the EAGLE’s existing behavior of the linkset’s tfatcabmlq parameter and allow the state of the route combined with the cost value of the route to determine the preferred route to use.
Turning the lsrestrict option on changes the way the EAGLE routes messages by using the state of the route along with the cost of the route to determine the preferred route to use. With this option on, the preferred route is not the absolute lowest cost available route in the routeset. A route is considered available if its status is either Allowed or Restricted. If the state of the absolute lowest cost route in the routeset is Restricted, the preferred route is the lowest cost route in the routeset whose status is Allowed. Make sure that you wish to have the EAGLE route messages in this manner before turning the lsrestrict option on.
In previous releases, a C linkset's tfatcabmlq parameter is not configurable and set to 1 (the linkset is allowed when the first link is available). This is because the C linkset is designed for message trafficking between the mate STP's and would allow these messages to be transferred as soon as the first link in the C linkset was available. The lsrestrict=on option allows the tfatcabmlq parameter value for a C linkset to be from 0 to 16, just as any other linkset.
With the lsrestrict=off option, the tfatcabmlq parameter value for a C linkset is set to 1 and cannot be changed.
When a linkset that was previously prohibited becomes restricted (that is, the number of links that became available is less than the required number of links as specified by the linkset’s tfatcabmlq parameter) the following events occur when the lsrestrict option is on:
- The EAGLE 5 ISS does not broadcast TFAs.
- Point codes that were previously prohibited and use the linkset as a lower cost route are marked restricted. The EAGLE continues to broadcast TFRs.
- Point codes that were previously restricted and use the linkset as a least cost route remain restricted. The EAGLE does not broadcast any TFx message. For these point codes, RSRT will respond to RSP messages with a TFR, and will not respond to RSR messages.
- The EAGLE marks the linkset as restricted.
- If a higher cost route is available, the EAGLE routes the traffic over the higher cost route.
Once the required number of links are available for the linkset, the following events occur when the lsrestrict option is on:
- The EAGLE marks the previously prohibited/restricted point codes as allowed that use the linkset as a lower cost route (unless the point code's nonadjacent status is prohibited).
- The EAGLE does not broadcast TFAs for the newly allowed point codes, but responds to RSR/RSP messages with a TFA.
- The EAGLE marks the linkset as allowed. The appropriate changeback procedures are performed and traffic is processed normally.
Canceling the RTRV-LS Command
Because the rtrv-ls command used in this procedure can output information for a long period of time, the rtrv-ls command can be canceled and the output to the terminal stopped. There are three ways that the rtrv-ls command can be canceled.
- Press the
F9function key on the keyboard at the terminal where thertrv-lscommand was entered. - Enter the
canc-cmdwithout thetrmparameter at the terminal where thertrv-lscommand was entered. - Enter the
canc-cmd:trm=<xx>, where<xx>is the terminal where thertrv-lscommand was entered, from another terminal other that the terminal where thertrv-lscommand was entered. To enter thecanc-cmd:trm=<xx>command, the terminal must allow Security Administration commands to be entered from it and the user must be allowed to enter Security Administration commands. The terminal’s permissions can be verified with thertrv-secu-trmcommand. The user’s permissions can be verified with thertrv-userorrtrv-secu-usercommands.
For more information about the canc-cmd command, go to Commands User's Guide.
Figure 3-36 Configuring the Restricted Linkset Option
Configuring the Options for Handling TFCs on ITU-I and ITU-N Networks
This procedure is used to configure the options for handling TFCs on ITU-I and ITU-N networks using the chg-ss7opts command with these two parameters:
:discardtfci – This parameter specifies that the EAGLE 5 ISS discards TFC traffic received from an ITU-I network (discardtfci=on), or does not discard TFC traffic received from an ITU-I network (discardtfci=off). The system default value for this parameter is off.
:discardtfcn – This parameter specifies that the EAGLE 5 ISS discards TFC traffic received from an ITU-N network (discardtfcn=on), or does not discard TFC traffic received from an ITU-N network (discardtfcn=off). The system default value for this parameter is off.
Figure 3-37 Configuring the Options for Handling TFCs on ITU-I and ITU-N Networks
Changing the High-Capacity Card Temperature Alarm Thresholds
This procedure is used to change the temperature alarm thresholds for high-capacity cards (shown in Table 3-26) using the chg-th-alm command and these parameters.
:thermallv1 – The temperature threshold, specified as a percentage of
the card’s thermal shutdown temperature, at which major alarm UAM 0078 is generated. UAM 0078 is
generated to alert the user that corrective action needs to be performed to prevent
the high-capacity cards from overheating. If the high-capacity card is E5-STC,
E5-SM4G, E5-TSM, or E5-MCPM-B, the state of the card is not
changed. If the high-capacity card is an HC MIM, E5-E1T1, E5-ENET card, or E5-ATM
card, or SLIC, the state of the card is changed to IS-ANR (in service-abnormal).
The values for this parameter are 73 to 92. The system default value for this parameter is 92.
:thermallv2 – The temperature threshold, specified as a percentage of the card’s maximum operating temperature, at which critical alarm UAM 0077 is generated. When this threshold is reached, the high-capacity cards shed their traffic load, accept no more traffic, and the state of the cards is changed to IS-ANR (in service-abnormal). The values for this parameter are 74 to 100. The system default value for this parameter is 100.
- E5-ENET-B or SLIC running ERTHC GPL
- Outstanding grant requests will be completed but no new grant requests will be accepted. The card's state transitions “in-service abnormal.”
- E5-ATM-B running ATMHC GPL
- PST/SST of card remains IS-ANR/Restrict.
- E5-ENET-B or SLIC running IPSHC GPL
- Auto inhibits all telnet terminals allowed by user on that card and sets their status to OOS-MT-DSBLD/MEA. Sets card state to out-of-service, maintenance fault.
- E5-ENET-B or SLIC running IPSG GPL
- Outstanding grant requests will be completed but no new grant requests will be accepted.
- E5-ENET-B running IPLIMx/IPGWx GPL
- Outstanding grant requests will be completed but no new grant requests will be accepted.
- E5-MCPM-B or SLIC running MCPHC GPL
- PST/SST of card transitions to IS-ANR/Restrict . If card is primary MCP, role change arbitration is initiated.
For more information on UAM 0078 and UAM 077, go to Unsolicited Alarm and Information Messages Reference.
Table 3-26 shows the maximum thermal operating limit of temperatures of these cards at selected threshold levels.
Table 3-26 High Capacity Thermal Limits
| High Capacity Card | High Capacity Card's Temperature at the Maximum Thermal Operating Limit (thermallv2 = 100%) | High Capacity Card Temperatures at Selected Threshold Levels | ||||
| 95% | 90% | 85% | 80% | 75% | ||
| HC-MIM |
82° C 179.6° F |
77.9° C 172.2° F |
73.8° C 164.8° F |
69.7° C 157.5° F |
65.6° C 150.1° F |
61.5° C 147.2° F |
|
E5-ENET E5-E1T1 E5-STC E5-TSM E5-ATM |
95° C 203° F |
90.25° C 194.5° F |
85.5° C 185.9° F |
80.75° C 177.4° F |
76° C 168.8° F |
71.25° C 160.3° F |
|
E5-SM4G E5-MASP E5-ENET-B E5-ATM-B E5-SM8G-B E5-MCPM-B |
90° C 194° F |
85.5° C 185.9° F |
81° C 177.8° F |
76.5° C 169.7° F |
72° C 161.6° F |
67.5 °C 153.5°F |
The chg-th-alm command contains other optional parameters. These parameters are not shown here because they are not necessary to provision the high-capacity card temperature alarm thresholds. These parameters are explained in more detail in Commands User's Guide.
Figure 3-38 Changing the High-Capacity Card Temperature Alarm Thresholds
Activating the Origin-Based MTP Routing Feature
This procedure is used to enable and turn on the Origin-Based MTP Routing feature using the feature’s part number and a feature access key.
The feature access key for the Origin-Based MTP Routing feature is based on the feature’s part number and the serial number of the EAGLE, making the feature access key site-specific.
The
enable-ctrl-feat command enables the
feature by inputting the feature’s access key and the feature’s part number
with these parameters:
Note:
As of Release 46.3, the fak parameter is no longer required. This parameter is only used for backward compatibility.:fak – The feature access
key provided by Oracle.
:partnum – The
Oracle-issued part number of the Origin-Based MTP Routing feature, 893014201.
Once this feature is enabled, it is permanently enabled. This feature cannot be enabled with a temporary feature access key.
The
enable-ctrl-feat command requires that
the database contain a valid serial number for the EAGLE, and that this serial
number is locked. This can be verified with the
rtrv-serial-num command. The EAGLE is
shipped with a serial number in the database, but the serial number is not
locked. The serial number can be changed, if necessary, and locked once
theEAGLE is on-site, with the
ent-serial-num command. The
ent-serial-num command uses these
parameters.
:serial – The serial
number assigned to the EAGLE. The serial number is not case sensitive.
:lock – Specifies whether
or not the serial number is locked. This parameter has only one value,
yes, which locks the serial number.
Once the serial number is locked, it cannot be changed.
Note:
To enter and lock the EAGLE’s serial number, theent-serial-num command must be entered
twice, once to add the correct serial number to the database with the
serial parameter, then again with the
serial and the
lock=yes parameters to lock the serial
number. You should verify that the serial number in the database is correct
before locking the serial number. The serial number can be found on a label
affixed to the control shelf (shelf 1100).
The
chg-ctrl-feat command uses these
parameters:
:partnum – The
Oracle-issued part number of the Origin-Based MTP Routing feature, 893014201.
:status=on – used to turn
the Origin-Based MTP Routing feature on.
The status of the controlled features in the EAGLE is
shown with the
rtrv-ctrl-feat command.
To turn the Origin-Based MTP Routing feature on with the
chg-ctrl-feat command, the STP option
MTPLPRST must be set to
yes. This can be verified by performing
the
rtrv-stpopts command. Perform the
Configuring the Frequency of RST Messages on Low Priority Routes
procedure to change the
MTPLPRST option value, if necessary.
Once the Origin-Based MTP Routing feature is enabled and turned on, provisioning for the Origin-Based MTP Routing feature can be performed. Perform these procedures to provision the Origin-Based MTP Routing feature.
Origin-Based MTP Routing Feature
Origin-Based MTP Routing provides greater flexibility and control over the EAGLE routing mechanisms by enabling the user to selectively route traffic to the same destination through different networks depending on various classes of exception routes. The classes of exception routes are shown in the following list.
- DPC and OPC - an exception route using the DPC (destination point code) and OPC (originating point code) in the message to determine how the message will be routed.
- DPC and the originating linkset - an exception route using the DPC and the name of the linkset carrying incoming traffic to the EAGLE to determine how the message will be routed.
- DPC and CIC - an exception route using the DPC and CIC (circuit identification code) in the message to determine how the message will be routed.
- DPC and SI - an exception route using the DPC and SI (service indicator) value in the message to determine how the message will be routed.
- DPC - an exception route using only the DPC in the message to determine how the message will be routed.
The DPC of a route coupled with an exception route class
and exception route criteria creates a new destination for the route and also
creates an additional entry in the EAGLE’s routing table. The number of entries
in the EAGLE’s routing table is the number of DPCs provisioned with the
ent-dstn command plus the number of
exception route entries provisioned with the
ent-rtx command.
The number of entries in the EAGLE’s routing table cannot
exceed the number of DPCs allocated in the routing table, shown in the
DESTINATION ENTRIES ALLOCATED: row of
the
rtrv-rtx and
rtrv-dstn output. The EAGLE can contain
a maximum of
10,000 entries in the routing table. The total
number of entries provisioned in the routing table is shown in the
TOTAL DPC(s): row of the
rtrv-dstn or
rtrv-rtx output.
All other properties of a routeset apply to exception routesets with respect to provisioning (routes and route costs) and alarming with the exception of network management, which is discussed in the "Network Management and Exception Routes" section.
Exception Route Processing Order and Route Costs
The processing order of exception routes is pre-defined. The exception class list in the "Network Management and Exception Routes" section also shows the order that the classes of exception routes are processed.
If a particular route has two exception routes, a DPC and OPC and a DPC and CIC exception route, the DPC and OPC exception route is used first since it is processed before the DPC and CIC exception route.
To determine the priority of exception routes, a relative cost value is assigned to each exception route. The relative cost values are used only within an exception route class. The DPC of the exception route contains multiple entries exception route class value, for example multiple entries with the same DPC and OPC value. The relative cost value determines the order in which the exception routes with the same DPC and OPC values are used to route the messages.
For example, DPC A contains the following exception routes:
- OPC = B: RC=20: LSN=LSB
- OPC = B: RC=20: LSN=LSC
- OPC = B: RC=30: LSN=LSD
- SI = 3: RC=10: LSN=LS3
When an SCCP message is received from Node B, the exception route mechanism splits traffic matching exception routes OPC = B between the linksets LSB and LSC, treating it as a combined linkset, since both entries have the same relative cost value. When both linksets LSB and LSC are not available, traffic is switched to linkset LSD. Even through the SI=3 exception route has a lower relative cost value than the other exception routes for DPC A, the SI=3 exception route is used to route the messages only when the linksets LSB, LSC, and LSD are not available.
CIC Handling
Exception routes can be provisioned based on a single CIC value or a range of CIC values in an ISUP message. The only value used by this feature for all CIC triggers will be the CIC value placed after the routing label and not any CIC value placed within the mandatory fixed, variable or optional parts of the message. Figure 3-39 shows the location of this value within the message.
Figure 3-39 ISDN User Part Message Parts
Since this feature will not consider any CIC value placed within the mandatory fixed, variable or optional part, messages within ISUP that are applied over a range of circuits (GRS, CGB, CGU, etc.) may be mishandled. Because of this, the user must consider how maintenance is handled before CIC ranging is used in order to ensure that circuit maintenance is performed properly.
For example, if a GRS is sent where the CIC field is 5 and the range field is 10, this implies that circuits 5 to 15 should be reset. If an exception route is provisioned for CIC 5, it would take the path (if available) provisioned since the CIC value in the message matches the one that is provisioned. However, if the exception route provisioned is 6, the CGU will not take the path provisioned even though 6 is within the range specified by the GRS message.
Network Management and Exception Routes
The Origin-Based MTP Routing operates on an end-to-end scheme, and not a point-to-point scheme. As a result, adjacent point codes cannot have exception routes. Correct network handing is critical for the EAGLE and other routing mechanisms to operate properly. Imposing exception routes over adjacent point codes introduces a large element of risk since elements of the network may receive point code and link events late, impacting routing to those and other destinations.
When considering the impact that exception routing could have on the network, the following restrictions are in place to ensure network sanity:
- Adjacent point codes cannot not have exception routes.
- Exception routes do not factor into the status of a destination. A destination’s status is defined only by the standard routes entered.
- If all the DPC-based routes to a destination are unavailable, then the status of the destination is listed as prohibited even if there are exception routes available.
- Preventative and broadcast TFx or TCx are not sent based on the status of exception routes. If an exception route is unavailable, the next exception route is chosen ending with the standard provisioned routes.
Congestion Handling and Origin-Based Routing
Since the only identifying characteristic of a TFC message is the capability point code (CPC), the EAGLE is unable to determine if the node or the route used to reach that destination is congested. Normally, the EAGLE would list the destination as congested since there was only one routeset to that destination.
With the Origin-Based MTP Routing feature, there is no longer only one routeset to a destination, but many. However, due to the inexact nature of the TFC, the EAGLE is still unable to determine if an exception route, a normal route, or the node itself that is congested. Thus, once a TFC is received regarding a node within exception routes provisioned against it, the EAGLE lists all routesets to that destination as congested.
To ensure that the EAGLE has the correct congestion status of the destination, the EAGLE sends an RCT regarding that destination over each impacted route and not just the normal route. This ensures that the destination does not “bounce” in and out of congestion. The EAGLE starts level 3 timer T15 at the beginning of the broadcast and level 3 timer T16 at the completion.
If the EAGLE receives a TFC regarding that destination in response to the poll, the EAGLE maintains the congestion level against it, even if it was received over a linkset which is part of an exception routeset and not the normal routeset. This is because the EAGLE can not rely on the incoming linkset of the TFC to identify the route that is congested since the adjacent nodes routing provisioning may be different the EAGLE.
Circular Route Detection and Origin-Based Routing
Normally, if the EAGLE detects that traffic originated from a route is to be sent back over the same route, it changes the status of the DPC to prohibited so that the linkset does not enter into congestion and potentially impact other valid routes. However, with Origin-Based MTP Routing, this can occur since there are some situations where this is the desired action. In order to reduce the impact to the true route of the DPC, the EAGLE prohibits only the impacted route to a destination, and not the destination itself.
This ensures that only the exception route provisioned in this manner is impacted if circular routing is detected and allow all other remaining traffic to reach the DPC.
However, since this is an abnormal routing condition, the
EAGLE requires the use of the
force=yes parameter when entering an
exception route where the ILSN and the LSN parameters values are the same
If circular routing is detected on an exception route,
enter the
rst-dstn command to clear this
condition.
Gateway Nodes and Exception Routes
Exception routes can be provisioned across networks, where the OPC and DPC do not exist within the same network type (ANSI, ITU-I or ITU-N). However, exception routes can be provisioned only through using full point code values, not alias or cluster point code values. This allows the user to understand which exception routes apply without trying to remember what aliases are provisioned for specific point codes.
Because of MTP conversion restrictions it is necessary that each OPC that is used within a gateway exception routeset must have an alias point code entry in the destination table for the network that the DPC of the exception route resides in. If the alias point code is not present, then the EAGLE is not able to route messages across networks.
SCCP HandlingWith SCCP messaging, there are three possible OPC values that may be used; the OPC originally in the routing header, the EAGLE true point code, and the CGPA OPC (determined by whether the CGPA portion of the message is route-on-dpcssn or route-on-gt). To provide the option on which criteria to use, Origin-Based MTP Routing provides an SCCP option (MOBRSCCPOPC) which has three values:
mtp– The original OPC in the message is used as the OPC value to use for routing the SCCP message.sccp– If the CGPA portion of the message is route-on-dpcssn, the point code in the CGPA portion of the message, if the CGPA portion of the message is route-on-dpcssn, is used as the OPC value to use for routing the SCCP message. If the CGPA portion of the message is route-on-gt, the MTP option, the original OPC in the message, is used as the OPC value to use for routing the SCCP message.tpc– The EAGLE’s true point code is used as the OPC value to use for routing the SCCP message.
The MOBRSCCPOPC option is provisioned with the
chg-sccpopts command.
If traffic truly originates from the EAGLE (for example,
a UDTS), then the
ilsn parameter of an exception route is
not used in evaluating which exception route to use, if any. This is because
the traffic was generated by the EAGLE and did not enter through any linkset.
UDTS/XUDTS messages generated by the EAGLE and messages undergoing global title translation are routed over OPC exception routes. However, other messages originated by the EAGLE, for example, response messages generated by the EAGLE SCCP services/subsystems, do not use OPC exception routes. These messages are routed using other exception criteria, for example, SI based exception routes, if these exception routes are defined. If these exception routes are not defined, normal routing is applied to these messages.
Figure 3-40 Activating the Origin-Based MTP Routing - Sheet 1 of 4 Feature
Figure 3-41 Activating the Origin-Based MTP Routing - Sheet 2 of 4
Figure 3-42 Activating the Origin-Based MTP Routing - Sheet 3 of 4
Figure 3-43 Activating the Origin-Based MTP Routing - Sheet 4 of 4
Configuring the Origin-Based MTP Routing SCCP OPC Option
This procedure is used to configure the option that determines which of the three OPC values can be used to route SCCP messages for the Origin-Based MTP Routing feature. The option is configured with the mobrsccpopc parameter of the chg-sccpopts command. The mobrsccpopc parameter has three values:
mtp – The original OPC in the message is used as the OPC value to use for routing the SCCP message.
sccp – If the CGPA portion of the message is route-on-dpcssn, the point code in the CGPA portion of the message, if the CGPA portion of the message is route-on-dpcssn, is used as the OPC value to use for routing the SCCP message. If the CGPA portion of the message is route-on-gt, the MTP option, the original OPC in the message, is used as the OPC value to use for routing the SCCP message.
tpc – The EAGLE 5 ISS’s true point code is used as the OPC value to use for routing the SCCP message.
If traffic originated from the Eagle, (for example, a UDTS message) then the incoming linkset name (ilsn parameter) of the exception route is not used in evaluating which exception route to use, if any. This is because since the traffic was generated by the Eagle it did not enter through any linkset.
The current value of the mobrsccpopc parameter is shown in the MOBRSCCPOPC field in the rtrv-sccpopts command output.
The mobrsccpopc parameter can be specified with the chg-sccpopts command, and the MOBRSCCPOPC field in the rtrv-sccpopts command output is displayed only if the Origin-Based MTP Routing feature is enabled and turned on. If the MOBRSCCPOPC field is not shown in the rtrv-sccpopts command output, perform the Activating the Origin-Based MTP Routing Feature procedure to enable and turn on the Origin-Based MTP Routing feature.
Figure 3-44 Configuring the Origin-Based MTP Routing SCCP OPC Option
Adding an Exception Route Entry
This procedure is used to add an exception route to the database using the ent-rtx command. The ent-rtx command uses these parameters.
:dpc/dpca/dpci/dpcn/dpcn24 – The destination point code of the node that the traffic is being sent to.
:opc/opca/opci/opcn/opcn24 – The originating point code of the node sending traffic to the EAGLE.
Note:
See Point Code Formats for a definition of the point code types that are used on the EAGLE and for a definition of the different formats that can be used for ITU national point codes.:ilsn – The name of the linkset carrying incoming traffic to the EAGLE.
:lsn – The name of the linkset that will carry the traffic to the node specified by the destination point code.
:si – The service indicator value that will be assigned to the exception route. The value of the si parameter is 3 to 15.
:cic – The circuit identification code (CIC) value that will be assigned to an exception route containing a single CIC entry or the CIC value that begins a range of CICs that will be assigned to the exception route. The value of the cic parameter is 0 to 16383.
:ecic – The circuit identification code value that ends the range of CICs that will be assigned to the exception route. The value of the ecic parameter is 0 to 16383.
:rc – The relative cost value (priority) that will be assigned to the exception route. The value of the rc parameter is 0 to 99.
:force – This parameter allows an exception route to be added to the database even if the ilsn parameter value is the same as the lsn parameter value. This parameter has only one value, yes.
The combinations of these parameters that can be used with the ent-rtx command are shown in Table 3-27.
To add an exception route to the database, the Origin-Based MTP Routing feature must be enabled and turned on. If error message E4584 is displayed after the rtrv-rtx command is executed, the Origin-Based MTP Routing feature is not enabled or turned on.
E4584 Cmd Rej: MTP Origin Based Routing Feature must be ON
If the Origin-Based MTP Routing feature is not enabled or turned on, perform the Activating the Origin-Based MTP Routing Feature procedure to enable, if required, and turn on the Origin-Based MTP Routing feature.
The DPC value assigned to the exception route must be assigned to a route. If the required route is not shown in the rtrv-rte output, perform on of these procedures to add the required route.
- Adding a Route Containing an SS7 DPC
- Adding a Route Containing a Cluster Point Code
- Adding a Route Containing an IPGWx Linkset
The names of the linksets required specified for the lsn and ilsn parameters must be provisioned in the database. This can be verified by entering the rtrv-ls command. If the required linkset is not in the database, perform one of these procedures to add the linkset.
- Adding an SS7 Linkset
- “Configuring an IPGWx Linkset,” "Adding an IPSG M2PA Linkset," or "Adding an IPSG M3UA Linkset" procedures in Database Administration - IP7 User's Guide.
The linkset must be added according to the rules shown in the "Adding Linksets for Exception Routes" section.
Adding Linksets for Exception Routes
The linkset must be added according to the following rules:
- If the
dpcvalue of the exception route entry is an ANSI point code, the adjacent point code of thelsnvalue must be an ANSI point code. - If the exception route is an OPC-based exception route, the
opcparameter value cannot be the adjacent point code of the linkset that is specified by thelsnparameter value. - If the
dpcvalue of the exception route entry is an ITU-I point code, the adjacent point code of thelsnvalue must be an ITU-I point code. If the linkset contains an SAPC (secondary adjacent point code), the adjacent point code of thelsnvalue can be either an ITU-N or ITU-N24 point code if thesapcvalue is an ITU-I point code. If the adjacent point code of thelsnvalue is an ITU-N point code with a group code, when the exception route is added, the group code of the adjacent point code of the linkset does not have to be the same as the group code of theopcnvalue. If an ITU-N linkset is specified for theilsnparameter, the group code of the adjacent point code of theilsnvalue does not have to match the group code of the adjacent point code of thelsnvalue. - If the
dpcvalue of the exception route entry is an ITU-N point code, the adjacent point code of thelsnvalue must be an ITU-N point code.- If the
dpcvalue of the exception route entry is an ITU-N point code with no group code assigned to the ITU-N point code, the adjacent point code of thelsnvalue or the adjacent point code of all the linksets in the routeset can be an ITU-I point code if thesapc(secondary adjacent point code) value is an ITU-N point code. - If the
dpcvalue of the exception route entry is an ITU-N point code with a group code, the adjacent point code of thelsnvalue can be an ITU-I point code if thesapcvalue is an ITU-N point code. When the exception route is added, the group code of thedpcnvalue and theopcnvalue must be the same. The group code of the adjacent point code of thelsnvalue and theilsnvalue must be the same. The group code of thedpcnvalue must be the same as the group code of either the adjacent point code of thelsnvalue or thesapc(secondary adjacent point code) assigned to thelsnvalue.
- If the
- If the
dpcvalue of the exception route entry is an ITU-N24 point code, the adjacent point code of thelsnvalue must be an ITU-N24 point code. If the linkset contains an SAPC (secondary adjacent point code), the adjacent point code of thelsnvalue can be an ITU-I point code if thesapcvalue is an ITU-N24 point code.
The SAPC values assigned to the linksets can be verified by entering the rtrv-ls:lsn=<linkset name> command.
Figure 3-45 Adding an Exception Route Entry
Removing a Route Exception Entry
This procedure is used to remove an exception route from the database using the dlt-rtx command. The dlt-rtx command uses these parameters.
:dpc/dpca/dpci/dpcn/dpcn24 – The destination point code of the node that the traffic is being sent to.
:opc/opca/opci/opcn/opcn24 – The originating point code of the node sending traffic to the EAGLE.
:ilsn – The name of the linkset carrying incoming traffic to the EAGLE.
:lsn – The name of the linkset carrying the traffic to the node specified by the destination point code.
:si – The service indicator value assigned to the exception route.
:cic – The circuit identification code value assigned to an exception route containing a single CIC entry or the CIC value that begins a range of CICs assigned to the exception route.
:ecic – The circuit identification code value that ends the range of CICs assigned to the exception route.
:all – This parameter, along with the force=yes parameter, allows all the exception routes containing the exception route criteria, OPC, ILSN, SI, CIC, CIC and ECIC, to be removed from the database. This parameter has only one value, yes.
:force – This parameter, along with the all=yes parameter, allows all the exception routes containing the exception route criteria, OPC, ILSN, SI, CIC, CIC and ECIC, to be removed from the database. This parameter has only one value, yes.
The values of all the parameters specified for the dlt-rtx command, except the all=yes and force=yes parameters, must be shown in the rtrv-rtx output and must be assigned to the specified dpc/dpca/dpci/dpcn/dpcn24 value.
The combinations of these parameters that can be used with the dlt-rtx command are shown in Table 3-28.
Figure 3-46 Removing a Route Exception Entry
Changing a Route Exception Entry
This procedure is used to change the attributes of an exception route in the database using the chg-rtx command. The attributes of the exception route that can be changed are the linkset (lsn parameter) and the relative cost (rc parameter) of the exception route.
The chg-rtx command uses these parameters.
:dpc/dpca/dpci/dpcn/dpcn24 – The destination point code of the node that the traffic is being sent to.
:opc/opca/opci/opcn/opcn24 – The originating point code of the node sending traffic to the EAGLE 5 ISS.
:ilsn – The name of the linkset carrying incoming traffic to the EAGLE.
:lsn – The name of the linkset that carries the traffic to the node specified by the destination point code.
:si – The service indicator value assigned to the exception route.
:cic – The circuit identification code value assigned to an exception route containing a single CIC entry or the CIC value that begins a range of CICs assigned to the exception route.
:ecic – The circuit identification code value that ends the range of CICs assigned to the exception route.
:rc – The new relative cost value (priority) that will be assigned to the exception route. The value of the rc parameter is 0 to 99.
:nlsn – The name of the new linkset that will carry the traffic to the node specified by the destination point code.
:force – This parameter allows the exception route to be changed even if the ilsn parameter value is the same as the nlsn parameter value. This parameter has only one value, yes.
The values of all the parameters specified for the chg-rtx command, except the rc, nlsn, and force=yes parameters, must be shown in the rtrv-rtx output and must be assigned to the specified dpc/dpca/dpci/dpcn/dpcn24 value.
The combinations of these parameters that can be used with the chg-rtx command are shown in Table 3-29 .
The names of the linksets required specified for the nlsn parameter must be provisioned in the database. This can be verified by entering the rtrv-ls command. If the required linkset is not in the database, perform one of these procedures to add the linkset.
- Adding an SS7 Linkset
- “Adding an X.25 Linkset” procedure in Database Administration - Features User's Guide
- “Configuring an IPGWx Linkset,” "Adding an IPSG M2PA Linkset," or "Adding an IPSG M3UA Linkset" procedures in Database Administration - IP7 User's Guide.
The linkset must be added according to the rules shown in the "Adding Linksets for Exception Routes" section.
Adding Linksets for Exception Routes
The linkset must be added according to the following rules:
- If the
dpcvalue of the exception route entry is an ANSI point code, the adjacent point code of the new linkset must be an ANSI point code. - If the exception route is an OPC-based exception route, the
opcparameter value cannot be the adjacent point code of the linkset that is specified by thelsnparameter value. - If the
dpcvalue of the exception route entry is an ITU-I point code, the adjacent point code of the new linkset must be an ITU-I point code. If the linkset contains an SAPC (secondary adjacent point code), the adjacent point code of the new linkset can be either an ITU-N or ITU-N24 point code if thesapcvalue is an ITU-I point code. If the adjacent point code of thenlsnvalue is an ITU-N point code with a group code, when the exception route is changed, the group code of the adjacent point code of the new linkset does not have to be the same as the group code of theopcnvalue. If an ITU-N linkset is specified for theilsnparameter, the group code of the adjacent point code of theilsnvalue does not have to match the group code of the adjacent point code of thenlsnvalue. - If the adjacent point code of the
nlsnvalue is an ITU-N point code with a group code, when the exception route is changed, the group code of the adjacent point code of the new linkset does not have to be the same as the group code of theopcnvalue. If an ITU-N linkset is specified for theilsnparameter, the group code of the adjacent point code of theilsnvalue does not have to match the group code of the adjacent point code of thenlsnvalue. - If the
dpcvalue of the exception route entry is an ITU-N point code, the adjacent point code of thenlsnvalue must be an ITU-N point code.- If the
dpcvalue of the exception route entry is an ITU-N point code with no group code assigned to the ITU-N point code, the adjacent point code of thenlsnvalue or the adjacent point code of all the linksets in the routeset can be an ITU-I point code if thesapc(secondary adjacent point code) value is an ITU-N point code. - If the
dpcvalue of the exception route entry is an ITU-N point code with a group code, the adjacent point code of thenlsnvalue can be an ITU-I point code if thesapcvalue is an ITU-N point code. When the exception route is changed, the group code of the adjacent point code of thenlsnvalue and theilsnvalue must be the same. The group code of thedpcnvalue must be the same as the group code of either the adjacent point code of thenlsnvalue or thesapc(secondary adjacent point code) assigned to thenlsnvalue.
- If the
- If the
dpcvalue of the exception route entry is an ITU-N24 point code, the adjacent point code of thelsnvalue must be an ITU-N24 point code. If the linkset contains an SAPC (secondary adjacent point code), the adjacent point code of thelsnvalue can be an ITU-I point code if thesapcvalue is an ITU-N24 point code.
The SAPC values assigned to the linksets can be verified by entering the rtrv-ls:lsn=<linkset name> command.
Figure 3-47 Changing a Route Exception Entry
Activating the Circular Route Auto-Recovery Feature
This procedure is used to enable and turn on the Circular Route Auto-Recovery feature using the feature's part number and a feature access key.
The feature access key for the Circular Route Auto-Recovery feature is based on the features part number and the serial number of the EAGLE, making the feature access key site-specific.
The enable-ctrl-feat command enables the feature by inputting the features access key and the features part number with these parameters:
:fak – The feature access key provided by Oracle.
:partnum – The Oracle-issued part number of the Circular Route Auto-Recovery feature, 893017601.
Once this feature is enabled, it is permanently enabled. This feature cannot be enabled with a temporary feature access key.
The enable-ctrl-feat command requires a valid serial number for the EAGLE to be configured in the database, and that this serial number is locked. This can be verified with the rtrv-serial-num command. The EAGLE is shipped with a serial number in the database, but the serial number is not locked. The serial number can be changed, if necessary, and locked once the EAGLE is on-site, by using the ent-serial-num command. The ent-serial-num command uses these parameters.
:serial – The serial number assigned to the EAGLE. The serial number is not case sensitive.
:lock – Specifies whether or not the serial number is locked. This parameter has only one value, yes, which locks the serial number. Once the serial number is locked, it cannot be changed.
Note:
To enter and lock the EAGLE’s serial number, theent-serial-num command must be entered twice, once to add the correct serial number to the database with the serial parameter, then again with the serial and the lock=yes parameters to lock the serial number. You should verify that the serial number in the database is correct before locking the serial number. The serial number can be found on a label affixed to the control shelf (shelf 1100).
The chg-ctrl-feat command uses these parameters:
:partnum – The Oracle-issued part number of the Circular Route Auto-Recovery feature, 893017601.
:status=on – used to turn the Circular Route Auto-Recovery feature on.
The status of the Circular Route Auto-Recovery feature is shown with the rtrv-ctrl-feat command.
Once the Circular Route Auto-Recovery feature has been turned on, it can be turned off. For more information on turning off the Circular Route Auto-Recovery feature, go to the Turning Off the Circular Route Auto-Recovery Feature procedure.
Once the Circular Route Auto-Recovery feature has been turned on, it automatically clears CRD when Far End Loopback is detected.
Figure 3-48 Activating the Circular Route Auto-Recovery Feature
Turning Off the Circular Route Auto-Recovery Feature
This procedure is used to turn off the Circular Route Auto-Recovery feature using the chg-ctrl-feat command.
The chg-ctrl-feat command uses these parameters:
:partnum – The Oracle-issued part number of the Circular Route Auto-Recovery feature, 893017601.
:status=off – used to turn off the Circular Route Auto-Recovery feature.
The status of the Circular Route Auto-Recovery feature must be on and is shown with the rtrv-ctrl-feat command.
Caution:
Circular Route Auto-Recovery will not be performed if the Circular Route Auto-Recovery feature is turned off.Figure 3-49 Turning Off the Circular Route Auto-Recovery Feature
Activating the Enhanced Far-End Loopback Detection Feature
This procedure is used to enable and turn on the Enhanced Far-End Loopback Detection feature using the feature's part number and a feature access key.
The feature access key for the Enhanced Far-End Loopback Detection feature is based on the features part number and the serial number of the EAGLE, making the feature access key site-specific.
The enable-ctrl-feat command enables the feature by inputting the features access key and the features part number with these parameters:
:fak – The feature access key provided by Oracle.
:partnum – The Oracle-issued part number of the Enhanced Far-End Loopback Detection feature, 893017601.
Once this feature is enabled, it is permanently enabled. This feature cannot be enabled with a temporary feature access key.
The enable-ctrl-feat command requires a valid serial number for the EAGLE to be configured in the database, and that this serial number is locked. This can be verified with the rtrv-serial-num command. The EAGLE is shipped with a serial number in the database, but the serial number is not locked. The serial number can be changed, if necessary, and locked once the EAGLE is on-site, by using the ent-serial-num command. The ent-serial-num command uses these parameters.
:serial – The serial number assigned to the EAGLE. The serial number is not case sensitive.
:lock – Specifies whether or not the serial number is locked. This parameter has only one value, yes, which locks the serial number. Once the serial number is locked, it cannot be changed.
Note:
To enter and lock the EAGLE’s serial number, theent-serial-num command must be entered twice, once to add the correct serial number to the database with the serial parameter, then again with the serial and the lock=yes parameters to lock the serial number. You should verify that the serial number in the database is correct before locking the serial number. The serial number can be found on a label affixed to the control shelf (shelf 1100).
The chg-ctrl-feat command uses these parameters:
:partnum – The Oracle-issued part number of the Circular Route Auto-Recovery feature, 893018101.
:status=on – used to turn the Enhanced Far-End Loopback Detection feature on.
The status of the Enhanced Far-End Loopback Detection feature is shown with the rtrv-ctrl-feat command.
Once the Enhanced Far-End Loopback Detection feature has been turned on, it can be turned off. For more information on turning off the Enhanced Far-End Loopback Detection feature, go to the Turning Off the Enhanced Far-End Loopback Detection Feature procedure.
Once the Enhanced Far-End Loopback Detection feature has been turned on, it significantly decreases the time required to take a link out of service. Whenever a trigger event occurs that indicates that Far-End Loopback may have occurred, the EAGLE will send an SLTM within 250 milliseconds after the trigger event has occurred. Normal processing of this SLTM will take the link out of service if the same SLTM is received at the OPC. The Enhanced Far-End Loopback feature will fail the link as quickly as possible. This rapid failure will prevent the EAGLE from marking DPCs as CRD-prohibited.
Figure 3-50 Activating the Enhanced Far-End Loopback Detection Feature
Turning Off the Enhanced Far-End Loopback Detection Feature
This procedure is used to turn off the Enhanced Far-End Loopback Detection feature using the chg-ctrl-feat command.
The chg-ctrl-feat command uses these parameters:
:partnum – The Oracle-issued part number of the Enhanced Far-End Loopback Detection feature, 893018101.
:status=off – used to turn off the Enhanced Far-End Loopback Detection feature.
The status of the Enhanced Far-End Loopback Detection feature must be on and is shown with the rtrv-ctrl-feat command.
Caution:
Enhanced Far-End Loopback Detection will not be performed if the Enhanced Far-End Loopback Detection feature is turned off.Figure 3-51 Turning Off the Enhanced Far-End Loopback Detection Feature
Activating the Multiple Linksets to Single Adjacent PC (MLS) Feature
This procedure is used to enable and turn on the Multiple Linksets to Single Adjacent PC (MLS) feature with the enable-ctrl-feat and chg-ctrl-feat commands.
The enable-ctrl-feat command enables the Multiple Linksets to Single Adjacent PC (MLS) feature by specifying the part number and feature access key for this feature with these parameters:
:fak – The feature access key supplied by Oracle. The feature access key contains 13 alphanumeric characters and is not case sensitive. If you do not have the feature access key for the proxy point code quantity you wish to enable, contact your Oracle Sales Representative or Account Representative.
:partnum – The Oracle-issued part number for the Multiple Linksets to Single Adjacent PC (MLS), 893019701.
The enable-ctrl-feat command requires a valid serial number for the EAGLE to be configured in the database, and that this serial number is locked. This can be verified with the rtrv-serial-num command. The EAGLE is shipped with a serial number in the database, but the serial number is not locked. The serial number can be changed, if necessary, and locked once the EAGLE is on-site, by using the ent-serial-num command. The ent-serial-num command uses these parameters.
:serial – The serial number assigned to the EAGLE. The serial number is not case sensitive.
:lock – Specifies whether or not the serial number is locked. This parameter has only one value, yes, which locks the serial number. Once the serial number is locked, it cannot be changed.
Note:
To enter and lock the EAGLE’s serial number, theent-serial-num command must be entered twice, once to add the correct serial number to the database with the serial parameter, then again with the serial and the lock=yes parameters to lock the serial number. You should verify that the serial number in the database is correct before locking the serial number. The serial number can be found on a label affixed to the control shelf (shelf 1100).
To enable the Multiple Linksets to Single Adjacent PC (MLS) feature, the Multiple Point Code feature must be turned on using the chg-feat command. The rtrv-feat command shows whether or not the Multiple Point Code feature is turned on.
Note:
Once the Multiple Point Code feature is turned on with thechg-feat command, it cannot be turned off.
The Multiple Point Code feature must be purchased before you turn this feature on with the chg-feat command. If you are not sure if you have purchased the Multiple Point Code feature, contact your Oracle Sales Representative or Account Representative.
The chg-ctrl-feat command uses these parameters:
:partnum – The Oracle-issued part number of the Multiple Linksets to Single Adjacent PC (MLS) feature, 893019701.
:status=on – used to turn the Multiple Linksets to Single Adjacent PC (MLS) feature on.
The status of this feature in the EAGLE is shown with the rtrv-ctrl-feat command.
After this feature is enabled and turned on, an adjacent point code can be assigned to a maximum of six linksets.
Figure 3-52 Activating the Multiple Linksets to Single Adjacent PC (MLS) Feature
Configuring the ITU Linkset NI Mapping Options
This procedure is used to configure the network indicator (NI) mapping options for an ITU-I or ITU-N linkset. These options are configured with the chg-lsopts command and these parameters.
:lsn - The name of the ITU-I or ITU-N linkset.
:icnimap - This parameter specifies the type of network indicator (NI) mapping for incoming MSUs on the linkset. The NI value in the incoming MSU is changed to the value specified by the icnimap parameter before processing the message. The values for this parameter are: itui2ituis, ituis2itui, itun2ituns, ituns2itun, or none.
itui2ituis- Map the ITU international network indicator value to the ITU international spare network indicator valueituis2itui- Map the ITU international spare network indicator value to the ITU international network indicator valueitun2ituns- Map the ITU national network indicator value to the ITU national spare network indicator valueituns2itun- Map the ITU national spare network indicator value to the ITU national network indicator valuenone- network indicator mapping is not performed on the specified linkset.
icnimap parameter for the linkset is not changed if the icnimap parameter is not specified with the chg-lsopts command. The system default value for the icnimap parameter is none.
:ognimap - This parameter specifies the type of network indicator (NI) mapping for outgoing MSUs on the linkset. The NI value in the processed MSU is changed to the value specified by the ognimap parameter for that linkset before routing the message to its intended destination. The values for this parameter are: itui2ituis, ituis2itui, itun2ituns, ituns2itun, or none.
itui2ituis- Map the ITU international network indicator value to the ITU international spare network indicator valueituis2itui- Map the ITU international spare network indicator value to the ITU international network indicator valueitun2ituns- Map the ITU national network indicator value to the ITU national spare network indicator valueituns2itun- Map the ITU national spare network indicator value to the ITU national network indicator valuenone- network indicator mapping is not performed on the specified linkset.
ognimap parameter for the linkset is not changed if the ognimap parameter is not specified with the chg-lsopts command. The system default value for the ognimap parameter is none.
icnimap and ognimap parameters, the ITU National and International Spare Point Code Support feature must be enabled. Refer to the Activating the ITU National and International Spare Point Code Support Feature procedure for information about enabling the ITU National and International Spare Point Code Support feature. Values for the icnimap and ognimap parameters other than none can be specified only for linksets that have ITU-I or 14-bit ITU-N adjacent point codes. If either the icnimap or ognimap parameters are specified for the chg-lsopts command, both parameters must be specified for the chg-lsopts command. The network indicator mapping value for incoming messages on the linkset must be compatible with the network indicator mapping value for the outgoing messages on the linkset. For example, if the icnimap=itui2ituis parameter is specified for the linkset, the ognimap=ituis2itui parameter must be specified for the linkset. Table 3-30 shows the relationship between the icnimap and ognimap parameter values.
Table 3-30 Network Indicator Mapping Rules
| ICNIMAP Parameter Value | OGNIMAP Parameter Value |
|---|---|
| ITUI2ITUIS | ITUIS2ITUI |
| ITUIS2ITUI | ITUI2ITUIS |
| ITUN2ITUNS | ITUNS2ITUN |
| ITUNS2ITUN | ITUN2ITUNS |
| NONE | NONE |
The values of the icnimap and ognimap parameters are shown in the ICNIMAP and OGNIMAP columns of the rtrv-ls output. The ICNIMAP and OGNIMAP columns are shown only if the linkset name (lsn parameter) is specified with the rtrv-ls command, the ITU National and International Spare Point Code Support feature is enabled, and if the adjacent point code of the linkset is either an ITU-I or ITU-N point code.
Figure 3-53 Configuring the ITU Linkset NI Mapping Options
Configuring the Option for Handling Message Priorities for Messages Crossing into ITU-I and ITU-N Networks
This procedure is used to configure the option for handling the priority value of messages that cross into ITU-I and ITU-N networks using the chg-ss7opts command with these two parameters.
:msgpri2itui – This parameter specifies the priority value for messages that cross into an ITU-I network. The values for this parameter are:
dflt- The priority value for an MTP-routed message is set to 0. A message routed by Global Title Translation retains the priority value set by the incoming message.0-3- The priority value for any message crossing into an ITU-I network is changed to this parameter value.
The system default value for the msgpri2itui parameter is dflt.
:msgpri2itun – This parameter specifies the priority value for messages that cross into an ITU-N or ITU-N24 network. The values for this parameter are:
dflt- The priority value for an MTP-routed message is set to 0. A message routed by Global Title Translation retains the priority value set by the incoming message.0-3- The priority value for any message crossing into an ITU-N or ITU-N24 network is changed to this parameter value. Messages crossing into an ANSI network are not affected.
The system default value for the msgpri2itun parameter is dflt.
These parameters are optional, but at least one of these parameters must be specified in this procedure. If a parameter is not specified, its value is not changed.
Figure 3-54 Configuring the Option for Handling Message Priorities for Messages Crossing into ITU-I and ITU-N Networks
Activating the 6-Way Loadsharing on Routesets Feature
This procedure is used to enable and turn on the 6-Way Loadsharing on Routesets feature with the enable-ctrl-feat and chg-ctrl-feat commands.
The enable-ctrl-feat command enables the 6-Way Loadsharing on Routesets feature by specifying the part number and feature access key for this feature with these parameters:
:fak – The feature access key supplied by Oracle. The feature access key contains 13 alphanumeric characters and is not case sensitive. If you do not have the feature access key for the proxy point code quantity you wish to enable, contact your Oracle Sales Representative or Account Representative.
:partnum – The Oracle-issued part number for the 6-Way Loadsharing on Routesets feature, 893019801.
The enable-ctrl-feat command requires a valid serial number for the EAGLE to be configured in the database, and that this serial number is locked. This can be verified with the rtrv-serial-num command. The EAGLE is shipped with a serial number in the database, but the serial number is not locked. The serial number can be changed, if necessary, and locked once the EAGLE is on-site, by using the ent-serial-num command. The ent-serial-num command uses these parameters.
:serial – The serial number assigned to the EAGLE. The serial number is not case sensitive.
:lock – Specifies whether or not the serial number is locked. This parameter has only one value, yes, which locks the serial number. Once the serial number is locked, it cannot be changed.
Note:
To enter and lock the EAGLE’s serial number, theent-serial-num command must be entered twice, once to add the correct serial number to the database with the serial parameter, then again with the serial and the lock=yes parameters to lock the serial number. You should verify that the serial number in the database is correct before locking the serial number. The serial number can be found on a label affixed to the control shelf (shelf 1100).
The chg-ctrl-feat command uses these parameters:
:partnum – The Oracle-issued part number of the 6-Way Loadsharing on Routesets feature, 893019801.
:status=on – used to turn the 6-Way Loadsharing on Routesets feature on.
Caution:
Once the 6-Way Loadsharing on Routesets feature is turned on, it cannot be turned off.The status of this feature in the EAGLE is shown with the rtrv-ctrl-feat command.
After this feature is enabled and turned on, a maximum of six routes in a routeset can be assigned the same relative cost value.
Figure 3-55 Activating the 6-Way Loadsharing on Routesets Feature