Previous page Next page

Loss of Signal Alarm Inquiry Test (#138)

This test verifies the synchronization status, echo cancellation, and continuity of the DS1 link. The Loss of Signal alarm indicates that the MM710 Interface Media Module is unable to derive the synchronization clock from the DS1 facility. When the MM710 Interface Media Module detects a Loss of Signal alarm, it stops providing the synchronization clock for the system, if it is administered as a timing source, and transmits a Yellow alarm to the remote DS1 endpoint.

Note: Synchronization is not administered from the SAT. It is administered via a CLI session with the G700 Media Gateway Processor.

When the Loss of Signal alarm is confirmed, maintenance software places all trunks or ports of the MM710 Interface Media Module into the out-of-service state. The inquiry test will run every 10 minutes until the loss of signal has been restored.

The MM710 Interface Media Module raises a Loss of Signal alarm after the signal has been lost for about 1 second. It will not retire the alarm until the signal has returned for about 10 seconds.

Echo Cancellation

If the MM710 firmware detects a serious echo canceller hardware error, it notifies maintenance software. When the maintenance subsystem receives notification of the echo cancellation error, it executes this Loss Of Signal Alarm Inquiry test.

This test, in addition to querying for a loss of signal condition and CSU errors, also queries MM710 to confirm the echo canceller error. A minor alarm is raised if the error is confirmed. The trunks of the board remain in-service since the board is still functional except for the echo cancellation capability.

If a loss of signal condition co-exists with CSU and/or echo canceller errors, the loss of signal condition takes priority, and the board and all trunks on the board are put in the out-of-service state. Errors are logged, however, for each error type.

When the maintenance subsystem receives notification that the echo canceller hardware error condition no longer exists, the maintenance subsystem restores the board and all trunks to their previous service state, if the alarm can be cleared (no other CSU errors or loss of signal conditions exist).

Note: The DSU functionality is not available in this release of AVAYA G700 systems software.

Table 65. TEST #138 Loss of Signal Alarm Inquiry Test �
Error Code
Test Result
Description/ Recommendation
ABORT
Internal system error
Retry the command at 1-minute intervals for a maximum of 5 times.
2000
ABORT
Response to the test was not received within the allowable time period. This may be due to hyperactivity. Error Type 1538 in the error log indicates hyperactivity. The hyperactive Media Module is out of service and one or more of the following symptoms may be exhibited.
The DS1-MM tests (such as Test #138 and Test #139) are aborting with error code 2000.
The tests run on the ports of this Media Module are returning a no board result.
A busyout or a release command has no affect on the test results.
A list config command shows that the Media Module and the ports are properly installed.
When hyperactivity occurs, the Media Module is isolated from the system, and all of the trunks for this Media Module are placed into the out of service state. The system will try to restore the Media Module within 15 minutes. When no faults are detected for 15 minutes, the DS1-MM (MM710) interface Media Module is restored to normal operation. All of the trunks for the Media Module are then returned to the in service state. Hyperactivity is often caused by the associated facility. In such a case, faults (such as slips, misframes, or blue alarms) would be entered in the error log. In addition, many hardware errors would be logged against the associated trunk circuits. If the facility is OK and the error occurs again after 15 minutes, replace the Media Module.
2100
ABORT
Could not allocate the necessary system resources to run this test.
Retry the command at 1-minute intervals for a maximum of 5 times.
FAIL
DS1-MM detects a Loss of Signal alarm. The physical link is broken or the remote DS1 endpoint is down. All trunks or ports of this MM710 are out-of-service. If the DS1-MM connects to a T1 network facility:
If the MM710 connects to a T1 facility, call the vendor of the T1 carrier to diagnose the remote DS1 endpoint. If the MM710 Interface Media Module connects directly to a switch, call the system technician of the remote switch to diagnose the DS1 endpoint.
If the DS1-MM connects to a line-side terminating device such as a PRI terminal adapter: Contact the vendor of the line-side terminating device to diagnose the equipment.
Check the physical connection of the MM710 Interface Media Module and the cable.
Check the physical connection of the MM710 Interface Media Module to the terminating device. Check premise distribution system (or intra-premise wiring) for physical connection failures.

1400
FAIL
Echo Canceller Function failed, this could be a hardware problem on the MM710:
Issue the busyout board command.
Issue the test board long command.
Issue the release board command.
If Test 1420 still fails, replace the board.
1401
FAIL
Echo Canceller Function failed, this could be a hardware problem on the MM710:
Issue the busyout board command.
Issue the reset board command.
Issue the test board long command.
Issue the release busy board command.
If the test still fails replace the board.
PASS
DS1 signal is present and the physical link is healthy.
Any
NO BOARD
The test could not relate the internal ID to the port (no board). This could be due to incorrect translations, no board is inserted, an incorrect board is inserted, or an insane board is inserted.
Ensure that the board translations are correct. Execute the add ds1 GGGVS command to administer the DS1-MM interface if it is not already administered.
If the board was already administered correctly, check the error log to determine whether the board is hyperactive. If this is the case, the board is shut down. Reseating the board will re-initialize the board.
If the board was found to be correctly inserted in step 1, then issue the busyout board command.
Issue the reset board command.
Issue the release busy board command.
Issue the test board long command.
This should re-establish the linkage between the internal ID and the port.


Previous page Next page