Signaling System No.7 Protocol Architecture And Sevices part 28 ppt

This capability is known as Global Title Translation GTT, which translates what is known as a global title for example, dialed digits for a toll free number into a signaling point code a

SCCP Routing Control (SCRC)

SCRC performs the following three functions:

• Routes messages received from the MTP to appropriate local subsystem

• Routes messages from local subsystems to other local subsystems

• Routes messages from local subsystems to subsystems in remote nodes by utilizing MTP's transport services The destination is specified in the called party (CdPA) address parameter, which is supplied by the subsystem The address can contain a combination of point code, system number, and global title

SCCP addressing capabilities are flexible in contrast to those of MTP 3 As a result, the addressing capabilities are somewhat complex, thereby allowing several different combinations of routing parameters

SCCP provides a routing function that allows signaling messages to be routed to a signaling point based on dialed digits, for example This capability is known as Global Title Translation (GTT), which translates what is known as a global title (for example, dialed digits for a toll free number) into a signaling point code and a subsystem number so that it can be processed at the correct application The

section on "Global Title Translation" explains global titles and GTT

The following are different types of network addressing that SCCP supports:

• Point Code (PC) routing

• Subsystem Number (SSN) routing

• Global Title (GT) routing

The MTP layer can only use point code routing, which is described in Chapter 7 Figure 9-9 shows a summary of MTP point code routing Using MTP point code routing, MSUs pass through the STPs until they reach the SP that has the correct DPC The following sections describe the SSN and GT routing

Figure 9-9 Showing MTP Point Code Routing

[View full size image]

Subsystem Number (SSN) Routing

As previously mentioned, a subsystem is the name given to an application that uses SCCP; applications are predominantly database driven, except where ISUP is the subsystem (for a limited number of supplementary services), or where BSSAP uses SCCP (for radio-related signaling in GSM) As illustrated in Figure 9-10, a SSN is used to identify the SCCP user in much the same way as the service indicator identifies the MTP3 user (see Chapter 7)

Figure 9-10 An SSN and DPC Are Required for the Final Delivery of an SCCP

Message

Figure 9-10 shows that a DPC and SSN are required in order to deliver a message

to the correct application at the destination node

It should be clear that noncircuit-related signaling (for example, database

transactions to support IN/cellular, and so on) involve two distant applications (subsystems) exchanging information The SSN is used to identify the application Appendix L contains a trace that shows the decoding of a VLR calling an HLR (to perform a location update)

NOTE

Applications using TCAP rely on SCCP for message routing since TCAP itself has

no routing capabilities Therefore, each application is explicitly identified by an SSN at the SCCP level

If SSN routing is used, the SSN is placed inside the CdPA parameter The SCCP uses the SSN to send an SCCP message to a particular subsystem (application) at

an SP The SSN of the originating subsystem is also included in the Calling Party Address (CgPA) parameter to identify the subsystem that sent the SCCP message NOTE

SCCP's CgPA and CdPA parameters should not be confused with the Calling Party

Number and Called Party Number parameters found in TUP/ISUP

The SSN field is one octet in length and, therefore, has a capacity of 255 possible combinations

Table 9-12 shows the SSN values that are specified by the ITU-T

Table 9-12 ITU-T Specified Subsystem Numbers [60]

Bits

8 7 6 5 4 3 2 1 Subsystem

0 0 0 0 0 0 0 0 SSN not known/not used

0 0 0 0 0 0 0 1 SCCP management

0 0 0 0 0 0 1 0 Reserved for ITU-T allocation

0 0 0 0 0 0 1 1 ISUP (ISDN user part)

0 0 0 0 0 1 0 0 OMAP (Operation, Maintenance, and Administration Part)

0 0 0 0 0 1 0 1 MAP (Mobile Application Part)

0 0 0 0 0 1 1 0 HLR (Home Location Register)

0 0 0 0 0 1 1 1 VLR (Visitor Location Register)

0 0 0 0 1 0 0 0 MSC (Mobile Switching Centre)

0 0 0 0 1 0 0 1 EIC (Equipment Identifier Centre)

0 0 0 0 1 0 1 0 AUC (Authentication Centre)

0 0 0 0 1 0 1 1 ISUP supplementary services[1]

0 0 0 0 1 1 0 0 Reserved for international use

0 0 0 0 1 1 0 1 Broadband ISDN edge-to-edge applications

0 0 0 0 1 1 1 0 TC test responder[1]

0 0 0 0 1 1 1 1 Reserved for international use

to

0 0 0 1 1 1 1 1

0 0 1 0 0 0 0 0

to

1 1 1 1 1 1 1 0

