Supplementary Services
`
`219
`
`• Redirecting Indicator-Not specified for ANSI networks . This field indicates how
`the call was forwarded and the presentation restriction indicators regarding the RI
`and RN.
`• Original Redirecting Reason - Indicates why the first forwarding station forwarded
`the call (for example, no reply or unconditional). This field is set to unconditional in the
`example illustrated in Figure 8-20.
`• Redirection Counter- Indicates the number of times a call has been forwarded. This
`counter is used to eliminate forwarding loops where a call ties up network resources
`because it is forwarded an excessive number of times. The ITU and ANSI standard for
`maximum redirections is five . In ANSI networks, the Hop Counter parameter provides
`this counter when RI is not included for forwarded calls. This field is set to 1 in the
`example illustrated in Figure 8-20.
`• Redirecting Reason - Indicates the reason the call is being forwarded . In our
`example using CFU, the reason indicator is set to unconditional.
`The OCN is the number dialed by the originator at A. The RN is the number of the station
`that forwarded the call. The RN is usually the same as the OCN, unless the call has been
`forwarded multiple times. If multiple forwardings have occurred, the RN is the number of
`the last station that forwarded the call. The CdPN will be set to the "forwarded to" number.
`Translation and routing using the new CdPN from the forwarding service at SSP B
`determine that the call should be directed to SSP C.
`
`Figure 8-20 !SUP Call Forwarding Signaling
`
`Forwarded to
`467-1234
`
`467-1234
`
`OCN=469-5333
`RN=469-5333
`1AM CPN=467-1234
`
`ACM
`
`ANM
`
`1AM
`
`ACM
`
`CPG
`
`ANM
`
`
`
`Page 151 of 156
`
`GOOGLE EXHIBIT 1011 (Part 5 of 5)
`
`

`

`220 Chapter 8: ISDN User Part (ISUP)
`
`At SSP B, an ACM is returned to the originator and a new call is attempted to the forward(cid:173)
`ing destination. Note that for ANSI networks, an ACM is not returned until the ACM is
`received from the new destination exchange, therefore, eliminating the CPG message.
`
`Additional Call Processing Messages
`In addition to messages presented in the chapter, many other messages are used in various
`contexts for call processing. Some of the additional messages are used to support supple(cid:173)
`mentary services, while others indicate specific network actions. Appendix B, "ISUP
`Messages (ANSI/UK/ETSI/ITU-T);' includes a complete list of all ISUP messages, their
`binary encoding, and a brief description.
`
`Maintenance Messages and Procedures
`ISUP provides an entire category of messages that are commonly categorized as "mainte(cid:173)
`nance" messages. Until now, this chapter has focused on the call processing aspect ofISUP.
`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
`
`
`
`Page 152 of 156
`
`

`

`Maintenance Messages and Procedures
`
`221
`
`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 mes(cid:173)
`sages 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.
`
`
`
`Page 153 of 156
`
`

`

`222 Chapter 8: ISDN User Part (ISUP)
`
`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(cid:173)
`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
`1AM 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 conti(cid:173)
`nuity 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 acknowl(cid:173)
`edge 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 informa(cid:173)
`tion on continuity testing, refer to the "Continuity Test" section of this chapter. The follow(cid:173)
`ing 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.
`
`
`
`Page 154 of 156
`
`

`

`Maintenance Messages and Procedures
`
`223
`
`• 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
`aBLO.
`• 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 mis(cid:173)
`match 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
`
`
`
`Page 155 of 156
`
`

`

`224 Chapter 8: ISDN User Part (ISUP)
`
`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 CI Cs are being reset.
`• Group Reset Acknowledgement (GRA)-Sent as an acknowledgement in response
`to GRS.
`
`Summary
`ISUP provides a rich network interface to call processing at an SSP. The increased band(cid:173)
`width and protocol standardization allow a greater range of services that are able to inter(cid:173)
`work both within a network and across network boundaries. ISUP was designed to interface
`well with ISDN access signaling by providing event mapping and facilitating end-to-end
`user signaling . The protocol's use of optional message parameters achieves flexibility and
`extensibility.
`
`ISUP uses a CIC identifier in each message to correlate the signaling with the correct
`circuit. The CIC is the key to associating signaling with bearer circuits.
`
`ISUP also provides a set of maintenance messages for diagnostics and maintenance
`of ISUP facilities . These messages allow for blocking, testing, and resetting circuits and
`inquiring about circuit status.
`
`
`
`Page 156 of 156
`
`