While TUP has certainly provided key functionalities for setting up a call using the SS7 net- work, it was still a basic protocol. ISUP was designed to overcome limitations of TUP; an important aspect of ISUP is that it is an extensible protocol—thus, it can be customized for lo- cal need within a country. ISUP is now extensively used around the world for call processing in the PSTN, although it was originally defined for ISDN services.
ISUP defines about 100 different message types. We have summarized several key mes- sages types such as Initial Address Message (IAM), Address Complete Message (ACM), and so on, in Table 12.5. Similar to TUP, the routing label and the TCIC code are included in all ISUP messages; the major difference here is that in the case of an ISUP message, the routing label consists of the DPC, the OPC, and the SLS fields while the TCIC code is included in a separate field following the routing label. Furthermore, in ISUP, IAM is generated only after all the dialed digits are entered by the user, while in TUP, IAM can be generated based on leading digits dialed.
The IAM message is the central message and carries much information; in fact, it has 39 different fields, of which 6 fields are mandatory fields. Table 12.6 lists key fields in the IAM message, including the mandatory fields. The IAM message carries all the critical information in regard to setting up a call; it includes information such as the TCIC field, and the Called Party Number and Calling Party Number. It is important to note that Calling Party Number is not a mandatory field. This means that the starting OPC is not required to include this field
TA B L E 12.5 Sample ISUP messages.
Message Type Full Name Usage
IAM Initial Address Message Used for establishing a call
ACM Address Complete Message Indicates that the other end is processing the call
CPG Call Progress Call in progress message used for alert-
ing, etc.
ANM Answer Message Indicates that the called party has an-
swered the call
EXM Exit Message Indicates that the IAM message has been
passed to another network when inter- networking is required to establish a call
REL Release Indicates that the call is being terminated
RLC Release Complete Indicates that the REL message has been received and the voice circuit can be re- leased
INR Information Request Used for requesting additional informa- tion about a call in progress
INF Information Used as a response to the INR message to
provide information requested
BLO Blocking Blocking on a circuit by a switch so that
other end does not use this circuit BLA Blocking Acknowledgment Acknowledgment of a BLO message
UBL Unblocking Unblocking a circuit previously blocked
using BLO
UBA Unblocking Acknowledg-
ment
Acknowledgment of a UBL message CGB Circuit Group Blocking For blocking a range of circuits CGBA Circuit Group Blocking
Acknowledgment
Acknowledgment of a CGB message CGU Circuit Group Unlocking For unblocking of a range of circuits
blocked earlier using CGB CGBA Circuit Group Unlocking
Acknowledgment
Acknowledgment of a CGU message
when an IAM message is generated. An advantage of not including the Calling Party Number is avoiding automatic number identification by the receiving party; however, a difficulty is that if an error code is to be generated along a call path by an intermediate SSP, it would not know what calling party it is for—certainly, it is debatable whether the intermediate SSP needs to know this information. Thus, leaving it as an optional field was probably the best solution.
In an IAM message, the Calling Party’s Category field is used to indicate the type of subscriber originating the call. This field is used to indicate whether the originator is an or- dinary calling subscriber, a call from a pay phone, or a call from a special-language operator.
TA B L E 12.6 ISUP Initial Address Message (IAM) and Release Message (REL): Key fields (Mandatory fields are marked with∗).
INITIALADDRESSMESSAGE(IAM):
Routing Label∗
Trunk Circuit Identification Code (TCIC)∗ Message Type (IAM)∗
Nature of Connection Indicator∗ Forward Call Indicator∗ Calling Party’s Category∗ User Service Information∗ Called Party Number∗ ...
Call Reference ...
Calling Party Number ...
Carrier Identification Code ...
Generic Address ...
RELEASEMESSAGE(REL):
Routing Label∗
Trunk Circuit Identification Code (TCIC)∗ Message Type (REL)∗
Cause Indicator∗ ...
Call Reference ...
The User Service Information field is usually not needed for a regular telephone call. It is used when the subscriber is requesting data transmission such as ISDN that does not use a modem. The Called Party Number contains the number that the originating user dials, ex- cluding any leading digits used to indicate whether it is a long distance, or an international, or an operator-assisted call. Since the number can be for a variety of services, we will discuss it further after a discussion of numbering plans in Chapter 13. Call Reference is an optional field in an IAM message. This is assigned to a call for the purpose of identification of the call;
this is not a global value and is used primarily for tracking. The Carrier Identification Code field identifies the network carrier; its use will be discussed in Chapter 13. Furthermore, the role of the fields, Forward Call Indicator and Generic Address, will be discussed later in Sec- tion 13.11.4, when we introduce number portability.
An ISUP REL message is an important message that is often associated with an IAM message. Key fields for an ISUP REL message, including 4 mandatory fields, are listed in Table 12.6. In the normal mode, this message is used to indicate the release of a call. How- ever, REL is used for much more than that. It includes a cause indicator field; for a normal call release, cause identifier 16 is used. If a call is not accepted during setup due to lack of an avail- able voice circuit, a REL message is generated by specifying this cause in the cause indicator field. Automatic congestion level is also indicated using the cause indicator field in the REL message. Two levels of congestion are used, which depends on the threshold value specified;
on receiving the level of congestion information, a source switch may choose to active hard- to-reach code (refer to Section 11.6.2). In fact, the REL message type is used in numerous ways [331]; for example, for indicating if the receiving user’s line is busy (cause identifier 17), or if the number at the receiving end is an unallocated/unassigned number (cause identifier 1), or if no circuits are available (cause identifier 34), or if switching equipment is congested (cause identifier 42).
There are some differences between the ISUP messages in the ANSI format and the ITU format; for example, the TCIC field in the ANSI-based IAM message is 14 bits long while it is 12 bits long in the ITU-based IAM message. Similarly, values for certain types or identifiers can be different.
Example 12.3 Call setup and tear-down process using ISUP messages.
We first present a simple illustration of the call setup process using ISUP messages. Con- sider a call from a switch with point code 1.4.4 to a destination switch with point code 1.4.5 (see Figure 12.7). Assume that by checking idle voice circuits, it has identified the TCIC code of the idle voice circuit as 51.
A call process starts with the IAM message from PC 1.4.4 to PC 1.4.5. At this point, the voice circuit number 51 is tagged for use by this call, but not fully reserved yet. If the user on the receiving side is available, PC 1.4.5 generates an ACM message to the PC 1.4.4 of the originating switch, and the ring is started while voice circuit number 51 is fully reserved for the call. On receiving the ACM message at the originating switch, user B starts hearing the ring. The destination switch generates the CPG message periodically until the user on the receiving side picks up the phone. Once the user picks up the phone, the ANM message is generated.
F I G U R E 12.7 ISUP call setup message exchanges.
F I G U R E 12.8 ISUP call tear-down message exchanges.
Assume that the call originator is the one who hangs up the phone at the end of the conversation (see Figure 12.8). A REL message is then generated at this end for the other end with cause identifier 16 for normal call clearing [331]; this REL message is then responded to
using an RLC message to indicate complete call tear-down.
We make the following important remarks:
• Before the trunkgroup is initialized between two adjacent telephone switches, they must agree on the logical voice circuit numbering that is to be viewed consistently from both sides so that there is no ambiguity in the TCIC code included in the initial IAM message.
That is, if TCIC is set to 51, the receiving switch knows which voice circuit it is, so that it does a tagging on this circuit and does not assign this same TCIC code to a newly arrived call at this switch going in the other direction. This is important since voice circuits are often bidirectional. There is a general rule about how to assign the TCIC code. Usually, two telephone switches are connected by T1 (with 24 voice circuits) or E1 (with 30 voice circuits) circuit groups; multiple circuit groups can make up the entire trunkgroup. Each T1/E1 circuit group is first numbered from 0 to a maximum of 127; instead of using 24 or 30, the circuit bundle for each link unit is often set to 32 following an ITU convention.
Thus,
TCIC code = circuit_group_number ×32+ circuit_id.
Suppose that the circuit group to be used is numbered 20 and the circuit number assigned within this circuit group is 15. The TCIC code for this circuit will then be 655. With this
rule, the maximum value possible is 4096, which is also the maximum value allowed in an ITU IAM packet due to 12 bits assigned to the TCIC field. Although the TCIC field in ANSI IAM is 14 bits long, i.e., the TCIC field can take a value up to 16,384, such a high value is rarely required if we consider the traffic demand factor. Using the Erlang-B loss formula given by Eq. (11.2.3), we can see that 3000 Erlangs of offered load at 1% call blocking requires 3023 trunks, which can be easily accommodated in the TCIC code range.
Not only that, it is extremely rare that two adjacent switches have more than 3000 Erlangs of offered load.
• There are many functions that can occur as soon as the ACM message is received by the originating switch. As an example, we show the initiation of the call detail record (CDR) for this specific call at the originating switch; this record is closed when the REL message is generated at the completion of the call. CDRs are used for the purpose of billing as well as for other usage. Note that not every CDR entry results in a billable entry; for example, a call may not be answered by the receiving side; a CDR is generated for this call but it is not a billable call.
ISUP currently uses the pass-along method for sending signaling messages from an origi- nating telephone switch to the ultimate destination telephone switch; that is, signaling mes- sages are handed on a hop-by-hop basis from one telephone switch to the next telephone switch until the ultimate destination is reached; this is consistent with progressive call con- trol (PCC) discussed earlier (refer to Section 10.1 in Chapter 10). This is not to be confused with actual routing of such messages within the SS7 network.
Example 12.4 Call routing and SS7 ISUP IAM message routing.
To understand the above discussion about the pass-along method/progress call control, consider Figure 12.9. We assume here that the telephone switch associated with point code 1.4.2 for which the call originates (“O-switch”) and the telephone switch associated with point code 1.4.3 for which the call is destined (“D-switch”) are not directly connected by a direct trunkgroup. A call between them is required to use the tandem switch identified by point
F I G U R E 12.9 Call routing and SS7 message routing illustration.
code 1.4.6 (“T-Switch”). That is, there is a trunkgroup between the O-Switch and T-Switch, and also a trunkgroup between the T-Switch and D-Switch—these are marked by bold lines.
We assume that when a call arrives at an O-switch, there are circuits available between the O-Switch and T-Switch, and between the T-Switch and D-Switch.
From an SS7 network perspective, assume that there is no direct F-link between SSPs 1.4.2 and 1.4.6, and between SSPs 1.4.6 and 1.4.3. All of them use STP with PC 1.4.0 to route signaling messages; for simplicity, we show only one STP instead of a mated pair of STPs.
Now consider a user associated with an O-Switch who dials a number to another user as- sociated with a D-Switch. The IAM message (not shown in the figure) will first be generated at PC 1.4.2 with OPC as 1.4.2 and DPC as 1.4.6 while including called and calling party num- ber information; the TCIC code of the voice circuit assigned on the trunkgroup between the O-Switch and T-Switch is, say, 22. This IAM message will be routed from SSP with PC 1.4.2 to STP with PC 1.4.0 to SSP with PC 1.4.6. On receiving this IAM message by PC 1.4.6, it will realize that the call is not terminating at this switch by inspecting the called party number.
Thus, PC 1.4.6 will regenerate an IAM message for this call keeping the called and calling party information but changing OPC to 1.4.6 and DPC to 1.4.3; this IAM message will be routed from the SSP with PC 1.4.6 to the STP with PC 1.4.0 to the SSP with PC 1.4.3. The TCIC code of the voice circuit assigned on the trunkgroup between the T-Switch and D-Switch is, say, 89 and is not related to the TCIC code on the first leg.
12.8.1 Called/Calling Party Number Format
So far, we have not discussed actually referencing to any specific Called or Calling Party Number format. This requires familiarity with E.164 numbering, which will be discussed later in Chapter 13, where we will again bring back SS7 call processing for a complete under- standing of call routing in the public switched telephone network. Here, we present a brief description of the format and a simple illustration.
The Called Party Number parameter contains two main subfields, one to indicate the nature of the address, and then the called number. The first subfield, Nature of Address In- dicator, is encoded to indicate if it is a national number or an international number, whether an operator is requested, and which numbering plan is used. Certainly, the most common numbering plan is E.164. Once the numbering plan is indicated, then the called party num- ber is encoded using four bits for each digit while all 1s in the four bits indicates the end of the number. The nature of address indicator can be used to indicate if the called number is a ported number; this will be discussed later in Section 13.11.4. We illustrate below Called and Calling Party Number as used, for example, in an IAM message.
Routing Label: OPC=1.4.4 DPC=1.4.5 TCIC: 55
Message Type: IAM CalledPartyNumber:
NatureofAddressIndicator: National NumberingPlan: E.164
Digit: 816-344-2525 CallingPartyNumber:
NatureofAddressIndicator: National NumberingPlan: E.164
Digits: 816-328-2208
It may be noted that ISUP messages use bit/byte–level encoding for different informa- tion. The above is listed in a textual mode for ease of understanding.