Reserved for national networks

1 1 1 1 1 1 1 1 Reserved for expansion of national and international SSN

[1]

ANSI [2] simply states this field value as reserved

ITU-T network specific subsystem numbers should be assigned in descending order, starting with 11111110 (for example, BSSAP is allocated 11111110 within GSM)

In GSM, subsystem numbers can be used between Public Land Mobile Networks (PLMNs), in which case they are taken from the globally standardized range (1– 31) or the part of the national network range (129–150) that is reserved for GSM use between PLMNs, or within a PLMN, in which case they are taken from the part of the national network range (32–128 and 151–254) that is not reserved for GSM use between PLMNs

Table 9-13 lists the globally standardized subsystem numbers that have been allocated by 3GPP for use by GSM/GPRS/UMTS cellular networks [106]

Table 9-13 3GPP Specified Subsystem Numbers [60]

Bits Subsystem

1111 1011 MSC

1111 1101 BSS O&M

Additionally INAP is specified as 0000 1111 [106]

Table 9-14 shows some common subsystems that are used within North America

Table 9-14 Common North American Subsystem Numbers

Bits Subsystem

1111 1011 Custom Local Area Signaling Service (CLASS)

1111 1100 PVN (Private Virtual Network)

1111 1101 ACCS Automatic Calling Card Service (ACCS)

1111 1110 E800 (Enhanced 800)

Global Title Routing

"A global title is an address, such as dialed-digits, which does not explicitly

contain information that would allow routing in the SS7 network."

Source: ITU-T-T Q.714 Subclause 2.1 [61]

There are many examples of digit strings that are global titles: in fixed-line

networks, toll free, premium rate, numbers ported under LNP, or in the case of GSM cellular networks, the Mobile Subscriber ISDN Number (MSISDN) and International Mobile Subscriber Identity (IMSI) of the cellular subscriber and each HLR and VLR

A GT is a telephony address As such, the GT address must be translated into an SS7 network address (DPC+SSN) before it can be finally delivered The GT is placed in the global title address information (GTAI) parameter within the CgPA and CdPA fields

Global title routing is often used in fixed-line networks for calling-card validation and such services as telemarketing numbers (like a toll-free or premium rate) It is used in cellular networks for exchanging messages when an HLR and VLR belong

to different networks or when several signaling points separate them

Global Title Translation

GTT is an incremental indirect routing method that is used to free originating signaling points from the burden of having to know every potential application destination (that is, PC+SSN) This section describes the GTT process and the parameters associated with GTT

For example, calling-card queries (which are used to verify that a call can be

properly billed to a calling card) must be routed to an SCP that is 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), SSPs generate queries that are addressed to their local STPs, which use GTT, to select the correct destination to which the message should be routed STPs must maintain a database that enables them to determine where a query should be routed GTT centralizes SCCP routing information at designated nodes, generally

an STP, although SSP or SCP nodes are normally capable of performing GTT

Even the SP that has been requested by another SP to perform GTT does not have

to know the exact final destination of a message Instead, it can perform

intermediate GTT, in which it uses its tables to locate another SP that might have the final address required in its routing tables An SP that performs a final GTT provides both the PC and SSN needed to route the message to its final destination Intermediate GTT further 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 a load among mated SCPs in both normal and failure scenarios In these instances, when messages arrive at an SP for final GTT and routing to

destination SP, the STP that routes the message can select from among available redundant SPs (for example, two mated SCPs) It can select an SP on either a priority basis or to equalize the load across the available SPs (this is referred to as loadsharing)

As an example, GTT is performed to determine the SCP location to which queries should be sent for number translation services such as tollfree and LNP If you dial 1-800-BUY-MORE in the U.S (toll-free begins with 0800 in many countries, including Great Britain), a query is sent to an SCP to translate the toll-free number

to a routing number See Chapter 11 for a detailed explanation of how number translation services work

When the SSP receives the tollfree or LNP number from the subscriber, it must determine the next hop destination to reach the SCP that provides the number translation service In Figure 9-11, the SSP performs a GTT to determine that the next hop destination is the STP The STP then performs the final GTT to route the message to the correct SCP It is worth noting that when people in the SS7 field refer to "where the GTT is done", they are usually referring to the STP that

provides the address of the final destination In the previous example, GTT is actually done at the originating SSP in order to determine the next hop desination (the STP) towards the SCP and also at the STP to determine the final destination

Figure 9-11 Example of GTT [View full size image]

The SSP could always get the information from such a database (SCP) without using GTT if the DPC and SSN of the required toll free (or LNP) application were present in its routing tables However, this would require maintaining a large

number of routing entries at the SSP New services (and applications) are

