Maintenance Messages and Procedures

ISUP provides an entire category of messages that are commonly categorized as "maintenance" messages. Until now, this chapter has focused on the call processing aspect of ISUP. This section discusses those messages that are used for diagnostics, maintenance, and the manipulation of ISUP facilities outside of the normal call processing realm.

The exchange can autonomously generate some maintenance messages, such as blocking (BLO) and Continuity Check Request (CCR), in response to an event or invoked manually by maintenance personnel. The collective set of messages described here helps to maintain trunk facilities and the integrity of user traffic. When necessary, trunks can be blocked from user traffic, tested, and reset to a state of sanity. The following sections illustrate how ISUP maintenance is used to accomplish these tasks:

• Circuit Ranges

• Circuit States

• Circuit Validation

• Continuity

• Blocking and Unblocking Circuits

• Circuit Reset

Circuit Ranges

ISUP maintenance messages apply to the CIC that is designated in the ISUP message. However, many messages can be applied to a range of CICs. These messages are referred to as "group" messages. Since ISUP trunk circuits are usually multiplexed together on digital spans, an action must often be applied to a larger group of circuits, such as the entire span. If a span is removed from service or brought into service, ISUP messages are sent to update the status of each of the span's circuits. If multiple spans are involved and individual messages were sent for each circuit, a flood of messages would occur over the SS7 network. Not only does this consume additional bandwidth on the SS7 links, but it also requires more processing by both the sending and receiving nodes. Using a single message with a CIC range eliminates the need to send a message for each CIC. Blocking messages, which we discuss later in this section, are a good example of where ranges are often used.

It is important to be aware that a message range can only be sent for contiguous CICs. If a span's CIC ranges were numbered using only even numbers such as 0, 2, 4,and 6, a message with a CIC range could not be used; individual messages would have to be sent for each CIC. It is good practice to number a span's CICs contiguously to maximize the efficiency of CIC ranges and effectively minimize message traffic.

Circuit States

An exchange maintains a circuit state for each bearer channel. Maintenance procedures and messages can affect that state. For example, maintenance messages can be sent to make circuits available for call processing, remove them from service, or reset them. A trunk circuit can have one of the following states:

• Unequipped— Circuit is not available for call processing.

• Transient— Circuit is waiting for an event to occur in order to complete a state transition. For example, an REL message has been sent, but an RLC has not been received.

• Active— Circuit is available for call processing. The circuit can have a substate of idle, incoming busy, or outgoing busy.

• Locally blocked— The local exchange has initiated the blocking of the circuit.

• Remotely blocked— The remote exchange has initiated the blocking of the circuit.

• Locally and remotely blocked— Both the local and remote exchanges have initiated blocking.

The following messages are used for querying the state of a group of circuits. These messages are usually sent in response to maintenance commands entered at a maintenance interface, or by automated trunk diagnostics that are performed as part of routine trunk testing.

• Circuit Query Message (CQM)— Sent to the far end exchange to query the state of a group of circuits. This allows the states to be compared to ensure that the two nodes agree on the status of the facilities. It provides a safeguard against a state mismatch in the event that a message indicating a change of state is sent, but not received.

• Circuit Query Response Message (CQR)— Sent in response to a CQM to report the state of the requested group of circuits.

Circuit Validation (ANSI Only)

Circuit validation determines whether translations data specific to the selection of an ISUP circuit has been set up correctly. The translations data at both ends of a circuit and between two exchanges is verified to ensure that the physical bearer channel can be derived. All switching systems require provisioning data to create the proper associations between trunkgroups, trunk members, CICs, and physical trunk circuits. Circuit Validation testing traverses these associations to ensure that they have been properly created. The Circuit Validation Test is particularly useful when turning up new trunk circuits because there is a greater potential for errors in newly provisioned facilities.

The Circuit Validation Test is typically invoked through a user interface at the switching system. Translations data at the local end is verified before sending a CVT message to the far end. The following messages are exchanged to perform the test:

