Figure 1 shows the components of the SS7 protocol stack.

Diagnostics consists of realigning and resynchronizing the link.

For example, if ISUP is not available at a particular node, a traffic management message can be sent to adjacent nodes informing them that ISUP is not available, without affecting TCAP messages on the same node.

Every SS7 node must have its own unique point code. Message routing determines the point code from an address contained in the routing table.

MTP provides the rest of the levels with node-to-node transmission, including basic error detection and correction schemes and message sequencing. It provides routing, message discrimination and distribution functions within a node.

Standards Compliance

TCAP enables the deployment of advanced intelligent network services by supporting non-circuit related information exchange between signaling points using the SCCP connectionless service. An SSP uses TCAP to query an SCP to determine the routing number(s) associated with a dialed 800, 888, or 900 number. The SCP uses TCAP to return a response containing the routing number(s) (or an error or reject component) back to the SSP. Calling card calls are also validated using TCAP query and response messages. When a mobile subscriber roams into a new mobile switching center (MSC) area, the integrated visitor location register requests service profile information from the subscriber's home location register (HLR) using mobile application part (MAP) information carried within TCAP messages.

TCAP messages are contained within the SCCP portion of an MSU. A TCAP message is comprised of a transaction portion and a component portion.

Transaction Portion

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

• Unidirectional: Transfers component(s) in one direction only (no reply expected).
• Query with Permission: Initiates a TCAP transaction (e.g., a 1-800 query). The destination node may end the transaction.
• Query without Permission: Initiates a TCAP transaction. The destination node may not end the transaction.
• Response: Ends the TCAP transaction. A response to an 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 end the transaction.
• Conversation without Permission: Continues a TCAP transaction. The destination node may not end the transaction.
• Abort: Terminates a transaction due to an abnormal situation.

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

Component Portion

The component portion contains components. There are six 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.

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

Standards Compliance

SCCP provides connectionless and connection-oriented network services above MTP Level 3. While MTP Level 3 provides point codes to allow messages to be addressed to specific signaling points, SCCP provides subsystem numbers to allow messages to be addressed to specific applications (called subsystems) at these signaling points. SCCP is used as the transport layer for TCAP-based services such as freephone (800/888), calling card, wireless roaming, and personal communications services (PCS).

Global Title Translation

One of the most important function provided by the SCCP is the ability to perform incremental routing using a capability called global title translation (GTT). GTT frees originating signaling points from the burden of having to know every potential destination to which they might have to route a message. A switch can originate a query, for example, and address it to an STP along with a request for GTT. The receiving STP can then examine a portion of the message, make a determination as to where the message should be routed, and then route it.

For example, calling-card queries (used to verify that a call can be properly billed to a calling card) must be routed to an SCP designated by the company that issued the calling card. Rather than maintaining a nationwide database of where such queries should be routed (based on the calling-card number), switches generate queries addressed to their local STPs, which, using GTT, select the correct destination to which the message should be routed. Note that there is no magic here; STPs must maintain a database that enables them to determine where a query should be routed. GTT effectively centralizes the problem and places it in a node (the STP) that has been designed to perform this function.

In performing GTT, an STP does not need to know the exact final destination of a message. It can, instead, perform intermediate GTT, in which it uses its tables to find another STP further along the route to the destination. That STP, in turn, can perform final GTT, routing the message to its actual destination.

Intermediate GTT minimizes the need for STPs to maintain extensive information about nodes that are far removed from them. GTT also is used at the STP to share load among mated SCPs in both normal and failure scenarios. In these instances, when messages arrive at an STP for final GTT and routing to a database, the STP can select from among available redundant SCPs. It can select an SCP on either a priority basis (referred to as primary backup) or so as to equalize the load across all available SCPs (referred to as load sharing).

Explanation of how GTT is done

Lets say for example you dialed 1 800 746 2936 from your home phone. All 800 service calls are routed via TCAP (Transaction Capabilitys Applications Part) which is one of the many protocols in the Switching System 7 (SS7) network. TCAP is used for database queries. With the 800 number, it is first starts at the TCAP level, and then goes to the SCCP and then finally to the MTP. From the MTP, the message continues to the next node in the layer of protocols, and then travels back through the SS7 protocol. The diagram below shows how 800 service routing works:

Example 1 (800 746 2936 Service Examples)

I cannot be botherd to make a geographicaly correct map of India in this format, so in this example we will asume that the India is a rectangle, and ignore we learn at school for the time being.

 |     You dialing                                                         |
 |     1 800 746 2936                                                      |
 |   /                                                                     |
 |  ___               ____               (Inter Exchange Carriers)         |
 | |   |         ____|    |===========\                                    |
 | |___|       /     |____|ICN       _||_                                  |
 |   |       /                      |    |_______________                  |
 |   |     /                        |____|           _____\___             |
 |    \   |  [1,2,3,4]  ____                        |         |            |
 |      \ |  __________|    |============\          | LATA Boundrys        |
 |     __||/           |____|ICN        _||_      / |         |____        |
 |    |   |                            |    |___/   |_________|     \      |
 |    |___| Central Office             |____|                         \    |
 |     ||                                       [5]                    |   |
 | STP ||                                                              |   |
 |    _|_\_  800 Applications                                          |   |
 |   |  |  | Software                                                  |   |
 |   |__|__| (global translation)               The terminating       _|_  |
 |    |   |                                     line: 561 682 8577   |   | |
 |  | || || |                                                        |___| |
 |  |__| |__|                                                              |
 |_________________________________________________________________________|

So whats happening here? If you cannot understand the diagram (like me) This is what happens:

[1]

You dial 1 800 746 2936 and the digits are sent to your central office, which recognises the 800 number stored in it's 800 applications software package. The central office, along with the SS7 protocol makes a querie message, which is then forworded to the STP. The coded querie message contains instructions to perform a global title translation on 800 746 2936.

[2]

The STP then looks up 800 746 2936 in it's translation table, and will produce a destination point code and a subsystem number. The destination point code is the location of the SCP and the subsystem number is the ID of the database within the SCP which is then accessed. The STP then encodes this information into a message and then makes the appropriate link selection and sends the message to the identified SCP.

[3]

The SCP then recieves your 800 routing instruction, then a database will then translate 800 746 2936 into an ordinary ten digit POTS number (561 682 8577). The number along with the pre selected IC carrier and any information nessasery for handeling the call is then encoded into a responce message, and sent back to the STP. The STP then looks up the destination point code in the message.

[4]

The destination point code ID's the originating SSP, and then based upon this information the STP will select a link and forward the responce message. Using the information in the message the SSP will enter it's signalling mode and select a trunk where it will pass the message off to the appropriate interexchange carrier.

[5]

The IC will then send the message accross LATA boundaries to the final destination point. Finally SS7 signalling is used as the message is transmitted to the switchboard in Palm Beach Florida. All of this routing is determined by the customers arrangments with the telco. The customers 800 routing configuration is stored in a database called the Call Managment Services Database (CMSDB)

SCCP messages are contained within the signaling information field (SIF) of an MSU. The SIF contains the routing label followed by the SCCP message contents. The SCCP message is comprised of a one-octet message type field followed by the mandatory fixed part (mandatory fixed-length parameters), mandatory variable part (mandatory variable-length parameters), and the optional part. Each optional part parameter is identified by a one-octet parameter code followed by a length indicator ("octets to follow") field.

The Service Indicator of the Service Information Octet (SIO) is coded 3 (binary 0011) for SCCP. SCCP messages are contained within the Signaling Information Field (SIF) of an MSU. The SIF contains the routing label followed by the SCCP message contents. The SCCP message is comprised of a one-octet message type field which defines the contents of the remainder of the message .

SCCP Message Format

BISUP (Broadband ISUP) will gradually replace ISUP as ATM is deployed.

The ISDN User Part (ISUP) defines the protocol and procedures used to set-up, manage, and release trunk circuits that carry voice and data calls over the public switched telephone network (PSTN). ISUP is used for both ISDN and non-ISDN calls. Calls that originate and terminate at the same switch do not use ISUP signaling.

Basic ISUP Call Control

Figure 8 depicts the ISUP signaling associated with a basic call.

