Earlier in Chapter 10 we presented several different dynamic call routing schemes that have been deployed in operational networks. Some of them use SS7 messaging for status related to call routing while others use dedicated circuits. Specifically, dynamic nonhierarchical routing (DNHR) and real-time network routing (RTNR) use SS7 ISUP messages for dynamic routing controls. Note that such messages are not standardized messages. We discuss them here to show how ISUP can be useful for the exchange of control messages for dynamic call routing.
Recall from Section 10.2.3 that telephone call control is usually based on progress call control (PCC). However, DNHR implemented originating call control (OCC) within its net- work. Thus, it requires a certain functionality to do OCC. Furthermore, crankback also plays a role in this regard. Also recall that the dynamic call routing network discussed in Chap- ter 10 is limited to using at most two links for call routing within its routing domain, where it is often the middle network connecting a local exchange carrier (LEC) to another local ex- change carrier (see Figure 12.10). For example, a call that originates at switch 6 in a LEC’s network that is destined for switch 7 in another LEC’s network uses the dynamic call rout- ing network as the middle network. Thus, within the dynamic call routing domain, we can
F I G U R E 12.10 Dynamic call routing along with hierarchical routing.
say that Switch 1 is the originating switch and Switch 3 is the destination switch. For alter- nate routing, we need to keep this in mind while considering the functionalities discussed below.
12.10.1 Functionalities
To set up a call in a dynamic call routing network, four types of messages are help- ful [27]:
• Traveling class mark—to control the selection of the route at a switch within the dynamic call routing network.
• Crankback—to return control of the call to the originating switch.
• Status Query—to request link status (trunkgroup status) from a switch.
• Status Response—to respond to a link status query that contains link status information.
The first two message types can be used during the call setup phase within the domain of the dynamic call routing network. The last two message types are not required to be tied up directly to the call setup phase.
TRAVELINGCLASSMARK
This message type can be used to control routing choices at different switches and is typically implemented as part of the ISUP IAM message by including this information in the optional part of the payload. Thus, when the originating switch within the dynamic call routing net- work receives its call control from the access network that is based on hierarchical routing, it needs to decide by consulting the routing table whether to route the call on the direct link path or on a two-link path to the destination switch within its network. Within its network,
there are three traveling class mark (TCM) tags, EXIT1, VIA1, and EXIT2, required for call handling in an IAM message. In essence, an IAM message is extended with additional infor- mation for the purpose of controlling routing choices.
CRANKBACK
Recall that we discussed crankback and call control in Section 10.2.3 in Chapter 10. To accom- plish crankback, a new ISUP message type for crankback is used. Its role comes within the dynamic call routing network at an intermediate switch. When the intermediate switch can- not find an available trunk to the destination switch, it has to return the control of the call to the originating switch within the dynamic routing network, for example, in a DNHR-based routing environment where originating call control is used. The returning control of the call is accomplished by sending an ISUP crankback message to the originating switch.
STATUSQUERY
A Status Query message can be generated depending on the actual implementation of the dynamic call routing schemes. In case of RTNR (refer to Section 10.6), the originating switch within the dynamic call routing network can initiate a status query to the destination switch to inquire about the link status of all outgoing trunksgroups from the destination switch that are within its routing domain. For RTNR, the query is about the availability of trunkgroups based on a certain load threshold value.
A Status Query message can be used in other dynamic call routing frameworks as well whenever the status of a trunkgroup is needed. For example, the query can be about available bandwidth, in a periodic or aperiodic manner, to a neighboring switch.
STATUSRESPONSE
A Status Response message is generated as a response to a Status Query message. For RTNR, the terminating switch responds with the link state status of outgoing trunkgroups.
While for RTNR this information concerns availability at a certain threshold, the status can be about available bandwidth in the case of an appropriate dynamic call routing frame- work.
In general, a status response would be generated as a response to a status query. However, a status response can also be generated by a switch to inform its neighbor about a change in trunk availability status based on an increase or decrease in call traffic. Either way, the status response message provides the functionality of the link state routing concept in a dynamic call routing environment.
12.10.2 Illustration
We now illustrate usage of the above messages in a dynamic call routing environment. Con- sider Figure 12.10 again; suppose the call originated in the access network at Switch 6 and is destined for Switch 7 in another access network. Switch 6, on recognizing that this call needs to go through another network, consults its translation table to determine that the call must be forwarded to Switch 1. Although the figure shows only the telephone switches, imagine that there is a parallel SS7 network that shadows the switched network. We consider the following possible scenarios:
1. If Switch 1 can route on the direct trunkgroup to Switch 3 due to availability of a circuit, then its IAM message includes the TCM tag EXIT1 so that Switch 3 knows that it is the destination switch within its network.
2. Suppose that Switch 1 needs to use the alternate route 1-2-3 to Switch 3 due to non- availability circuits on the direct trunkgroup 1-3. In this case, the IAM message is gen- erated by Switch 1 where the TCM tag is set to VIA1. On receiving this switch, Switch 2 recognizes that it is the intermediate switch within the dynamic routing network. By in- specting the called party number in this IAM message, Switch 2 determines that the des- tination switch is Switch 3 and finds an available circuit on the 2-3 link; Switch 2 then generates a new IAM message for this call with the TCM tag set to EXIT2, which is sent to Switch 3. On receiving this IAM message by Switch 3, it recognizes that it is the destination of the call by inspecting the tag field of the IAM message.
3. When Switch 2 receives an IAM message with the TCM tag set to VIA1, it is possible that there are no trunks available on the trunkgroup from Switch 2 to Switch 3 (subject to trunk reservation) for this call. Two situations are possible:
(a) If the dynamic routing network has crankback capability, Switch 2 will generate a crankback message to Switch 1 identifying the handling of the call and also specifying that the TCIC code of the circuit on link 1-2 identified through the IAM message is no longer needed. On receiving this crankback message at Switch 1, Switch 1 may try another alternate path such as 1-4-2 if this path is listed as the next route in its call routing table.
(b) If the dynamic routing network does not have crankback capability, Switch 2 will gen- erate an ISUP network trunk congestion (NTC) message to Switch 1 so that Switch 1 in turn can indicate to the originating switch (Switch 6) that the call cannot be com- pleted.
4. On arrival of a call within the dynamic routing core, Switch 1 (the ingress switch) may request Switch 3 (the egress switch) provide a status report for all outgoing trunkgroups by sending a Status Query message; on receiving such a message, Switch 3 may respond by sending a Status Response message that reports the availability status of all outgoing links.
It is easy to see that all dynamic call routing schemes that allow at most two-link call routing within its network can invoke step 1 and step 3. Any scheme that has crankback functionality can invoke step 3(a); otherwise, step 3(b) is invoked. A scheme such as the RTNR scheme would invoke step 4, which essentially enables the link state routing concept for dynamic call routing networks. Finally, a Status Response message can be generated by any switch to update information about its outgoing links to others, either periodically or based on load-based triggers; this functionality also applies to link state routing where each switch upon receiving such information may decide to update its routing.