In some parts of the world, such as China, the Telephone User Part (TUP) protocol supports basic call processing. TUP handles analog circuits only; digital circuits and data transmission capabilities are supported by the Data User Part protocol.

ISUP Message Format

ISUP information is carried in the service information field (SIF) of an MSU. The SIF contains the routing label followed by a 14-bit (ANSI) or 12-bit (ITU) circuit identification code (CIC). The CIC indicates the trunk circuit reserved by the originating switch to carry the call.

The CIC is followed by the message type field - IAM, ACM, ANM, REL, RLC - which defines the contents of the remainder of the message.

Each ISUP message contains a mandatory part that includes fixed-length parameters. Sometimes the mandatory fixed part is comprised only of the message type field.

The mandatory fixed part may be followed by a mandatory variable part and/or an optional part. The optional part contains parameters which are identified by a one-octet parameter code followed by a length indicator ("octets to follow") field. (See Figure 5-2.)

Figure 5-1: Basic ISUP Signaling

Figure 5-2: ISUP Message Format

ISUP Message Types

IAM

An initial address message (IAM) is sent in the "forward" direction by each switch in the circuit between the calling party and the destination switch of the called party. An IAM contains the called party number in the mandatory variable part and may contain the calling party name and number in the optional part. (See Figure 5-3.)

Figure 5-3: ANSI and ITU-T Initial Address Message (IAM) Format

ACM

An address complete message (ACM) is sent in the "backward" direction to indicate that the remote end of a trunk circuit has been reserved. The originating switch responds to an ACM message by connecting the calling party's line to the trunk to complete the voice circuit from the calling party to the called party. The calling party hears ringing on the voice trunk. (See Figure 5-4.)

Figure 5-4: ANSI and ITU-T Address Complete Message (ACM) Format

REL

A release message (REL) is sent in either direction indicating that the circuit is being released due to a specified cause indicator. An REL is sent when either calling or called party hangs up the call (cause = 16). An REL is also sent back to the calling party if the called party is busy (cause = 17). (See Figure 5-5.)

Figure 5-5: ANSI and ITU-T Release (REL) Message Format

RLC

A release complete message (RLC) is sent in the opposite direction of an REL to acknowledge the release of the remote end of a trunk circuit and to end the billing cycle, if appropriate. (See Figure 5-6.)

Figure 5-6: ANSI and ITU-T Release Complete (RLC) Message Format

ISUP Call Sequence

Call Initiated

See Figure 5-7 and Figure 5-8 as you review the following messaging sequence:

1. Calling party goes "off hook" on an originating switch (SSP) and dials the directory number of the called party.

1a. Originating SSP transmits ISUP IAM to reserve an idle trunk circuit. The IAM includes OPC, DPC, CIC, dialed digits, CPID, and calling party name (Caller ID option).

1b. IAM is routed via home STP of originating SSP.

2. Destination switch (SSP) checks the dialed number against its routing table and confirms that the called party's line is available for ringing.

2.a Destination SSP transmits ACM to the originating SSP via its home STP to confirm that the remote end of the trunk circuit has been reserved.

2b. The STP routes the ACM to the originating SSP which connects the calling party's line to the trunk to complete the voice circuit. The calling party hears ringback tone.

Figure 5-7: ISUP Call Initiation (1)

Figure 5-8: ISUP Call Initiation (2)

ISUP Call Answered

See Figure 5-9 as you review the following messaging sequence:

3a. Called party goes off-hook. Destination switch terminates ringing tone and transmits an ISUP answer message (ANM) to the originating switch via its home STP.

3b. STP routes ANM to originating switch which verifies that the calling party is connected to the reserved trunk. Billing is initiated.

Figure 5-9: ISUP Call Answered

ISUP Call Released

See Figure 5-10 and Figure 5-11 as you review the following messaging sequence:

4a./b. If the calling party hangs up first, the originating switch sends an ISUP release message (REL) to release the trunk between the two switches. If the called party releases first, the destination switch sends an REL message to the originating switch to release the circuit.

5a. When the destination switch receives the REL, it disconnects and idles the trunk, and transmits an ISUP release complete message (RLC) to the originating switch to acknowledge the release of the remote end of the circuit.

5b. When the originating switch receives or sends an RLC, the billing cycle ends and the trunk state is returned to idle.

Figure 5-10: ISUP Call Release (1)

Figure 5-11: ISUP Call Release (2)

TCAP Functions

Transactional Capabilities Application Part (TCAP) enables deployment of advanced intelligent network (AIN) services by supporting information exchange between signaling points using SCCP. TCAP messages are contained within the SCCP portion of a Message Signal Unit (MSU). TCAP messages consist of a transaction portion and a component portion.

An SSP uses TCAP to query an SCP to find out the routing number for an 800, 888 or 900 number. Calling cards are validated using TCAP query and response messages.

Mobile subscribers roaming into a new mobile switching center (MSC) area cause the integrated Visitor Location Register (VLR) to request a service profile from the subscribers Home Location Register (HLR) using the Mobile Application Part (MAP) information carried in TCAP messages.

TCAP Transaction Portion

The transaction portion contains the package type identifier. There are several package types:

Unidirectional—Transfers component(s) in one direction only (no reply expected).
Query with Permission—Initiates a TCAP transaction. The destination node may not end the transaction.
Response—Ends the TCAP transaction. A response to a 1-800 query with permission may contain the routing number(s) associated with the 800 number.
Conversation with Permission—Continues a TCAP transaction. The destination node may not end the transaction.
Abort—Terminates the transaction due to an abnormal situation.

The transaction portion also contains the Originating Transaction ID and Responding Transaction ID which associate the TCAP transaction with a specific application at the originating and destination signaling points.

TCAP Component Portion

The TCAP component portion contains several possible kinds of components:

Invoke (Last)—Invokes an operation. For example, a Query with Permission transaction may include an Invoke (Last) component to request SCP translation of a dialed 800 number. The component is the last component in the query.
Invoke (Not Last)—Similar to the Invoke (Last) component except that the component is followed by one or more components.
Return Result (Last)—Returns the result of an invoked operation. The component is the last component in the response.
Return Result (Not Last)—Similar to the Return Result (Last) component except that the component is followed by one or more components.
Return Error—Reports the unsuccessful completion of an invoked operation.
Reject—Indicates that an incorrect package type or component was received.

Note Components include parameters which contain application-specific data carried unexamined by TCAP.

Sample TCAP Database Query

This sample query describes how a dialed 800 number is processed using TCAP. See Figure 5-12 as you review the messaging sequence described below.

1. A subscriber goes off-hook and dials an 800 number. The end office switch (SSP) parses the digit string and sends an 800 query message to either of its STPs over its A-link.

2. The STP recognizes the 800 query and routes it to an appropriate database via an SCP.

3. The SCP receives the query, extracts the passed information and retrieves a real telephone number to which the call should be routed.

4. The SCP sends a response message with the information necessary to process the call to the originating SSP via an STP and an A-link.

5. The STP receives the response and routes it to the SSP.

6. The SSP receives the response and uses the information to route the call. It generates an IAM message and proceeds with ISUP call setup.

Figure 5-12: Sample TCAP "800" Number Query

Review: ISUP and TCAP

1. What is the principal function of ISUP?

2. Which field in an MSU carries ISUP information?

3. Define CIC.

4. What is the function of an IAM?

5. What does the receipt of an ACM indicate?

6. Which ISUP message initiates call billing?

7. What is the function of an REL message?

8. What is the response to an REL message?

9. What information is included in an IAM?

10. What happens when a called party goes off-hook?

11. What is the principal function of TCAP?

12. Where in an MSU are TCAP messages located?

13. Briefly describe the two portions of a TCAP message.

Table of Contents