1. When a call is placed to an out-of-switch number, the originating SSP transmits an ISUP initial address message (IAM) to reserve an idle trunk circuit from the originating switch to the destination switch (1a). The IAM includes the originating point code, destination point code, circuit identification code (circuit "5" in Fig. 8), dialed digits and, optionally, the calling party number and name. In the example below, the IAM is routed via the home STP of the originating switch to the destination switch (1b). Note that the same signaling link(s) are used for the duration of the call unless a link failure condition forces a switch to use an alternate signaling link.

Figure 8. Basic ISUP Signaling
2. The destination switch examines the dialed number, determines that it serves the called party, and that the line is available for ringing. The destination switch transmits an ISUP address complete message (ACM) to the originating switch (2a) (via its home STP) to indicate that the remote end of the trunk circuit has been reserved. The destination switch rings the called party line and sends a ringing tone over the trunk to the originating switch. The STP routes the ACM to the originating switch (2b) which connects 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 the ringing tone on the voice trunk.

   In the example shown above, the originating and destination switches are directly connected with trunks. If the originating and destination switches are not directly connected with trunks, the originating switch transmits an IAM to reserve a trunk circuit to an intermediate switch. The intermediate switch sends an ACM to acknowledge the circuit reservation request and then transmits an IAM to reserve a trunk circuit to another switch. This processes continues until all trunks required to complete the voice circuit from the originating switch to the destination switch are reserved.

3. When the called party picks up the phone, the destination switch terminates the ringing tone and transmits an ISUP answer message (ANM) to the originating switch via its home STP (3a). The STP routes the ANM to the originating switch (3b) which verifies that the calling party's line is connected to the reserved trunk and, if so, initiates billing.

4. If the calling party hangs-up first, the originating switch sends an ISUP release message (REL) to release the trunk circuit between the switches (4a). The STP routes the REL to the destination switch (4b). If the called party hangs up first, or if the line is busy, the destination switch sends an REL to the originating switch indicating the release cause (e.g., normal release or busy).

5. Upon receiving the REL, the destination switch disconnects the trunk from the called party's line, sets the trunk state to idle, and transmits an ISUP release complete message (RLC) to the originating switch (5a) to acknowledge the release of the remote end of the trunk circuit. When the originating switch receives (or generates) the RLC (5b), it terminates the billing cycle and sets the trunk state to idle in preparation for the next call.

ISUP Message Format

ISUP information is carried in the Signaling 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 (e.g., IAM, ACM, ANM, REL, RLC) which defines the contents of the remainder of the message (Fig. 9).

Figure 9. ISUP Message Format

Each ISUP message contains a mandatory fixed part containing mandatory fixed-length parameters. Sometimes the mandatory fixed part is comprised only of the message type field. The mandatory fixed part may be followed by the mandatory variable part and/or the optional part. The mandatory variable part contains mandatory variable-length parameters. The optional part contains optional parameters which are identified by a one-octet parameter code followed by a length indicator ("octets to follow") field.

Initial Address Message

An Initial Address Message (IAM) is sent in the "forward" direction by each switch needed to complete the circuit between the calling party and called party until the circuit connects to the destination switch. 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.

Figure 10. ANSI and ITU-T Initial Address Message (IAM) Format

Address Complete Message

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 the ringing tone on the voice trunk generated by the destination switch.

Figure 11. ANSI and ITU-T Address Complete Message (ACM) Format

Answer Message

When the called party answers, the destination switch terminates the ringing tone and sends an Answer Message (ANM) to the originating switch. The originating switch initiates billing after verifying that the calling party's line is connected to the reserved trunk.

Figure 12. ANSI and ITU-T Answer Message (ANM) Format

Release Message

A Release Message (REL) is sent in either direction indicating that the circuit is being released due to the cause indicator specified. An REL is sent when either the calling or called party "hangs up" the call (cause = 16). An REL is also sent in the backward direction if the called party line is busy (cause = 17).

Figure 13. ANSI and ITU-T Release (REL) Message Format

Release Complete Message

A Release Complete Message (RLC) is sent in the opposite direction of the REL to acknowledge the release of the remote end of a trunk circuit and end the billing cycle as appropriate.

Figure 14. ANSI and ITU-T Release Complete (RLC) Message Format

Standards Compliance