• Circuit Validation Test (CVT)— Sent to the far end exchange to validate circuit-related translations data for an ISUP circuit. This message is only used in ANSI networks.

• Circuit Validation Response (CVR)— Sent in response to a CVT message to report the results of a Circuit Validation Test. The CVR message reports a success or failure for the Circuit Validation Test, along with characteristics of the circuit group being tested. For example, one reported characteristic is the method of glare handling being used for the circuit group. This message is only used in ANSI networks.

Continuity Testing

We have discussed continuity testing in the context of call processing where a circuit is tested before setting up a call. Continuity testing can also be performed manually by maintenance personnel, or by automated facilities testing.

The maintenance test procedure is slightly different than when it is performed as part of call processing. You will recall from the section on continuity testing that an indicator in the IAM is used for signifying that a test is required. When invoked as part of a maintenance procedure, the Continuity Check Request (CCR) message is used to indicate that a continuity test is required. The CCR is sent to the far end, and the continuity test proceeds as we discussed previously. The far end sends back a Loop Back Acknowledgement to acknowledge that a loop back or transceiver circuit has been connected for the test. The results are reported using a COT message by the node that originated the test. For additional information on continuity testing, refer to the "Continuity Test" section of this chapter. The following messages are used during the maintenance initiated continuity test:

• Continuity Check Request (CCR)— Sent to the far end to indicate that a continuity test is being performed. The far end connects a loopback or transceiver for the test.

• Loop Around (LPA)— Sent in response to a CCR to indicate that a loop back or transceiver has been connected to a circuit for continuity testing.

• Continuity Test (COT)— Sent to the far end to report the results of the continuity test. Indicates success if the received COT tones are within the specified guidelines of the country's standards. Otherwise, the message indicates a failure.

Blocking and Unblocking Circuits

ISUP provides blocking to prevent call traffic from being sent over a circuit. Maintenance messages can continue to be sent over the circuit. The two primary reasons for blocking are to remove a circuit from use when a problem has been encountered, or to allow for testing of the circuit. The local software blocks a trunk's local end. A blocking message notifies the trunk's far end about blocking. Unblocking is performed when circuits are ready to be returned to service for call traffic. The exchange unblocks locally and sends an unblocking message to the far end to provide notification of the state change. Both blocking and unblocking messages are acknowledged to ensure that both ends of the circuit remain in sync concerning the state of the trunk. The following messages are used in blocking and unblocking circuits:

• Blocking (BLO)— Sent to the far end to indicate the blocking of a circuit.

• Blocking Acknowledgement (BLA)— Sent as an acknowledgement in response to a BLO.

• Circuit Group Blocking (CGB)— Sent to the far end to indicate blocking for a range of circuits. The CICs must be contiguous for the group of circuits being blocked.

• Circuit Group Blocking Acknowledgement (CGBA)— Sent as an acknowledgement in response to a CGB.

• Unblocking (UBL)— Sent to the far end to indicate the unblocking of a blocked circuit.

• Unblocking Acknowledgement (UBA)— Sent as an acknowledgement in response to a UBL.

• Circuit Group Unblocking (CGU)— Sent to the far end to indicate unblocking for a range of blocked circuits.

• Circuit Group Unblocking Acknowledgment (CGUA)— Sent as an acknowledgement in response to a CGU.

Circuit Reset

A circuit is reset as an attempt to recover from an error condition or an unknown state. There are several reasons a circuit might need to be reset. Memory corruption or a mismatch of trunk states by the trunk's local and remote ends are examples of the need to reset a circuit. Calls are removed if they are active on the circuit that is being reset. A circuit reset reinitializes the local resources that are associated with the circuit and returns it to an idle state so it can be used again. Note that only group resets receive an acknowledgement from the far end; an individual reset does not. The following messages are associated with circuit resets:

• Reset Circuit (RSC)— Sent to the far end to indicate that the circuit is being reset to the idle state.

• Group Reset Circuit (GRS)— Sent to the far end to indicate that a contiguous group of CICs are being reset.

• Group Reset Acknowledgement (GRA)— Sent as an acknowledgement in response to GRS.