frequently deployed into the SS7 network around the world Some of the services might be proprietary and are, therefore, only accessible to the SSPs in the same proprietary network Others are intended to be offered to other networks for a fee

If a service becomes universally available, it should not mean that every switch

worldwide should be required to add the location (DPC) and application identifier (SSN) to its routing tables Therefore, the GTT is used to centralize these routing functions

SCCP routing (utilizing GTT) is an effective solution The GTT information is placed at a limited number of network locations (such as STPs), and SSPs query these centralized locations without identifying from where the information is

retrieved When a switch requires a GT translation (that is, to address an

application), it must only identify the nature of the translation it needs (for

example, a toll-free number to E.164 "real" number), and send the request to a location that has GT routing tables to perform the translation GTT is only

performed on the number of digits required to identify where the SCCP message should be sent after translation For example, in our toll-free illustration, GTT may only be performed on the three most significant digits (800) at the SSP to

determine that all 800 numbers should be sent to a designated STP At the STP, GTT could require translation of six digits (800-289) in order to determine the next STP for intermediate GTT or the final SCP destination These decisions are made based on the administration of the network and agreements between network

operators

NOTE

It is important not to confuse directory number translation with GTT When a

query involving a number translation service is sent, GTT determines the SS7 address of the service (DPC + SSN) in order to deliver the message to the correct

SP and subsystem The service (such as toll-free) translates the number contained

in the TCAP portion of the message, not the GT number in the SCCP portion of the message

This allows a single entry in the SSP's routing table (such as the location of an STP) to provide 800 number translations As stated previously in this section, with intermediate GTT, even the first location that receives the query (for DPC and/or SSN of destination application) does not have to maintain a routing table of all locations on the globe Instead, it might have a table that indicates that all requests

in several similar categories should be sent to one location, while requests in other categories can be sent somewhere else These locations either directly identify the correct destination application (subsystem) or again, in the case of intermediate GTT, send it to another node for further GT routing analysis

Figure 9-12 shows a further example using the GSM cellular network

Figure 9-12 GTT on a GSM Cellular Network

[View full size image]

In Figure 9-12, a VLR in Country A originates a MAP Update Location message The message contains the DPC of a Country A's International Switching Centre (ISC) The MSC/VLR contains the PC of the ISC that is provisioned in its routing tables The message also contains the GT of the HLR (an E.164 number) The ISC

at Country A changes the DPC to be an ISC of Country B Again, this PC is

already provisioned in its routing tables, and again, the GT of the HLR is present in the message The ISC in Country B happens to have the data fill to translate the GT into a PC+SSN; therefore, it performs the GTT Thus, the message is routed to the HLR via the GMSC using only the PC+SSN GT translations are usually

centralised at STPs to allow routing changes to be made easily

Calling Party Address (CgPA) and Called Party Address (CdPA)

The CgPA contains information for identifying the originator of the SCCP

message The CdPA contains information to identify the SCCP message's intended destination Figure 9-13 shows the placement of the CgPA/CdPA in the context of

an MSU Figure 9-14 shows the fields that are found within the CgPA/CdPA

Figure 9-13 Positioning of the CgPA and CdPA Fields in the Context of an MSU

[View full size image]

Figure 9-14 The Subfields that Belong to Both the CgPA and CdPA Fields

Address Indicator (AI)

The AI is the first field within CgPA/CdPA and is one octet in length Its function

is to indicate which information elements are present so that the address can be interpreted—in other words, it indicates the type of addressing information that is

to be found in the address field so the receiving node knows how to interpret that data

The Routing Indicator (RI) specifies whether GTT is required; it determines

whether routing based on PC+SSN or GT If routing is based on the GT, the GT in the address is used for routing If routing is based on PC+SSN, the PC and SSN in the CdPA are used The PC from the CdPA is then placed into the MTP3 routing label DPC before MTP routing takes place

The GT Indicator (GTI) specifies the GT format In addition to those codes shown previously, 0101 to 0111 represent spare international use, and 1000 to 1110 represents spare national use

The subsystem number is encoded "00000000" when the Subsystem Number is unknown (such as before GTT)

Figure 9-15 shows an example of SCCP routing using a GT

Figure 9-15 Example Routing Parameters and Values

[View full size image]

There are four possible GT formats (bits C-F) '0100' is a common format that is used for international network applications, including INAP, which is discussed in Chapter 11, "Intelligent Networks (IN)," and MAP, which is discussed in Chapter

13, "GSM and ANSI-41 Mobile Application Part (MAP)." Figure 9-16 shows this common format

Figure 9-16 GT Format 0100 [View full size image]