Signaling System No.7 Protocol Architecture And Sevices part 28

Chia sẻ: Dasdsadqwe Dsadasdsadsa | Ngày: | Loại File: PDF | Số trang:13

Thêm vào BST

Báo xấu

36
lượt xem 4
download

Signaling System No.7 Protocol Architecture And Sevices part 28

Mô tả tài liệu

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Signaling System No.7 Protocol Architecture And Sevices part 28

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 00011111 0 0 1 0 0 0 0 0 Reserved for national networks to 11111110 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 0000 0110 HLR 0000 0111 VLR 0000 1000 MSC 0000 1001 EIR 0000 1010 AuC 1111 1010 BSC
1111 1011 MSC 1111 1100 SMLC 1111 1101 BSS O&M 1111 1110 BSSAP 1000 1110 RANAP 1000 1111 RNSAP 1001 0001 GMLC 1001 0010 CAP 1001 0011 gsmSCF 1001 0100 SIWF 1001 0101 SGSN 1001 0110 GGSN 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]
We now examine the fields with the format '0100' that are found within a GT. Translation Type (TT) The Translation Type (TT) field indicates the type of translation. When it is not used, the TT is coded 00000000. A GTI of 0010 is for national use only; the translation types for GTI 0010 is a national decision; it can imply the encoding scheme and the numbering plan. The ITU-T has not specified the translation types for GTI 0011. Figure 9-17 shows the TT values [60]. Figure 9-17. Translation Type Values [60] [View full size image] Encoding Scheme (ES) The Encoding Scheme (ES) tells the receiving node how to translate the digits from binary code. Figure 9-18 shows the ES values [60]. Figure 9-18. Encoding Scheme Values [60] Numbering Plan (NP) The Number Plan (NP) field specifies the numbering plan that the address information follows. The E.164 standard for telephony has the format Country Code, National Destination Code, and Subscriber Number. The E.212 standard for the mobile station numbering plan has the format Mobile Country Code, Mobile Network Code, and Mobile Subscriber Identity Number (MSIN). The E.214 standard is a hybrid number with the Country Code and National Destination Code from E.164 and the MSIN from E.212. The E.214 format exists because international signaling networks require E.164 format. By replacing the leading digits of an E.212 number with the leading digits of an E.164 number, the existing translations can be used to route GTs. Figure 9-19 shows the NP values [60].
Figure 9-19. Numbering Plan (NP) Values [60] [View full size image] Nature of Address Indicator (NAI) The Nature of Address Indicator (NAI) field defines the address range for a specific numbering plan. The exact meaning depends on the numbering plan, not on GTI values. Figure 9-20 shows the NAI values [60]. Figure 9-20. The Nature of Address (NAI) Values [60] [View full size image] Address Information (AI) The AI contains the actual Global Title digits. These include enough of the most significant portion of the actual address digits to identify the destination node. For example, if a toll-free number of 800-123-4567 is dialed, the AI field might contain the digits 800 to identify an SCP to which the tollfree query should be sent. As shown in Figure 9-21, the address information is predominantly coded in Binary Coded Decimal (BCD) using four bits to code each digit. Figure 9-21. BCD Encoding of Address Digits [View full size image] As an example of the parameters found for GT format "0100,"we consider SCCP addressing for GSM-MAP messages (which is discussed in Chapter 13, "GSM and ANSI-41 Mobile Application Part [MAP]). For Inter-PLMN addressing, the
CdPA/CgPA contains the following values: SSN Indicator = 1 (SSN included); GT Indicator = 0100, GT includes Translation Type, Numbering Plan, Encoding Scheme and Nature of Address Indicator; TT = 00000000 (not used), and Routing Indicator = 0 (routing on GT).

CÓ THỂ BẠN MUỐN DOWNLOAD