For the “A” side of the unit:
### Servernet interface names – DO NOT REMOVE THIS LINE OR MODIFY LINES
BELOW
10.16.192.3 akchin7a # system 1
10.16.192.4 akchin7b other # system 2
### End Servernet interface names – DO NOT REMOVE THIS LINE
#
# Internet host table
#
# Next Lines are SP–to–Host Internal Net IP Connections –
# DO NOT MODIFY THE LINES BELOW!
# DO NOT USE IN spconfig.env CONFIGURATION FILE!
For the “B” side of the unit:
### Servernet interface names – DO NOT REMOVE THIS LINE OR MODIFY LINES
BELOW
10.16.192.4 akchin7b # system 2
10.16.192.3 akchin7a other # system 1
### End Servernet interface names – DO NOT REMOVE THIS LINE
#
# Internet host table
#
# Next Lines are SP–to–Host Internal Net IP Connections –
# DO NOT MODIFY THE LINES BELOW!
# DO NOT USE IN spconfig.env CONFIGURATION FILE!
- Execute the following command.
Hwstatus
-
Verify that the test is successful by verifying the system finds the correct cards and modules in the correct slots. Refer to the MM Card and Module Location section of this chapter for the standard MM configuration.
An example of a successful test is shown below. The following are the part names for the various items: sscCru= SSC, iocTiavSs7Cru= SS7, iocTiavTringCru= Token Ring, ioceCRU= Ethernet, devDsk4gbCru= disc drive, devDdsCru= DAT tape,
hwstatus
Module Information:
–––––––––––––––––––
physical module Tandem rev track
address type partNo level id
––––––––– –––––––– –––––– –––––– ––––––
1.1 STORAGE
1.2 CO_CPU
1.3 CO_IO
1.5 CO_FAN
CRU Information:
––––––––––––––––
physical slot cru cru cru Tandem rev track part
address type type state substate partNo level id name
–––––––– –––– –––– –––––––––––– –––––––– –––––– –––––– ––––– ––––––––
1.2.201 ROC ROC CONFIGURED CNFG_OK 129464 A00–00 V0ABHZ rocCru
1.2.206 ROC ROC CONFIGURED CNFG_OK 129464 A00–00 V0AP65 rocCru
1.2.202 CPU CPU CONFIGURED CNFG_OK 420586 B00–01 V0JF9W cpuCru
1.2.205 CPU CPU CONFIGURED CNFG_OK 420586 B00–01 V0JF9Y cpuCru
1.3.313 SSC SSC CONFIGURED CNFG_OK 119669 A10–13 V0AZWZ sscCru
1.3.319 SSC SSC CONFIGURED CNFG_OK 119669 A10–13 V0AZS6 sscCru
1.3.314 IOC VME CONFIGURED CNFG_OK 108969 C09–10 D06LJ5 iocTiavSs7Cru
1.3.315 IOC VME CONFIGURED CNFG_OK 108969 D00–00 D0F021 iocTiavSs7Cru
1.3.316 IOC VME CONFIGURED CNFG_OK 136510 A00–00 D0M12C iocTiavTring-Cru
1.3.317 IOC VME CONFIGURED CNFG_OK 136510 A00–00 D0M2JH iocTiavTring-Cru
1.3.318 IOC ENET CONFIGURED CNFG_OK 125604 A01–01 V0B07U ioce2Cru
1.3.324 IOC ENET CONFIGURED CNFG_OK 125604 A01–01 V0B08L ioce2Cru
1.3.301 SCSI SCSI CONFIGURED CNFG_OK 124254 A06–08 D0KJHC devDsk4gbCru
1.3.302 SCSI SCSI CONFIGURED CNFG_OK 124254 A06–08 D0KJFD devDsk4gbCru
1.3.305 SCSI SCSI CONFIGURED CNFG_OK 112390 B11–19 D059VV devDdsCru
1.3.307 SCSI SCSI CONFIGURED CNFG_OK 124254 A04–06 D0AA0D devDsk4gbCru
1.3.308 SCSI SCSI CONFIGURED CNFG_OK 124254 A04–06 D0JXE8 devDsk4gbCru
1.3.311 SCSI SCSI CONFIGURED CNFG_OK 112462 B10–17 D05N8H devCdromCru
1.5.401 FAN FAN CONFIGURED CNFG_OK
1.5.402 FAN FAN CONFIGURED CNFG_OK
- Execute the following command. The test may take over 5 minutes to complete.
mds_snetev
- Verify that the test is successful.
An example of a successful test is shown below.
mds_snetev
mds_snetev: Processing Request, Please Wait; Version A02.00
–– This evaluation may take over 5 minutes.
–– Note: An attempt will be made to enable all disabled controllers.
scsi–0.hba–7: X Path enabled upon request.
nioc–1: Y Path enabled upon request.
scsi–1.hba–7: X Path enabled upon request.
scsi–0.hba–6: Y Path enabled upon request.
scsi–1.hba–6: Y Path enabled upon request.
nioc–0: X Path enabled upon request.
CONCLUSION: ServerNet OK
: system–1
- Execute the following command. The test usually takes 15 minutes to complete. It is a high load (–l high) test having a 15 minute timeout limit (–t 15) and a maximum of two full test cycles (–n 2)
tst_cdrom –l high –t 15 –n 2 /dev/rcdrom/cdrom1
- Verify that the test is successful.
An example of a successful test is shown below.
tst_cdrom –l high –t 15 –n 2 /dev/rcdrom/cdrom1
–––
Tester: tst_cdrom
PID: 8109
Test file: /dev/rcdrom/cdrom1
Time: Wed Jan 13 12:09:03 1999
Event: CDROM Test Started.
–––
CDROM Test Complete.
Reason: Completed All Requested Passes.
Errors: 0 Detected.
Passes: 2 Completed.
-
Execute the following command. The test usually takes XX minutes to complete. It is a low load (–l low) test having a 15 minute timeout limit (–t 15) and a maximum of two full test cyles (–n 2)
tst_tape –l low –t 15 –n 2 /dev/rmt/ctape1
- Verify that the test is successful.
An example of a successful test is shown below.
tst_tape –l low –t 15 –n2 /dev/rmt/ctape1
–––
Tester tst_tape
PID: 8122
Test File: /dev/rmt/ctape1
Time Wed Jan 13 12:29:07 1999
Event: Tape Test Started.
–––
Tape Test Complete.
Reason: Completed All Requested Passes.
Errors: 0 Detected.
Passes: 2 Completed.
- Execute the following commands to reset the SS7 cards.
cfreset ss7–0
cfreset ss7–1
- Execute the following commands. Wait for the first to complete before executing the second. The test will run 5 times on one port of one card.
tst_ss7 –l L –n 5 –b 0 –p 2048 –i –t 2m /dev/ss70/port0
tst_ss7 –l L –n 5 –b 0 –p 2048 –i –t 2m /dev/ss71/port0
- Verify that the test is successful.
An example of a successful test is shown below.
tst_ss7 –l L –n 5 –b 0 –p 2048 –i –t 2m /dev/ss70/port0
–––
Tester: tst_ss7
PID: 14301
Test Port: /dev/ss70/port0
Time: Wed Jan 13 12:40:21 1999
Event: SS7 Test Started.
<5>Jan 13 12:40:21 1 navajo3b unix:
<5>Jan 13 12:40:21 1 navajo3b unix: NOTICE: SS70: no error state is now 1
<5>Jan 13 12:40:22 1 navajo3b unix:
<5>Jan 13 12:40:22 1 navajo3b unix: NOTICE: SS70: no error state is now 1
<5>Jan 13 12:40:22 1 navajo3b unix:
<5>Jan 13 12:40:22 1 navajo3b unix: NOTICE: SS70: no error state is now 1
SS7_0: embedded code has been started
<5>Jan 13 12:40:22 1 navajo3b unix:
<5>Jan 13 12:40:22 1 navajo3b unix: NOTICE: SS70: no error state is now 2
<5>Jan 13 12:40:27 1 navajo3b unix:
<5>Jan 13 12:40:27 1 navajo3b unix: NOTICE: SS70: no error state is now 2
<5>Jan 13 12:40:27 1 navajo3b unix:
<5>Jan 13 12:40:27 1 navajo3b unix: NOTICE: SS70: no error state is now 2
<5>Jan 13 12:40:27 1 navajo3b unix:
<5>Jan 13 12:40:27 1 navajo3b unix: NOTICE: SS70: no error state is now 2
–––
Tester: tst_ss7
PID: 14301
Test Port: /dev/ss70/port0
Time: Wed Jan 13 12:40:48 1999
Event: SS7 Test Complete.
Reason: Completed All Requested Passes.
Errors: 0 Detected.
Passes: 5 Completed.
- Execute the following commands to reset the Token Ring cards.
cfreset tring–0
cfreset tring–1
- Execute the following commands. Each test usually takes 10 seconds (–t 10) to complete. The first test will transmit on TX of Token Ring card 0 and receive on RX of Token Ring card 1. The second test will transmit on TX of Token Ring card 1 and receive on RX of Token Ring card 0.
/usr/lib/tring/data –b 0 –e 1 –t 10
/usr/lib/tring/data –b 1 –e 0 –t 10
- Verify that the tests are successful. If the tests are successful go to Step 25. If the tests are unsuccessful go to Step 21.
An example of a successful test is shown below.
/usr/lib/tring/data –b 0 –e 1 –t 10
Running Tests between boards 1 & 0 for 10 secs. Please Wait...
777
TEST #0 PASSED SUCCESSFULLY
board 0, frames: 778 sent, 777 received, elapsed time 10 secs
/usr/lib/tring/data –b 1 –e 0 –t 10
Running Tests between boards 0 & 1 for 10 secs. Please Wait...
777
TEST #0 PASSED SUCCESSFULLY
board 0, frames: 778 sent, 777 received, elapsed time 10 secs
- Change the loopback cabling. Connect the TX and RX of Token Ring card 0 together and connect the TX and RX of Token Ring card 1 together.
- Execute the following commands to reset the Token Ring cards.
cfreset tring–0
cfreset tring–1
- Execute the following commands. Each test usually takes 10 seconds (–t 10) to complete. The first test will transmit on TX of Token Ring card 0 and receive on RX of Token Ring card 0. The second test will transmit on TX of Token Ring card 1 and receive on RX of Token Ring card 1.
/usr/lib/tring/data –b 0 –e 0 –t 10
/usr/lib/tring/data –b 1 –e 1 –t 10
- Determine which test fails. If the first test fails there is a problem with Token Ring card 0. If the second test fails, there is a problem with Token Ring card 1. If both tests fail, there is a problem with the system. Replace the Token Ring card that has a problem or call for help with the system.
An example of a successful test is shown below.
/usr/lib/tring/data –b 0 –e 0 –t 10
Running Tests between boards 0 & 0 for 10 secs. Please Wait...
777
TEST #0 PASSED SUCCESSFULLY
board 0, frames: 778 sent, 777 received, elapsed time 10 secs
/usr/lib/tring/data –b 0 –e 0 –t 10
Running Tests between boards 0 & 1 for 10 secs. Please Wait...
777
TEST #0 PASSED SUCCESSFULLY
board 0, frames: 778 sent, 777 received, elapsed time 10 secs
- Execute the following command to verify the memory size.
cfstatus –uV slice–0.cpu0
- Verify that the test is successful.
An example of a successful test is shown below.
cfstatus –uV slice–0.cpu–0
–– Processing Request, Please Wait...
Resource Path = slice–0.cpu–0
Specific Type = cpu
Identification = Integrity S4000 Processor
physicalPath = stack–1.mod–2.cru–202.cpu–1
ControlledBy = slice–0
ProvidedBy =
stack–1.mod–2.cru–202.cpu–1,stack–1.mod–2.cru–202,stack–1.mod–2.cru–201
### ISO States and Statuses ###
operational = Enabled
operationalEnhanced = Enabled
usage = Active
admin = Unlocked
procedural = Initialized, Not Initializing
availability = Not_Failed, Installed
### End ISO States and Statuses ###
physicalPartNumber = 138265
physicalSerialNumber = V0FETU
numberOfFailures = 0
functionalPath = slice–0.cpu–0
cru_type = CPU
cru_partid = 138265
cru_tracknumber = V0FETU
cru_revision = A01–02
nodeid = 0xF0000
memsize = 268435456
cache_size = 4194304
host = akchin7a
- After all the tests are completed, remove the scratch tape from the DAT drive, remove the disc from the CD–ROM drive, remove loopback cables from the Token Ring cards, and connect all cables back to the SS7 and Token Ring cards.
DNP MM Operational Tests
This test verifies that commands for operational activities that should be performed on a regular basis executes properly.
Test Procedure
-
To ensure that platform services and nodeMon are running, type :
# dkac
KID PID TYPE
-------------------------------------
watchd 868 DKA
statesvr(prim) 869 DKA
statesvr(bkup 878 DKA
ppm 875 SYSTEM
nodeMon 943 USER
If DNP keepalive is not running the following message will be shown:
Keepalive is not running
- To verify PRIMARY/BACKUP states, type :
# dnpc
( sample output)
Connecting to PPM...Connected
Sent Query Message to both nodes, waiting for reply...
Status of PPM on akchi3a:
Application status is PRIMARY
Split state is Unsplit
Inhibit state is Uninhibited
Status of PPM on akchi3b:
Application status is BACKUP
Split state is Unsplit
Inhibit state is Uninhibited
-
To verify Supercell processes are alive, type mmprocs.
-
To ensure that both nodes are synchronized, type execute cbsc–# checkpoint
-
To status switchable resources, type resstatus.
(sample output)
Application Resource SlotNumber NodeName Status RecLevel DuplResources
ALL nioc-2 1.3.318 akchi3a Enabled major nioc-3
ALL nioc-3 1.3.324 akchi3a Enabled major nioc-2
ALL tring-0 1.3.316 akchi3a Enabled major tring-1
ALL tring-1 1.3.317 akchi3a Enabled major tring-0
ALL ss7-0 1.3.314 akchi3a Enabled major ss7-1
ALL ss7-1 1.3.315 akchi3a Enabled major ss7-0
-
To check status of non-switchable resources, type cfstatus. All device status should be Enabled Not_Failed.
-
To check disk usage and status, type vxprint -A. All plex and volume state should be on ENABLED.
Pass/Fail Criteria:
All commands should execute without any errors and as required in the procedures.
DNP Functionality Tests
Node Swap
This test verifies that the two nodes properly swaps state from BACKUP to PRIMARY.
Test Procedure
-
Login to the omc as scadm and start a CLI session. Display the status of the CBSC by typing
display cbsc-1 allstatus
display cbsc-1 allsta oos
- Make a CDMA M-M call. The call should be successful.
- Login to the MM by typing rsh mm1. Then change the user to root. Check the NODE status by typing:
# dnpc
( sample output)
Connecting to PPM...Connected
Sent Query Message to both nodes, waiting for reply...
Status of PPM on akchi3a:
Application status is PRIMARY
Split state is Unsplit
Inhibit state is Uninhibited
Status of PPM on akchi3b:
Application status is BACKUP
Split state is Unsplit
Inhibit state is Uninhibited
-
To swap the nodes, type
# dnpc -o swap
Call processing will momentarily be affected as the system switches resources. Alarms will be generated at the OMC. OMC-MM communication will be disrupted.
-
At the OMC window, type ping mm1 . The response should state the MM-1 is alive.
Rlogin to the MM and type dnpc. Check if the node which was on BACKUP is now acting as the PRIMARY node, and the PRIMARY went to BACKUP status. It takes a few minutes for the BACKUP node to re-initialize.
-
At the omc CLI window, execute the command audit cbsc-1 dbsync. The command should complete without any errors.
-
Check the status of the CBSC by typing display cbsc-1 allsta oos. All OOS devices should be only those devices that were OOS before the node swap.
- Make a CDMA call. The call should be successful.
Pass/Fail Criteria:
The node swap should complete successfully, with no errors and the CBSC should stay in INS status throughout the process. CDMA calls should be successful after the SWAP.
OMC-R Operational Tests
This test verifies that commands for operational activities that should be performed on a regular basis executes properly.
Test Procedure
-
To ensure that system devices are ok , type :
# cfstatus
All devices should be on ONLINE s tate.
- To verify system disk volume and plex states, type :
# volprint -pt
All volume and plex state should be ENABLED ACTIVE.
-
To verify Supercell processes are alive, type omcprocs.
Pass/Fail Criteria:
All commands should execute without any errors and as required in the procedures.
XC FUNCTIONALITY TEST
The following equipment is required to verify XC functionality:
- Electronic Mobile Exchange (EMX)
- Operational CBSC
- Operational BTS
- Operational CDMA Mobile
FEP Redundancy test
This test verifies FEP redundancy. A FEP will be removed and the redundant FEP will then transition to the active state.
Test Procedure
-
At the OMCR-CLI, enter the following command to display the CBSC status:
omcr-000098 > display cbsc-1 status
A listing of all devices associated with that CBSC will be shown along with their present status. Verify that the FEP is INS_ACTIVE and the FEPR is INS_STBY state.
Then execute the command:
omcr-000098 > display fep-1-A linkconf (where A is the FEP number)
A listing of configured BTSLINK and XCLINK associated with the FEP will be shown. Note the BTSLINK being controlled by the FEP. Use this BTS to test the FEP redundancy feature.
- Place a call under the BTS. A successful call will confirm the BTS is ok.
-
Toggle the FEP switch to disable and pull out the FEP controlling the BTS which is INS_ACTIVE. An alarm will be generated by the system and the redundant FEP (FEPR) will transition to INS_ACTIVE state. The FEP that was pulled should go to OOS_AUTO state. The redundant FEP should take over the BTSLINK and XCLINK being controlled by that FEP. Do a display bts-xxx status to confirm that the BTS is still is service. Also do a status of the XCLINK to confirm that it is in service.
-
Place another call to confirm the FEP redundancy feature. The call should be successful.
-
Reinsert the pulled FEP. Toggle the switch from disable to reset then the middle. Access the XC-CLI window and do a status of the FEP by executing disp_dev_stat 0 fep x 0 0. The FEP should be in Unlocked Disabled state. Do the following commands to reintegrate the FEP to the system:
lock 0 fep x 0 0
Wait untill the FEP status is in Locked Enabled state, then do
unlock 0 fep x 0 0
Make sure that the FEP state is in Unlocked Busy state by entering the command disp_dev_stat 0 fep x 0 0.
At the OMCR-CL window, enter the command enable FEP-1-X (where X is the FEP). The FEP will transition to INS_ACTIVE state, and FEPR will change back to INS_STBY state. All associated links should return to the FEP.
- Place another CDMA call to make sure the BTS is functioning.
Pass/Fail Criteria:
The redundant FEP should replace the active FEP. A CDMA call should be successful after the FEPR takes over.
GCLK Redundancy test
This test verifies GCLK redundancy. The active GCLK will be removed and the redundant GCLK will then transition to the active state.
Test Procedure
-
At the OMCR-CLI, enter the following command to display the CBSC status:
omcr-000098 > display cbsc-1 status
A listing of all devices associated with that CBSC will be shown along with their present status. Verify that the CBSC and all BTSs are in service.
At the XC-CLI window, enter the command disp_eq 0 status location to check the status of all XC devices. Make sure that one of the GCLK is in Unlocked Busy state and the other is on Unlocked Enabled state.
- Place a CDMA call. The call should be successful.
-
Toggle the GCLK switch to disable and pull out the GCLK. Alarms will be generated by the system and the redundant GCLK will transition to Unlocked Busy state while the pulled GCLK will transition to Unlocked Disabled state.
Do a display cbsc-1 status to confirm that the CBSC is still is service.
-
Place another call to confirm the GCLK redundancy feature. The call should be successful.
-
Reinsert the pulled GCLK. Toggle the switch from disable to reset then the middle. Access the XC-CLI window and do a status of the GCLK by executing disp_dev_stat 0 gclk x 0 0. The GCLK should be in Unlocked Disabled state. Do the following commands to reintegrate the GCLK to the system:
lock 0 gclk x 0 0
unlock 0 gclk x 0 0
Make sure that the GCLK state is in Unlocked Busy state by entering the command disp_dev_stat 0 gclk x 0 0.
-
Do another display cbsc-1 status to make sure the system is ok. Place another CDMA call to confirm CDMA call processing is still functioning.
Pass/Fail Criteria:
The redundant GCLK should replace the active GCLK. A CDMA call should be successful after the redundant GCLK takes over.
LAN Redundancy test
This test verifies LAN redundancy. A LANX card connection will be removed and the redundant LANX will then transition to the active state.
Test Procedure
-
At the OMCR-CLI, enter the following command to display the CBSC status:
omcr-000098 > display cbsc-1 status
A listing of all devices associated with that CBSC will be shown along with their present status. Verify that one of the MMXCLAN is INS_ACTIVE and the other is in INS_STBY state.
At the XC-CLI window, enter the command disp_eq 0 status location to check the status of all XC devices. Make sure that one of the LAN is in Unlocked Busy state and the other is on Unlocked Enabled state.
- Place a CDMA call. The call should be successful.
- Remove both fiber optic cables of the active LAN to simulate LAN failure. Alarms will be generated by the system and the redundant MMXCLAN will transition to INS_ACTIVE state. The MMXCLAN that was pulled should go to OOS_AUTO state. The redundant lanx card should take.
-
Do a display cbsc-1 status to confirm that the CBSC is still is service. Also do a status of the lanx at the XC-CLI to confirm that it is in Unlocked Busy state. The failed lanx card should be in Unlocked Disabled state.
-
Place another call to confirm the LAN redundancy feature. The call should be successful.
-
Reinsert the pulled fiber optic cables. Access the XC-CLI window and do a status of the lanx card by executing disp_eq 0 status location. The lanx should be in Unlocked Enabled state.
At the OMCR-CL window, enter the command ena mmxclan-1-x unc (where X is the other MMXCLAN). The MMXCLAN will transition to INS_STBY state.
- Execute the command swap mmxclan-1-x at the OMCR-CLI to swap the active lan.
- Place another CDMA call. The call should be successful.
Pass/Fail Criteria:
The redundant MMXCLAN should replace the active MMXCLAN. A CDMA call should be successful after the redundant MMXCLAN takes over.
OMP Redundancy test
This test is to make sure that the XC does not reboot in the event of the active OMP failure and the redundant OMP takes over.
Test Procedure
-
At the OMCR-CLI, enter the following command to display the CBSC status:
omcr-000098 > display cbsc-1 status
A listing of all devices associated with that CBSC will be shown along with their present status.
At the XC-CLI window, enter the command disp_eq 0 status location to check the status of all XC devices.
Execute the command disp_dev_stat 0 gproc 0 0 0 to give the OMP status which should be in Unlocked Busy state. The OMP is located at cage 0, slot 20.
Check the OMPR status by typing disp_dev_stat 0 gproc 1 0 0. The OMPR should be in Unlocked Enabled state. The OMPR is located at cage 1, slot 20.
- Place a CDMA call. The call should be successful.
-
On the XC-CLI window, change to level 3 environment by doing chg_level command. The passwords are to be typed in order - 3stooges , 4beatles.
Enter the command lock 0 gproc 0 0 0 to disable the OMP. The OMPR should transition to Unlocked Busy state.
-
Do a display cbsc-1 status at the OMCR-CLI window to confirm that the CBSC is still is service. At the XC-CL window, enter disp_eq 0 status location to check all XC devices which should be unlocked busy. The XC should not reboot!
-
Place another call to confirm the OMP redundancy feature. The call should be successful.
-
Recover the OMP by executing the command unlock 0 gproc 0 0 0. The OMP should go back to Unlocked Busy state.
At the OMCR-CLI window, check the CBSC status with the command disp cbsc-1 allsta. The CBSC should still be in service.
- Place another CDMA call. The call should be successful.
Pass/Fail Criteria:
The redundant OMP should replace the active OMP. A CDMA call should be successful after the redundant OMP takes over.
Cage Controller Redundancy test
This test is to make sure that the XC does not reboot in the event of the active cage controller failure and another cage controller takes over.
Test Procedure
-
At the OMCR-CLI, enter the following command to display the CBSC status:
omcr-000098 > display cbsc-1 status
A listing of all devices associated with that CBSC will be shown along with their present status.
At the XC-CLI window, enter the command disp_eq 0 status location to check the status of all XC devices.
Execute the command disp_cage_ctrl to give the list of active cage controllers. All cage controller gprocs should be in Unlocked Busy state. Note down the GPROC ID of the cage controller you wish to test.
- Place a CDMA call. The call should be successful.
-
On the XC-CLI window, change to level 3 environment by doing chg_level command. The passwords are to be typed in order - 3stooges , 4beatles.
Enter the command lock 0 gproc X 0 0 (where X is the gproc number) to disable an active cage controller. The system will prompt you that there is a candidate cage controller. The GPROC should transition to Locked Enabled state.
-
Do a display cbsc-1 status at the OMCR-CLI window to confirm that the CBSC is still is service. At the XC-CL window, enter disp_eq 0 status location to check all XC devices. The XC should not reboot!
Execute the command disp_cage_ctrl at the XC-CLI to check which GPROCs are now the active cage controllers.
-
Place another call to confirm the cage controller redundancy feature. The call should be successful.
-
Recover the GPROC by executing the command unlock 0 gproc X 0 0. The GPROC should go back to Unlocked Busy state.
At the OMCR-CLI window, check the CBSC status with the command disp cbsc-1 allsta. The CBSC should still be in service.
- Place another CDMA call. The call should be successful.
Pass/Fail Criteria:
A candidate cage controller GPROC should take over the failed active cage controller GPROC. A CDMA call should be successful after the switch.
BTS FUNCTIONALITY TEST
The following equipment verifies BBX redundancy:
- Electronic Mobile Exchange (EMX)
- Operational CBSC
- Operational BTS
- Operational CDMA Mobile
BTS Power Loss
To verify an active BTS will return to the in-service state when a loss of power occurs at the BTS. An operational BTS will have its power source removed while in-service, once the power is reapplied the BTS will be returned to an operational state.
Test Procedure
-
At the OMCR-CLI, enter the following command to display the BTS status:
omcr-000098 > display bts-<bts#> status
A listing of all devices associated with that BTS will be shown along with their present status.
- Make a CDMA call under that BTS. The call should be successful.
- While the BTS is in-service, remove the power source by either pulling the breakers or shutting off the main power at the distribution point. Several alarms should be generated by the activity. The BTS devices will transition from INS to OOS in the events log.
-
Do a display bts-<bts#> status to check the BTS status. The BTSLINK should be in OOS_AUTO state while the other devices on OOS_PARENT state.
-
Re-apply power to the BTS. The BTSLINK should come INS_ACTIVE automatically. This can be checked with the display bts-<bts#> status command.
All BTSLINK child devices should undergo software loading and transition to INS. To check the progress of the devices, execute the command sta <device ID> phy, looking at the PROCEDURE state if its either DOWLOAD, INITIALIZE, etc. The devices should go INS one after the other.
BTS loading time is as follows:
MGLI - 10 min. per device.
CSM - maximum of 30 mins to DOWNLOAD, INITIALIZE and STABILIZE.
BBX - 7 min. per device.
MCC - 7 min. per device.
-
When all the BTS devices are back in service, make a CDMA call under that BTS to confirm it is OK.
- On cases wherein child devices does not come back INS automatically, recovery can be done by executing the commands at the OMCR-CLI:
disa <device ID> unc
ena <device ID> unc / load <device ID>
Pass/Fail Criteria:
The BTS should come back INS after a power loss. A successful CDMA call should be done after full BTS recovery.
MGLI Redundancy test
This test verifies MGLI redundancy. An MGLI will be removed and the other MGLI will then transition to the active state.
Test Procedure
-
At the OMCR-CLI, enter the following command to display the BTS status:
omcr-000098 > display bts-<bts#> status
A listing of all devices associated with that BTS will be shown along with their present status. Verify that one of the MGLI is INS_ACTIVE and the other is in INS_STBY state.
-
Pull out the active MGLI. A major alarm will be generated by the system and the other MGLI will transition to INS_ACTIVE state. The MGLI that was pulled should go to OOS_AUTO state.
-
Reinsert the pulled MGLI and enter the command enable MGLI-XXX-B (where XXX is the BTS number and B is the MGLI number). The MGLI will transition to INS_ACTIVE state and the other MGLI will change back to INS_STBY state.
Pass/Fail Criteria:
The redundant CSM should replace the active MGLI and does not bring down its child devices (CSM, BBX and MCC).
BBX Redundancy test
This test verifies BBX redundancy. A BBX will be removed and the redundant BBX will then transition to the active state.
Test Procedure
-
At the OMCR-CLI, enter the following command to display the BTS status:
omcr-000098 > display bts-<bts#> status
A listing of all devices associated with that BTS will be shown along with their present status. Verify that the BBX is INS_ACTIVE and the BBXR is INS_STBY state.
-
Pull out one of the BBX which is INS_ACTIVE. A major alarm will be generated by the system and the redundant BBX (BBXR) will transition to INS_ACTIVE state. The BBX that was pulled should go to OOS_AUTO state.
-
Reinsert the pulled BBX and enter the command enable bbx-XXX-B (where XXX is the BTS number and B is the BBX number). The BBX will transition to INS_ACTIVE state and BBXR will change back to INS_STBY state.
Pass/Fail Criteria:
The redundant CSM should replace the active CSM and does not bring down its child devices (MCC).
CSM Redundancy test
This test verifies CSM redundancy. The active CSM will be removed and the redundant CSM will then transition to the active state.
Test Procedure
-
At the OMCR-CLI, enter the following command to display the BTS status:
omcr-000098 > display bts-<bts#> status
A listing of all devices associated with that BTS will be shown along with their present status. Verify that CSM-1 is INS_ACTIVE and the CSM-2 is INS_STBY state.
-
Pull out CSM-1 which is INS_ACTIVE. A major alarm will be generated by the system and the redundant CSM (CSM-2) will transition to INS_ACTIVE state. The CSM that was pulled should go to OOS_AUTO state.
-
Reinsert the pulled CSM and enter the command enable CSM-XXX-1 (where XXX is the BTS number). CSM-1 will transition to INS_ACTIVE state and CSM-2 will change back to INS_STBY state.
Pass/Fail Criteria:
The redundant CSM should replace the active CSM and does not bring down its child devices (BBX and MCC).
MM initsiim Functionality Test
After initializing the Supercell Processes in the MM, the CBSC should be enabled to go back INS.
Test Procedure
-
At the OMCR-CLI, enter the following command to display the BTS status:
omcr-000098 > display cbsc-1 status
A listing of all devices associated with that CBSC will be shown along with their present status.
- Make a CDMA call. The call should be successful.
-
Log on to the MM by executing rlogin mm-1 command at the OMCR. Check the MM Processes by executing the mmprocs command.
-
Execute the command scsiim_init mm-1 level=2 at the MM to restart all SC processes. To monitor the SC processes, execute the command tscsiim. Wait untill the "INIT indication" line and the last SC process (FepMon process) is brought up. This will signal that re-init of all SC processes are completed. Type control+c to exit the window.
- At the OMCR-CLI window, the CBSC status should be on OOS_AUTOMATIC state.
-
Bring up the CBSC with the enable cbsc-1 unc command. All devices should go back to pre-init states.
- Make a CDMA call. The call should be successful.
Pass/Fail Criteria:
The CBSC should come back INS after an scsiim_init command is done. A successful CDMA call should be done after full CBSC recovery.
OMC initsiim Functionality Test
After initializing the Supercell Processes of the OMC, Operation and Maintenance commands should not be affected.
Test Procedure
-
At the OMCR-CLI, enter the following commands for operations and maintenance activity:
omcr-000098 > display cbsc-1 status
omcr-000098 > display bts-XXX status
omcr-000098 > audit cbsc-1 dbsync
omcr-000098 > disa mmxclink-1-1-x
omcr-000098 > ena mmxclink-1-1-x
All commands should complete with no errors.
-
Log on to the OMCR by executing rlogin omc command at the OMCR. Check the OMCR Processes by executing the omcprocs command.
-
Execute the command scsiim_init omc level=2 at the OMC to restart all SC processes. To monitor the SC processes, execute the command tscsiim. Wait until the "INIT indication" line is shown. This will signal that re-init of all SC processes are completed. Type control+c to exit the window.
- At the OMCR-CLI window, execute the same commands as in step 1.
All commands should not fail
Pass/Fail Criteria:
The CLI function of the OMC should still be functioning normally after an init of the OMC SC processes.
OMC-R power cycle
This test is to ensure the Operations and Maintenance Center - Radio (OMC-R) machine will recover in a case of a shutdown/power loss.
Test Procedure
-
Login as ROOT at the omc console and enter the command to shutdown the machine :
# shutdown -i0 -g0 -y
The system will shut down and wait until the >> prompt appears.
- Access the back of the cabinet and at the SP patch panel cards, rotate the two knobs from ON to STANDBY to OFF. This will turn the power off to the system.
- After 1 minute, rotate back the SP knobs from OFF to STANDBY to ON position. Power again applied to the machine.
- At the OMCR console terminal, observe the messages while the system boots up. DO NOT INTERRUPT THE BOOT UP SEQUENCE. Boot up procedure completes when the "Console Login:" prompt appears. SC processes re-init completes when the "Sec_Mgmt completes" message appears.
-
Do a # /etc/cfstatus command to make sure that all devices are ONLINE. Execute a #/usr/sbin/volprint -pt to check the status of all plexes and volumes and make certain their status is ENABLED.
All commands should not fail and devices are in service.
Pass/Fail Criteria:
The system should go back inservice, recognizing all devices, re-initializing all processes, and that all system disks are functional.
DNP-MM power cycle
This test is to ensure the Dual Node Puma - Mobility Manager (DNP-MM) machine will recover in a case of a shutdown/power loss.
Test Procedure
-
Login as ROOT at the MM console and check the status of the two nodes with the command :
# dnpc
One of the nodes (mm1a or mm1b) should be in PRIMARY and the other node in BACKUP. Both nodes should be in UNSPLIT and UNINHIBITED status.
-
Shutdown the system by typing the following commands on the BACKUP node:
# dnpc -o inhibit - To put the node in MAINTENANCE - INHIBITED state.
# dnpc - Check the node state if it is correct.
# shutdown -i0 -g0 -y - To shutdown the node.
Enter " ~. " To escape the host and go to the SP prompt (MSP0 or MSP1).
sysstatus - To check the status of the node. The backup node should
have a status of OS DOWN WARM
The same commands should also be done to the PRIMARY node.
-
After both nodes are in OS DOWN WARM status when a sysstatus command is executed at the SP prompt, toggle the main power breakers to OFF. They are found in front of the cabinet, topmost portion. This will disable the power to the system.
- After 1 minute, toggle both the breakers to ON. The system will reboot. Monitor the re-init messages at the MM console terminal. System OS reboot is completed when the "Console Login" prompt is seen.
-
A dnpc command will state that both nodes are in the MAINTENANCE - INHIBITED state. Recover the system by doing the following commands on any of the nodes (mm1a or mm1b):
# dnpc -o uninhibit - This will transition the node to PRIMARY - UNINHIBITED.
And will allocate the shared resources (SS7, Tring, and
Enet controllers) to the node and init the SC processes.
Do the same on the other node to put it in BACKUP - UNINHIBITED state.
- Do the following commands to check the system status:
# dnpc - Check node status. One node should have a PRIMARY - UNSPLIT
- UNINHIBITED state and the other on BACKUP - UNSPLIT -
UNINHIBITED.
# cfstatus - All devices should be in ENABLED NOT_FAILED state.
# vxprint -a - Plexes should be in ENABLED state.
Pass/Fail Criteria:
The system should go back in service, recognizing all devices, re-initializing all processes, and that all system disks are functional.
Transcoder power cycle
The objective of this test is to verify that the cards in the Transcoder (XC) will achieve a known good state after power is cut-off and turned back on.
The following equipment is required to verify this test:
- Transcoder cabinet
- Transcoder PC (XCPC)
- Multi-system Access Unit (MAU)
Test Procedure
-
Log on to the OMC-R as scadm. At the prompt, enter the command 'tqcomm a0'. This will access the XC CLI. Do a 'disp_eq 0 staus location' command to note all the XC card status.
- Turn the breakers at the breaker panel of the XC to OFF position.
- Wait for 1 minute and turn the breakers back to ON. Reset the XC by following the procedures below.
- toggle the OMP (located at cage 0, slot 20) to reset. Then toggle the DSW cards (located at cage 0, slot 1 and 27 ; cage 1, slot 1 and 27).
- Wait for 30 seconds, then toggle the rest of the GPROC cards.
- Observe the XC CLI window. The XC reboot messages should state that there is "no valid database found - waiting for XC PC connection".
- Turn on the XCPC computer. Connect the RJ-45 cable at the Ancillary cabinet to the ODS adapter slot at the back of the XCPC (located at slot 2). Connect the other end of the RJ-45 cable to slot 1 of MAU-a (the left MAU module).
- At the XCPC, click the Start button, go to Programs, and click on Lanload. This will initiate the Lanload program. Observe the init messages and make sure the lan adapter successfully initializes.
-
Click the Utilities menu. Unclick the options - Forced download , Fast Download Mode, & Large Config Mode. The Broadcast menu can then be selected.
-
Click on the Edit Object Directory List option and a window with the XC codes will appear. Make sure the path is correct. Click the View code Obj list and make sure the 002 codes are present.
-
Click the Broadcast option. The XCPC will then download the codes to the XC. A small window will appear that shows the downloading of the codes. Wait until all codes are downloaded. The XC will then continue initialization.
- XC initialization complete message should be seen at the XC CLI window and the Cust0115 prompt should appear. Check all device status. All device status should be the same as before the activity.
Pass/Fail Criteria:
The XC should initialize properly, downloading the correct codes from the XCPC via the MAU.