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

Node A Node B 1 ASE-1 b TC-Primitives TCAP-A 4 N-Primitives SCCP-A MTP-Primitives MTP-A I Components --w---B- TCAP Messages TC-Primitives -t TCAP-B N-Primitives SCCP-B MTP-Primit

15

TRANSACTION CAPABILITIES

APPLICATION PART

the message transfer part (MTP) [l-3], enables application service elements (ASE) at two nodes (the TCAP term for signaling points) to conduct trans- act ions

TCAP is similar in many respects to the protocols defined by CCITT/ITU-T

recommendations

and have been revised in 1993 by ITU-T [5-91

The U.S version of TCAP has been specified by ANSI [lo] The work on this version started before the publication of the initial CCITT recommendations

differences in coding, between the two versions Sections 15.1-15.4 of this chapter follow the CCITI’ version Section 15.5 describes the main differences

of the U.S version

During a transaction, one (usually) or more (rarely) remote operations are executed The operation is requested by an ASE at one node, and executed by

involve “peer” ASEs (dedicated to the same application) at the two nodes

417

Signaling in Telecommunication Networks John G van Bosse

Copyright  1998 John Wiley & Sons, Inc ISBNs: 0-471-57377-9 (Hardback); 0-471-22415-4 (Electronic)

Some remote operations provide information to the requesting ASE For

requests its peer to translate an 800 number into a routing number Other remote operations provide instructions to the requesting ASE In the chapters that follow, we shall encounter operations of both types

Fig 15.1-1 shows the SS7 entities involved in a transaction between ASE-1 and ASE-2 The physical message path traverses the TCAPs, SCCPs, and MTPs at the nodes, and a path in the signaling network, which transfers the message signal units (MSU) between the nodes

This section describes transactions at the component and the message level

operation, or the results of the operation A message (containing one or more

between ASE and TCAP in a node, and N-unitdata primitives are the interface between TCAP and SCCP [4,9]

To send a message, an ASE passes a series of TC-requests to the TCAP at its node, and TCAP passes the message to its SCCP, in a N-unitdata request When

destination ASE in its node, with a series of TC-indications

Node A Node B

1 ASE-1 b TC-Primitives

TCAP-A 4 N-Primitives

SCCP-A MTP-Primitives

MTP-A

I

Components w -B- TCAP Messages

TC-Primitives -t TCAP-B

N-Primitives SCCP-B MTP-Primitives

MSUs

- Physical Message Path

e -) Logical Message Paths

Figure 15.1-I Messages and message paths

) Components Portion

Figure 15.1-2 TCAP message

As shown in Fig 15.1-2, a TCAP message consists of a TCAPportion, which is processed by TCAP, and a components portion with one or more components,

represent the status of the transaction, as perceived by the sending ASE and TCAP

sender does not expect

transaction

a

a

Begin This message initiates a transaction

Continue This message is sent in response of a begin or continue message, and continues the transaction

End This message is sent

terminates the transaction

response to a begin or continue message,

Abort This message is sent when a fatal problem has been encountered during the transaction, and terminates the transaction

An abort message can originate at an ASE or a TCAP The other messages always originate at an ASE

always includes one (or more) invokes Continue and End messages sometimes include invokes

Return Result, Last (RR-L) This component is a final response to an invoke

It contains the information obtained in a successful operation

Return Result, Not Last (RR-A/L) This component is a non-final response to

an invoke, and contains a part of the information generated by the operation This component is necessary because the maximum length of a message signal

is about 240 octets Most operations yield information that fits within one component If the information is too voluminous, it is segmented, and carried

in one or more RR-NL components, and a final RR-L component

Return Error This component is a final response to an invoke, and indicates that the requested operation was executed, and has failed

indicates that the component cannot be processed, because its syntax is not correct

15.1.6 Application-independence

the structure (syntax) of components, but does not cover their information content

examples of Chapters 16 and 17

Figure 15.1-3 shows examples of TCAP message sequences in transactions that

sends a Begin message with an invoke 1 The vast majority of transactions require just two messages (Begin and End)-see cases (a) and (b) In case (a),

instruction, which is conveyed in an End message with invoke 2

execute invoke 1 It therefore returns a Continue message, whose invoke 2 requests the information After executing the invoke, ASE-1 sends a Continue

executes invoke 1, and returns a RR-L or an invoke in an End message Figure 15.1-4 shows a chain of two transactions, involving three ASEs ASE-

Node A

Node B

BEGIN [Invoke l]

END [RR-Last]

BEGIN [Invoke l]

