Tài liệu Tín hiệu trong các mạng viễn thông P14 ppt

In the second place, SCCP also allows a calling subsystem to address a called subsystem by a global title GT.. This is a message sent by an SCCP at either end of a signaling connection,

SCCP has been documented by CCITT [4], and later by ITU, in a series of Recommendations [5-81 The U.S version has been specified by ANSI [9]

Figure 14.1-1 shows SCCP and its relations with the other parts of SS7 TCAP and ISUP are SCCP users In turn, the ASEs at a signaling point are users of TCAP, and can be considered as “indirect” SCCP users Each SCCP user at a signaling point has a subsystem number (SSN) that ranges 1 through 127 When SCCP receives an incoming message from MTP, it uses SSN to deliver the message to the appropriate SCCP user (in the case of ASEs, the message is passed to TCAP, which then delivers it) In this chapter, the term subsystem is used to denote an SCCP user

385

Signaling in Telecommunication Networks John G van Bosse

ISBNs: 0-471-57377-9 (Hardback); 0-471-22415-4 (Electronic)

Signaling Point Functions ASE

ISUP TCAP

Figure 14.1-1 Position of SCCP in signaling system No.7 (From Rec Q.700 Courtesy of ITU-T.)

14.1 l Message Transfer Enhancements

SCCP enhances the message transfer capabilities of SS7 in two principal ways

In the first place, MTP uses the service indicator (SI) (8.8.3) in an incoming message to deliver it to the appropriate MTP user (SCCP is one of them) SI has a range 0 through 15, limiting the number of MTP users to 16 SCCP expands the addressing capability of SS7, allowing up to 127 subsystems at a signaling point

In the second place, SCCP also allows a calling subsystem to address a called subsystem by a global title (GT) This is a functional address, in the form of a digit string, that cannot be used for message routing The purpose of GTs is discussed in Section 14.3 SCCP includes provisions to translate a global title into an address that can be used to route a message to its tion subsystem

SCCP provides four service classes to its users:

l Class 0: Basic connectionless service

l Class 1: Connectionless service with sequence control

l Class 2: Basic connection-oriented service

l Class 3: Connection-oriented service with flow control

In connectionless services, the SCCPs at the signaling points of the two subsystems involved in a transaction are not aware of the transaction In connection-oriented service, a (virtual) “signaling connection” between the SCCPs is established first, making both SCCPs aware of the transaction At the end of the transaction, the signaling connection is released

Messages for on-line transactions (Section 13.1) are usually transferred by

primarily for the transfer of messages in off-line transactions that involve a

INTRODUCTION 387

large amount of data In addition, one group of on-line transactions in the

14.1.3 Structure and Interfaces of SCCP

SCCP consists of the parts shown in Fig 14.1-2 Connectionless control (SCLC) and connection-oriented control (SCOC) handle the message transfer

in the corresponding services

N-exped Data Request

N-data Ack Request

N-exped Data Indication

N-data Ack Indication

SCCP Connection- less

(SCLC)

SCCP Routing Control (SCRC)

I Msg Received for

Unavailable Local SS

I

SCCP Management (SCMG)

MTP-Transfer hdication MTP-Transfer Request

MTP-Pause Indication MTP-Resume Indication MTP-Status Indication Figure 14.1-2 Structure and interfaces of SCCP (From Rec Q.714 Courtesy of ITU-T.)

Routing control (SCRC) determines the destinations of outgoing messages, and routes incoming messages to SCLC or SCOC, which then deliver them (directly, or via TCAP) to the destination subsystems

signaling network management (Section 8.8) It aims to maintain the message traffic of the SCCP users under congestion and failure conditions in the signaling network, signaling points, and subsystems

The interfaces between SCCP and MTP are as described in Sections 8.8 and 8.9 MTP-transfer primitives are the interface between SCCP routing control

resume and MTP-status indications to SCCP management

N-Primitives form the interface between SCCP and its local subsystems (either directly, or via TCAP) We distinguish three groups of primitives The group to/from connection-oriented control, the group to/from connectionless control, and the group to/from SCCP management

message (UM) fields of MTP3 messages (Fig 8.8-l)

The format of SCCP messages is very similar to that of ISUP messages (see Fig

parameters with fixed or variable lengths, and optional (0) parameters As

appear with their value (contents) field only The mandatory variable-length parameters have a pointer, and a length and a value field Each optional parameter has a name, length, and value field The name field is also known as tag field

The messages that will be discussed in this chapter are outlined below [4,6] The first two apply to connectionless SCCP service, the others are used in connection-oriented service

Unitdata Message (UDT) This is sent by an SCCP, to transfer subsystem data Unitdata Service Message (UDTS) This is sent to the SCCP that originated a UDT message, by an SCCP that cannot deliver a received UDT message to its destination

SCCP MESSAGES AND PARAMETERS 389

Connection Request Message (CR) This is a request from a calling SCCP to

a called SCCP, to set up a signaling connection

Connection Confirm Message (CC) This is sent by called SCCP, indicating that it has set up the signaling connection

indicating that it is unable to set up the signaling connection

Data Form 7 (DT1) This is a message sent by an SCCP at either end of a signaling connection, and containing subsystem data (used in class 2 operation)

Data Form 2 0 This is a message sent by an SCCP at either end of a signaling connection It contains subsystem data, and acknowledges the receipt

of messages (class 3 operation)

Released Message @SD) This is sent by SCCP at one end of the signaling connection, and indicating that it wants to release the signaling connection

message, and indicating that the sending SCCP has released the connection

The message type codes of these messages are listed in Table 14.2-1

This section describes the most important parameters in the above messages

At this point is it suggested merely to peruse the descriptions, and to refer back

to them when reading the later sections of this chapter

parameter has a reference number (for example, Par.1) In the sections that follow, a parameter is always identified by name and reference number

Table 14.2-I Message type codes of SCCP messages

390 SIGNALING CONNECTION CONTROL PART

Table 14.2-2 Parameters in SCCP messages

Message Acronyms CCCDDRRUU

Called party address (CDA)

Calling party address (CGA)

Destination local reference

CL: connectionless service CO: connection-oriented service

Source: Rkc Q.712 Courtesy of ITU-T

Table 14.2-2 lists the parameters, and the messages in which they appear The focus is on parameter contents, and only the “value” fields are shown in the figures The name (tag) fields of parameters that can appear as optional parameters are coded as follows:

SCCP MESSAGES AND PARAMETERS 391

Point Code (PC) Subsystem Number (SSN)

Figure 14.2-I General format of: called party address (ParA), calling party address (Par.2) PCI: point code indicator, SSNI: subsystem number indicator, GTI: global title indicator, RTI: routing indicator (From Rec Q.713 Courtesy of ITU-T.)

combination of point code (PC), subsystem number (SSN), and/or global title (GT) The general format is shown in Fig 14.2-1

Octet 1 indicates the presence or absence of PC, SSN, and GT in the address

Point Code hdicator (PC/) This indicates the presence (1) or absence (0) of

PC

Subsystem Number indicator (SSAH” This indicates the presence or absence

of SSN

Global Title hdicator (GT/) If GTI = 0000, no global title is present If GTI

is 0001, 0010, Doll, or 0100, a GT is present The GT format depends on the value of GTI

Routing hdicator (RTI) If the called address includes a global title, the send- ing SCCP specifies with RTI how the receiving SCCP should route the message:

RTI = 0 Global title translation should be performed, and routing should

be based on the translation result

RTI = 1 GT translation should not be performed, and routing should be

based on the destination point code (DPC) in the MTP routing label of the message (Section 8.8)

Octets 2 through n contain PC, SSN, and GT, if included

Point Code (PC) The point codes in CCITT No.7 signaling and ANSI No.7 signaling have respectively 14 and 24 bits (Section 7.2), and occupy three and two octets, respectively

392 SIGNALING CONNECTION CONTROL PART

Subsystem Number (WV) The one-octet SSN field identifies the SCCP user (subsystem) Examples of SSN codes standardized by CCIIT/ITU:

+- Bits

SSN field not used

SCCP management

ISDN user part

administration part (OMAP)

Mobile application part (MAP)

Global Title The GT contents consist of the translation type (TT) and the

global title address (GTA)-see Fig 14.2-2 We first consider GTA, which contains several parameters The presence (P) or absence (A) of the octets with individual parameters is indicated by the value of GTI

GT always includes GTA-consisting of a digit string (octets d through n)

and may include the following parameters:

Encoding Scheme (octet b)

f- Bits

4 3 2 1

Numbering Plan (octet b)

+- Bits

8 7 6 5

Translation Type (octet a)

Most GT translations yields the PC + SSN (point code and subsystem number)

of a called subsystem TT specifies the type of translation to be performed (see Section 14.3.3) The TT values in a particular network are established by the network operator

P ar.2 Calling Patiy Address (CGA) The format and coding are as in Par.l

PC and SSN are always included; GT is present only in transactions between signaling points in different networks

the “called” (destination) signaling point of a connection-oriented message

Par.4 Protocol C/ass (P/X) This represents the class of SCCP operation (Section 14.1.2), and occupies bits 4, 1 of one octet:

Par.5 Refusal Cause This one-octet parameter appears in the connection

connection cannot be set up, for example:

- f- Isits

(b) Unknown destination address 0 0 0 0 0 100

Cause (a) indicates that the called subsystem has refused the connection Causes (b) indicate that an SCCP along the message path was unable to transfer the connection request message

Released (RLSD) messages only It indicates why a signaling connection is being released, for example:

far.7 Return Cause A one-octet parameter that appears in unitdata service (UDTS) messages only It indicates why a unitdata message is being returned, for example:

Return causes (a) and (b) appear in UDTS messages originated at the SCCP

in signal transfer point that has been unable to translate a global title UDTS messages with return causes (c) and (d) are sent by the SCCP in the destination signaling point UDTS messages, with return causes (e) and (f), can be sent by any SCCP in a signaling point along the message path

Par.8 Return Option (Ro)m This appears in unitdata (UDT) messages only

messages only (class 2 connection-oriented service) Only bit 1 is used:

Bit 1

0 Last data form of transaction

Par 7 0 SeguencinglSegmenting (Fig 14.2-3) This appears in data form 2 messages (class 3 connection-oriented service) only P(S) and P(R) are send and receive sequence numbers Bit M indicates whether more data forms follow:

M = 0 Last data form in a sequence

M = 1 More data forms follow

Par 7 1 Source Local Reference (SLR) This is a reference number (three octets) that identifies a signaling connection at the SCCP in the “calling” (source) signaling point of a connection-oriented message

transferred transparently by SCCP

This section examines the role of connectionless SCCP in the transfer of messages between subsystems The material in this section is illustrated by a transaction in which an exchange queries a network database to obtain the translation of an 800 number into a routing number (2.1.3)

1; / * -$ - 2 j : /

Figure 14.2-3 Sequencing/segmenting (Par.1 0)

396 SIGNALING CONNECTION CONTROL PART

- - + -w

Figure 14.3-1 Transaction to obtain 800-number translation SIP: signal transfer point

In Fig 14.3-1, the subsystems (ASEs) denoted by Q800 and located at exchanges A and B, make the 800-number queries The subsystems denoted by R800 are located at network databases C and D, and respond to these queries with messages that contain the national number of the called party, and routing and charging information Databases C and D are “mates,” and contain the same information Normally, C and D are both in-service, and the network sends 50% of the query traffic to each of them However, if C or D is out-of- service, all queries are sent to its mate

When a R800 has received a query, it sends a response message with routing instructions for the 800 call

Points E, F, H, and K are signal transfer points in the signaling network The point codes (PC) in signaling points A through K are a through k The subsystem numbers (SSN) for the Q800 and RSOO ASEs are q and r

When reading the material that follows, it is helpful to look up the parameter descriptions in Section 14.2.3

In connectionless service, transaction messages are passed between SCCP and MTP as SCCP unitdata messages- see Fig 14.3-2 [4,6] The message type code (MTYP) indicates: unitdata message All message parameters are mandatory:

Par 7 Called Pafly Address &DA) This is the address of the subsystem for which the message is intended

Par.2 Calling Party Address (CGA) This is the address of the subsystem that originated the message

CONNECTIONLESS SCCP 397

Calling Party Address (CGA) Subsystem Data

Figure 14.3-2 SCCP unitdata message (From Rec Q.713 Courtesy of W/T.)

connectionless service (0), or connectionless service with sequence control (1)

wishes to be informed if its message cannot be delivered

Par 72 Subsystem Data This can be a TCAP message (package), or an ISUP message

14.3.2 Primitives

In connectionless SCCP, subsystem data are passed in N-unitdata requests and indications The parameters in the primitives are shown in Fig 14.3-3 [4,5] On receipt of a N-unitdata request, SCCP forms an unitdata message, using the information in the request In connectionless service, SCCP does not maintain address information for the messages of individual transactions, and all N- unitdata requests therefore include a called and calling party address

determines the destination point code (DPC) and signaling link selector (SLS) for the message, and passes the outgoing unitdata message to MTP in a MTP- transfer request (see Fig 14.1-2 and Section 8.8) Service indicator value (SI)

= 0011 indicates an SCCP message

Incoming messages with SI = 0011 are passed by MTP to SCCP, in MTP- transfer indications SCCP routing control passes the subsystem data in N- unitdata indications to ISUP or TCAP, depending on the value of SSN in the called party address

The N-unitdata indications include all information listed in Fig 14.3-3, except the called party address, the protocol class and return option (they are not significant to the receiving TCAP or ISUP) TCAP then delivers the information in the package to the subsystem specified by SSN

l Called Party Address

l Calling Party Address

l Protocol Class (in Requests only)

l Return Option (in Requests only)

l Subsystem Data: (TCAP Package,

l Destination Point Code

l Signaling Link Selector (in Requests only)

l SCCP Message Figure 14.3-3 N- and MTP-primitives (From Rec CL71 1 Courtesy of ITU-T.)

14.3.3 Global Title Translation

A SCCP called party address (Par.1) can contain various combinations of PC, SSN and/or GT We now explore the reasons for global titles and GT translations

A subsystem in a network is uniquely identified by the combination of the point code PC of its signaling point, and its SSN at that point.- If an SCCP message has a PC + SSN called party address, the MTPs along the message path then use PC to route the message to its destination signaling point, and the SCCP at this point delivers it to the subsystem specified by SSN For example,

in Fig 14.3-1, a SCCP message with called party address PC = c, SSN = r, is delivered to subsystem RSOO in database C

A global title is a “functional” address of a subsystem in an exchange or database The reason for these functional addresses is illustrated with the example of Fig 14.3-1

Suppose that the set-up of a call with a called 800 number, say 800-123-

4567, has reached exchange A Subsystem Q800-A then has to send a query message to an RSOO subsystem at a database that

number-in this example: databases C and D

stores the translation for this

In principle, exchange A could translate the received 800 number into a PC + SSN called party address of an R800 in the appropriate database However,

CONNECTIONLESS SCCP 399

this would require “800 number” translation tables in all exchanges, and would entail a large effort when an item in the tables has to be added or removed

A better arrangement is to let the exchanges use the received 800 number as

a global title (GT) address, which is the “functional” address of an R800 at a database with information on the 800 number, and install the GT translation capability in the SCCPs of the signal transfer points (STP) of the network The SCCP at the originating exchange then routes the query message to a directly connected STP, whose SCCP translates GT into the PC + SSN address of the destination From this point on, the message can be routed by MTP to its destination

The number of exchanges in a network greatly exceeds the number of STPs, and placing the GT translation capability in the SCCPs at the STPs instead of

in the exchanges greatly reduces the effort to update the translation data

A GT consists of two parts, known as the GT address (GTA), which is a digit string received from a calling subscriber, and the translation type (IT), which indicates the desired translation (Fig 14.2-2) For example, if GTA is the national number of a subscriber (S), one value of TT could indicate that GTA

is to be translated into the PC + SSN address of an ASE in the maintenance center that covers S; another TT value could require a translation that yields the PC + SSN address of an ASE in the revenue accounting center that covers

S, and so on

14.3.4 Transfer of Unitdata Messages

We now examine the transfer of unitdata messages for an 800 number query- response transaction- see Fig 14.3-1 We assume that all entities in the figure are part of the same telecommunication network

Query Mess&gem Suppose that the set-up of an 800 call has reached exchange A The Q800-A then launches a query to a database, to obtain the routing number for the call We assume that the call-routing information for this particular 800 number is stored in R800-C and R800-D (at databases C and D)

primitives at signaling points A, E and D, and in the message signal unit (MSU) that carries the first unitdata message

Q800-A, and includes them in the N-unitdata request to SCCP-A The CDA is

a GT in which the translation type = t, and the address = n (the called 800 number) The translation type indicates that n has to be translated into the SP + SSN address of an RSOO at a database with information on that number SCCP-A enters GT in the CDA field of the unitdata message, PC = a, SSN

= q in the CGA field, and sets the routing indicator (Fig 14.2-1) to RTI = 0, indicating that a GT translation is needed Since SCCP-A has received a GT called address, and knows that the SCCP-E can perform GT translations, it

400 SIGNALING CONNECTION CONTROL PART

Database D PC=d R800-D SSN=r

P

CGA: PC = a; SSN = q -m m

I TCAP-D ; CDA: PC = d; SSN = r; CGA: PC = a; SSN = q

MTP-D

P

i - J

Figure 14.3-4 Address information in the first SCCP unitdata message of a transaction

includes the MTP address of signaling point E (DPC = e) when passing the message MTP-A then forms the MSU, and transfers it to STP-E

SCCP-E translates the GT, and obtains the addresses PC= c, SSN = r, and

PC = d, SSN = r, of the RSOO units at databases C and D Assuming that SCCP-E selects database D, it enters SSN = r in the CDA of its outgoing message, and passes it to its MTP-E, in a MTP-transfer request which includes destination point code DPC = d It also sets the routing indicator to RTI = 1 The MTP-E routes the MSU to MTP-H, which routes it to database D SCCP-D receives the message from MTP-D, and passes it to TCAP-D in a N-unitdata indication, which includes the calling address PC = a, SSN = q Finally, TCAP-D delivers the message to R800-D

Response Message R800-D uses the received CGA (PC = a, SSN = q) as the CDA for its response message SCCP-D passes the message to MTP-D, in a