END [Invoke 21 BEGIN [Invoke l]

CONTINUE [Invoke 21 CONTINUE [RR-Last l]

END [RR-Last 2 or Invoke 31

Figure 15.1-3 Transaction examples

Node A Node B

BEGIN [Invoke l]

w

0 a

@I

0 C

Node C ASE-3

E TCAP-C

BEGIN [Invoke 21

w END [RR-Last l]

N END [RR-Last 21

1

Figure 15.1-4 Chain transaction

initiates a transaction with ASE-3, sending invoke 2 ASE-3 executes invoke 2, obtains a result, and includes it in the RR-last 1 of its End message ASE-2 then executes invoke 1, and sends an End message with the result in RR-last 2

information elements (IE) We shall see that the term parameter is used also, but has a restricted meaning

reference number (IE.1, etc) These numbers are used in the sections that follow

Table 15.2-l Information elements in TCAP portion of message

Message

Information Element

IE.l Unidirectional

IE.6 Originating-TID

IF.7 Destination-TID

IE.9 U-Abort-Information

IE.10 Component-Portion

C

C

C

C

P

P

P

C

M

M

M

M

0

0

CONT: Continue UNIDIR: Unidirectional TID: Transaction-ID (identity) C: Constructor P: Primitive

Source: Rec Q.773 Courtesy of ITU-T

Table 15.2-1 lists the IEs in the transaction portion of TCAP messages IE.l through IE.5 represent the individual message types

The TCAP at a node has a pool of transaction-identities (TID), which are

transaction is initiated, a TID is allocated When the transaction ends, the TID

is returned to the pool

specifies the TID of the transaction at the originating (sending) node

the transaction at the destination (receiving) node

and indicates why TCAP has aborted the transaction

and indicates why the ASE has aborted the transaction

component portion

TCAP INFORMATION ELEMENTS 423

Table 15.2-2 Information elements in components

Component

IE.ll

IE.12

IE.13

IE.14

IE.15

IE.16

IE.17

IE.18

IE.19

IE.20

IE.21

IE.22

IE.23

IE.24

IE.25

IE.26

Return-Result-Not-Last C

Return-Result-Problem P

Return-Error-Problem P

M

M

M

M

M

M

M

M

#

#

#

#

RETRSL: Return-Result-Last (RR-L) RETRSNL: Return-Result-Not-Last (RR-NL) RETERR: Return-Error C: Constructor P: Primitive #: One of the IEs is mandatory in reject components @: One of the IEs is mandatory if the component includes more than one parameter

Source: Rec Q.713 Courtesy of ITU-T

The mandatory (M) and optional (0) IEs in the various components are listed

in Table 15.2-2 Elements IE.ll through IE.15 represent the component types

components, it is a reference number that identifies an invoke in a transaction

A return-result, return-error, and reject component is a response to a received invoke, and has the IE.16 value of that invoke

IE 7 7 Linked-ID This IE is mandatory in an invoke component that is sent as the response to a received invoke In this case, IE.16 identifies the sent invoke, and IE.17 identifies the received invoke

specifies the requested operation

IE.79 Error-Code This IE is mandatory in return-error components, and indicates why a requested operation has failed

be processed

processed

result cannot be processed

cannot be processed

A reject component has to include IE.20, or IE.21, or IE.22, or IE.23

If a component contains more than one parameter, it has to include an IE.24

or IE.25

ponent

In invoke components, parameters specify the operands for the requested operation

In return-result components, parameters hold the results of the operation

In return-error and reject components, the parameters are the information

rejection of a received component

This section describes the formats and coding of the TCAP messages defined by

15.3-1 The tag field indicates the IE type, and the length field indicates the number of octets in the value (or contents) field

A TCAP IE can be a primitive IE or a constructor IE The value field of a primitive IE contains the information of the IE Primitive IEs should not be confused with the primitives that pass information between the SS7 protocols

in a node (Section 7.3.2)

TCAP FORMATS AND CODING 425

- Bits

Value

(Information

of DE)

(a)

- Bits

q Length Tw I/ /I / c

Value

- l

(b) I I

I

- Bits

Cc)

Figure 15.3-l Structure of information elements (a): primitive IE (b) constructor IE (From Rec Q.773 Courtesy of IT&T.)

The value field of a constructor IE holds one or more other IEs, which may

be primitives or constructors

In Tables 15.2-l and 15.2-2, the primitive and constructor IEs are marked (P) and (C) The constructor IEs, and the information in their value fields, are listed below

/E.I-/ES The tag fields of these IEs identify a message type, and the value fields hold all other IEs in the message

transaction

IE 70 Component-Portion The value field of this IE holds the IEs of all components in the message

IE.1 IIIF.15 The tag fields of these IEs identify a component type, and the value fields hold all other IEs of the component

IEs in the component, in a predetermined order

IE.25 Parameter-Set The value field of this IE holds all parameter IEs in the component, in any order

As an example, Fig 15.3-2 shows the format of a begin message with one

IE.2 (T)

IE.2 (L) ,

/ ’ IE.6 (T) / I

/ IE.6 (L) /

IE.6 (V) / IE.10 (T) ’

I IE.10 (L) /

IE.11 (L)

IE.2 (V) IE.11 (V)

Figure 15.3-2 Information elements in Begin message IE.2: Begin message IE.6: Originating transaction ID IE.10: Components-portion IE.11: Invoke component IE.16: Invoke ID IE.18: Operation code IE.24: Parameter sequence IE.26: Parameters

IE 10 (V)

IE 11 (T) /

/

; IE.26 (T) / I IE.26 (L)

I L

I IE.26 (V)

I IE.26 (T)

I

I IE.26 (L)

I

I IE.26 (V) IE.26 (T) IE.26 (L) IE.26 (V)

invoke The TCAP portion consists of IE.2 (begin message), whose value field holds an IE.6 (originating-TID), and an IE.10 (component-portion)

The value field of IE.10 holds an IE.ll (invoke component), whose value

(parameters)

An IE tag field consists of one, two, or three octets, and has three fields-see Fig 15.3-3

C/ass Field Bits H,G of octet 1 indicate the IE class:

Universal Aplication-wide Context-specific Private use

00 9

01

110

191 The class implies where the IE is specified Universal IEs are specified in

data communication networks, and some are also used in TCAP Application-

are specified within the context of the next higher constructor IE A context- specific tag value thus has different meanings, which depend on the class of the constructor Private use IEs are defined by various national organizations

TCAP FORMATS AND CODING 427

Octets 4 - Bits

j - H,G F EID,C,B,A

1 Class Type Tag Code

Figure 15.3-3 Tag fields (From Rec Q.773 Courtesy of ITU-T.)

The “class” concept enables the various standards organizations to define IEs independently of each other

Type Field Bit F of octet 1 indicates whether the IE is a constructor (F = 1)

or a primitive (F = 0)

Tag Code Field The tag code identifies the IE (Fig 15.3-3) In one-octet tags, bits E A hold a tag code that ranges from 00000 through 11110 (decimal

0 through 30) In two-octet tags, bits E A in octet 1 are set to 11111, and bits G A in octet 2 hold a tag code that ranges from 31 through 127 In three-octet tags, the tag code (bits G A of octets 2 and 3) ranges from 128 through 16383 Table 15.3-1 lists the tag codes of the IEs discussed in Section 15.2 The tags

of IEs in the transaction portion are coded “application-wide.” The tags of most IEs in the components portion are coded “context-specific,” i.e in the

“universal” Note that the tag codes of IE.16, IE.18, and IE.19 are identical Their meanings are implied by the component types which hold these IEs Parameter IEs are application-dependent, and their tag codes can be found

in the specifications of individual applications

This section gives examples of IE value field (V) coding for the primitive IEs More details can be found in Ref [7]

E6(V’ and E7(V’ The value fields of the originating and destination TIDs hold reference numbers (binary coded integers) that identify a TID at a node E8(V’ P-Abort-Cause, The one-octet field indicates why a TCAP has aborted the transaction

Table 15.3-l Tag codes

f- Bits

Information Elements in TCAP Portion IF.1

IE.2

IE.3

IE.4

IE.5

IF.6

IE.7

IE.8

IF.9

IE.10

Unidirectional Begin Continue End Abort Originating-TID Destination-TID P-Abort-Cause U-Abort-Information Component-Portion

01 1

01 1

01 1

01 1

01 1

01 0

01 0

01 0

01 1

01 1 Information Elements in Components Portion

10 1

10 1

10 1

10 1

10 1

00 0

10 0

00 0

00 0

10 0

10 0

10 0

10 0

00 1

00 1

00001

00010

00101

00100

00111

01000

01001

0 10 10

0 10 1 1

01100

00001

00010

00111

00011

00100

00010

0 0 0 0 0

00010

00010

0 0 0 0 0

00001

00010

00011

10000

10001

Source: Rec Q.773 Courtesy of ITU-T

IE 76(V) and IE 17(V) The value fields of invokeIDs and linked-IDS hold references numbers (binary coded integers) that identify an invoke in a transaction

IE 7 8(V), IE 7 9(V), and E26(V) The operation-code, parameter, and error- code IEs are application-specific The coding of their value fields are defined in the specifications of the individual ASEs

E2O(V) Examples of value field codes in the general-problem IE: