03-Chapter 3 MTP and MTP3B

Technical Manual – Signaling & ProtocolsTable of Contents

Table of Contents

Chapter 3 MTP and MTP3B.........................................................................................................3-1

3.1 MTP................................................................................................................................. 3-1

3.1.1 Overview...............................................................................................................3-1

3.1.2 MTP3 Functions....................................................................................................3-2

3.1.3 Message Format....................................................................................................3-4

3.1.4 Signaling Procedures..........................................................................................3-15

3.2 MTP3B........................................................................................................................... 3-17

3.2.1 Overview.............................................................................................................3-17

3.2.2 Introduction of MTP3B.........................................................................................3-18

3.2.3 MTP3B Message Structure.................................................................................3-20

3.3 SAAL.............................................................................................................................. 3-22

3.3.1 SAAL Function Structure.....................................................................................3-22

3.3.2 SSCOP................................................................................................................3-23

3.3.3 SSCF................................................................................................................... 3-28

3.3.4 LM....................................................................................................................... 3-29

i

Technical Manual – Signaling & ProtocolsChapter 3 MTP and MTP3B

Chapter 3 MTP and MTP3B

3.1 MTP

3.1.1 Overview

Narrowband Message Transfer Part (MTP) is the traditional TDM based transmission

system. Its major function is to enable reliable transmission of signaling messages

over signaling network, and to take measures to avoid or minimize message loss,

duplication or mis-sequencing in case of system fault or signaling network fault. The

functions of the MTP are separated into three functional levels: signaling data link

(MTP1), signaling link functions (MTP2) and signaling network functions (MTP3). The

structure of the MTP protocol stack is illustrated in Figure 3-1.

Figure 3-1 Structure of the MTP protocol stack

The MTP in the signaling-processing module of MSC and HLR is used to convey SS7

user signaling (ISUP/SCCP). It is designed completely in compliance with the ITU-T

Recommendations Q.701 to Q.710 Series.

I. MTP1

Signaling data link is the level 1 function (MTP1) of the MTP. It defines the physical,

electrical and functional characteristics of a signaling data link and the means to

access it. It is equivalent to the physical layer of the OSI reference model and is used

to generate and receive the signals through the physical channels.

A signaling data link is a bidirectional transmission path for signaling, comprising two

data channels operating together in opposite directions at the same data rate. The

standard bit rate on a digital bearer is 64kbit/s. A transmission link at a lower bit rate

(for example, 4.8kbit/s) or at a higher bit rate (for example, 2048kbit/s) may also be

applied.

1


II. MTP2

Signaling link functions are the level 2 functions (MTP2) of the MTP. They are used to

transfer signaling to a data link. The level 2 functions together with a level 1 signaling

data link provide a signaling link for reliable signaling transfer between two directly

associated signaling points.

The signaling link functions include signal unit delimitation, signal unit alignment, error

detection, error correction, initial alignment, processor outage, level 2 flow control and

signaling link error monitoring.

III. MTP3

Signaling network functions are the level 3 functions (MTP3) of the MTP. They

implement the functions of the network layer of the OSI reference model, and are

used to enable management message transmission between the signaling points for

the purpose of ensuring a reliable transfer of the signaling messages over the

signaling network in case that signaling links and signaling transfer points fail.

3.1.2 MTP3 Functions

The signaling network functions provided by the MTP3 must ensure a reliable transfer

of the signaling messages even in the case of the failure of signaling links and

signaling transfer points. Therefore, they include the appropriate functions and

procedures necessary both to inform the remote parts of the signaling network of the

consequences of a fault, and to appropriately reconfigure the routing of messages

through the signaling network

The signaling network functions are divided into two basic categories, namely

signaling message handling and signaling network management. See Figure 3-2.

2


Figure 3-2 Signaling network functions

I. Signaling Message Handling

The purpose of the signaling message handling functions is to ensure that the

signaling messages originated by a particular User Part at a signaling point

(originating point) are delivered to the same User Part at the destination point

indicated by the sending User Part.

The signaling message handling functions are divided into:

the message routing function, used at each signaling point to determine the

outgoing signaling link on which a message has to be sent towards its

destination point;

the message discrimination function, used at a signaling point to determine

whether or not a received message is destined to the point itself. When the

signaling point has the transfer capability and a message is not destined to it,

that message is transferred to the message routing function;

the message distribution function, used at each signaling point to deliver the

received messages (destined to the point itself) to the appropriate User Part.

I. Signaling Network Management

The purpose of the signaling network management functions is to provide

reconfiguration of the signaling network in the case of failures and to control traffic in

case of congestion. Such a reconfiguration is effected by use of appropriate

3


procedures to change the routing of signaling traffic in order to bypass the faulty links

or signaling points. Moreover, in some circumstances it is necessary to activate and

align new signaling links, in order to restore the required signaling traffic capacity

between two signaling points. When the faulty link or signaling point is restored, the

opposite actions and procedures take place, in order to reestablish the normal

configuration of the signaling network.

The signaling network management functions are divided into:

Signaling traffic management

Signaling link management

Signaling route management

These three signaling network management functions are activated in the appropriate

circumstances when some change occurs to the state of a signaling link, route or

signaling point. The details are described as follows:

2) Signaling traffic management function: This function is used for the diversion of

signaling traffic from one link or route to one or more alternative link or route,

used for MTP restart of signaling points, or used to temporarily slow down

signaling traffic in the case of congestion at signaling points.

3) Signaling link management function: This function is used to restore a faulty

signaling link, activate an idle (unaligned) link, and deactivate an aligned

signaling link.

4) Signaling route management function: This function is used to distribute the

information about the signaling network status with the objective of blocking or

unblocking a signaling route.

3.1.3 Message Format

For the purpose of meeting the requirements of the MTP for transmitting a variety of

signaling messages, three basic types of signal unit are defined: Message Signal Unit

(MSU), Link Status Signal Unit (LSSU), and Fill-In Signal Unit (FISU).

Message signal units are used to carry messages of the user parts, signaling

network management messages, and signaling network testing and maintenance

messages.

Link status signal units provide the information about the link status in order to

perform control actions such as connection and restoration on the signaling link.

Under normal conditions, when no message signal units or link status signal

units are to be transmitted over the signaling links, fill-in signal units are sent

continuously with the feeding objective, for the purpose of maintaining the normal

operation of the signaling links.

The structure of the signal units is illustrated in Figure 3-1.

4


MSU F CK SIF SIO LI FIB FSN BIB BSN F

8 16 8N(N≥2) 8 2 6 1 7 1 7 8

Basic format of a message signal unit (MSU)

First bittransmitted

LSSU F CK SF LI FIB FSN BIB BSN F

8 16 8 or 16 2 6 1 7 1 7 8

Format of a link status signal unit (LSSU)


FISU F CK LI FIB FSN BIB BSN F

8 16 2 6 1 7 1 7 8

Format of a fill-in signal unit (FISU)



8 16 8N(N≥2) 8 2 6 1 7 1 7 8




8 16 8N(N≥2) 8 2 6 1 7 1 7 8




8 16 8 or 16 2 6 1 7 1 7 8




8 16 8 or 16 2 6 1 7 1 7 8




8 16 2 6 1 7 1 7 8




8 16 2 6 1 7 1 7 8



Figure 3-1 Format of the signal units

A signal unit is divided into two parts from the structure point of view. One is shared

by the variety of signal units and required by the MTP processing; this part comprises

8 fixed length fields. The other contains the signaling information to be handled by the

user part.

I. The Part Required by the MTP Processing

This part includes Flag (F), Forward Sequence Number (FSN), Forward Indicator Bit

(FIB), Backward Sequence Number (BSN), Backward Indicator Bit (BIB), Length

Indicator (LI), Check bits (CK), Status Field (SF), and Service Information Octet (SIO)

(SIO only exists in message signal units).

Flag (F)

There is a flag at the start and the end of every signal unit. In the transmission of

signal units, the opening flag of a signal unit is normally the closing flag of the

preceding signal unit. Therefore, a signal unit will be delimitated once the opening

and closing flags are successfully found from the information stream.

The bit pattern for the flag is 01111110.

In addition to signal unit delimitation, several flags may be inserted between signal

units, in case that the signaling links are overloaded, in order to cancel controlling and

reduce loading.

Forward sequence number (FSN)

The forward sequence number is the 7-bit sequence number of the message signal

unit in which it is carried. At the transmitting terminal, all the transmitted message

signal units are allocated with a forward sequence number which is numbered from a

cyclic sequence ranging from 0 to 127. At the receiving terminal, the forward

sequence numbers of the received message signal units are used to detect the order

of the message signal units, as a part of the acknowledgement function. If

5


retransmission is required, the forward sequence number also serves to identify the

signal unit to be retransmitted. A fill-in signal unit and a link status signal unit share

the forward sequence number of the last transmitted message signal unit instead of

being assigned again.

Forward indicator bit (FIB)

One bit is occupied. The forward indicator bit is used in the retransmission procedure

of message signal units. It has the same status as the received backward indicator bit

during non-error operation. A change made to the value of the received backward

indicator bit indicates a request for retransmission. The signaling terminal also

changes the value of the forward indicator bit (changing 1 to 0 or 0 to 1) when

retransmitting the message signal unit, in order to keep consistent with the backward

indicator bit value, until the value of the backward indicator bit changes at receiving

another retransmission request.

Backward sequence number (BSN)

The backward sequence number is the sequence number of a message signal unit

being acknowledged. It is sent by the receiving terminal to indicate to the transmitting

terminal that the message signal unit is acknowledged (accepted successfully).

In the case of a request for a retransmission, the backward sequence number

indicates the sequence number for starting the retransmission.

In the operation of the signaling network, the transmitting terminal and the receiving

terminal of a message independent assign the forward sequence number.

Limited by the forward sequence number and the backward sequence number, not

more than 127 signal units can be transmitted while not be acknowledged.

Backward indicator bit (BIB)

The backward indicator bit provides a retransmission request for the received error

signal unit. If the received message signal unit is correct its value will be invariable

when a new signal unit is sent; otherwise this bit will be sent with a conversed value

(that is, 0 is changed to 1 or 1 is changed to 0), requesting the terminal peer to

retransmit the error message signal unit.

Length indicator (LI)

The length indicator is used to indicate the number of octets following the length

indicator octet and preceding the check bits. The length indicator differentiates

between the three types of signal units.

The 6-bit length indicator field is a number in binary code in the range 0~63 (decimal).

The length indicator values of the three types of signal units are as follows:

Length indicator = 0 Fill-in signal unit

Length indicator = 1 or 2 Link status signal unit

6


Length indicator > 2 Message signal unit

In the national signaling network, the length indicator is invariably set to 63 if the

signaling information field of a message signal unit is more than 62 octets. In the case

that the length indicator equals 63, the maximum length indicated by it cannot be

more than 272 octets.

Note that it is necessary to calculate the number of bits and the number of octets

between two flags in the receiving process of signal units. According to the CCITT, the

number of bits between two signal unit flags must be an integral multiple of 8. The

number of octets may be equal to 0 (if only flags are sent), be equal to 5 (fill-in signal

unit), or be less than or equal to m+7 (m is 272). For a number out of such range, the

signal unit is treated as error.

Check bits (CK)

The check bits field is used for error detection of a signal unit. It is composed of 16

bits.

The seven fields described above appear in all the three types of signal units. (Eight

such fields are mentioned in the previous section, where the closing flag is included.)

They are mandatory to every signal unit.

Status field (SF)

The status field is unique to link status signal units and is used to indicate the status

of a signal link.

The length of the status field may be one octet (8 bits) or two octets (16 bits).

If the status field is one octet, the link status is indicated by the lower three bits

currently, as shown in Table 3-1:

Table 3-1 Meanings of the link status indications in the status field

CBA Bits Identifier Indication Meaning

000 SIO Status indication “O” Out of alignment

001 SIN Status indication “N” Normal alignment

010 SIE Status indication “E” Emergency alignment

011 SIOS Status indication “OS” Out of service

100 SIPO Status indication “PO” Processor outage

101 ISB Status indication “B” Busy (link congestion)

Service information octet (SIO)

7


The service information octet field is unique to the message signal units. It contains

the service indicator (SI) and the sub-service field (SSF), as shown in Figure 3-2.

The field has 8 bits. The service indicator and the sub-service field occupy 4

respectively.

SISSF

MeaningDCBA

International networkSpare (for international use only)National networkReserved for national use

0 0 0 00 1 0 01 0 0 01 1 0 0

MeaningDCBA

Signaling network management messagesSignaling network testing and maintenance messagesSpareSCCPTelephone User PartISDN User Part

Data User Part

Spare

0 0 0 00 0 0 10 0 1 00 0 1 10 1 0 00 1 0 10 1 1 00 1 1 11 0 0 0

1 1 1 1

F CK SIF SIO

SISSF

MeaningDCBA

International networkSpare (for international use only)National networkReserved for national use

0 0 0 00 1 0 01 0 0 01 1 0 0

MeaningDCBA


Data User Part

Spare

0 0 0 00 0 0 10 0 1 00 0 1 10 1 0 00 1 0 10 1 1 00 1 1 11 0 0 0

1 1 1 1

MeaningDCBA


Data User Part

Spare

0 0 0 00 0 0 10 0 1 00 0 1 10 1 0 00 1 0 10 1 1 00 1 1 11 0 0 0

1 1 1 1

F CK SIF SIO

Figure 3-2 Format and codes of the service information octet

1) Service indicator (SI)

The service indicator is used to indicate the particular user part associated with the

transmitted message. In the message transfer part of the signaling network, the

message handling functions will base the service indicator to distribute the message

to the specified user part.

The code allocation for the service indicator is shown in Figure 3-2. The service

indicator capacity is enough to indicate 16 types of user part messages. Several

common types are listed in the figure.

2) Sub-service field (SSF)

It is composed of 4 bits. The higher two bits are the network indicator; the lower two

are currently spare bits, coded 00.

The network indicator is used to identify the nature of the network where the message

is transferred, that is,, it is an international or national signaling network message.

The code allocation of the sub-service field is shown in Figure 3-2.

According to the CCITT, the spare bits in the sub-service field may be used as per the

national signaling network. For example, the network indicator may be set to 10 or 11

to indicate the local signaling network or toll signaling network in case of 14-bit

8


signaling point encoding scheme. If the unified 24-bit encoding scheme is utilized, the

network indicator is set to 10 or 11 in order to identify the unified 24-bit encoding

scheme or temporary 24-bit encoding scheme (where ten “0” at the higher bit is

added/removed).

I. The Signaling Information Part Processed by a User Part

The signaling information part processed by the user parts is the signaling information

field (SIF) in the message signal unit format. The signaling information field only

exists in a message signal unit. It consists of three parts: the label for message

addressing, the heading code of the user signaling information, and the user signaling

information.

Label

The label contains the information necessary to deliver the message to its the

destination point. The standard routing label has a length of 32 bits and is placed at

the beginning of the signaling information field. The label includes the destination

point code (DPC), the originating point code (OPC) and the signaling link selection

(SLS) field.

A signaling point code is a numeric address, uniquely identifying one signaling point in

the SS7 network. When the destination point code contained in the message

indicates the receiving signaling point, the message is distributed to the

corresponding user part (such as ISUP or SCCP) identified by the service indicator in

the service information octet.

The signaling link selection is used in the following cases:

3) In ensuring message sequencing. Any two transmitted messages with the same

signaling link selection will normally arrive at the destination in the order in which

they were first transmitted.

4) In performing average load sharing of the stream between all available links. If a

certain user part periodically transmits messages and the signaling link selection

value is assigned in the cyclic manner, all the traffic to the destination has the

same traffic level.

The label structure determines four types of label as shown in Figure 3-1:

Type A MTP management messages

Type B TUP messages

Type C ISUP messages

Type D SCCP messages

As TCAP messages have to be transferred by the SCCP, the TCAP messages are

classified as SCCP messages, that is, type D.

9


F CK SIF FIBLI FSNSIO BIB BSN

Management message SLC OPC DPC Type A: MTP management messages

Signaling messageCIC

OPC DPC Type B: TUP messagesSLS

Signaling message OPC DPC Type C: ISUP messagesCIC SLC

F

SCCP user data SLS OPC DPC Type D: SCCP messages

F CK SIF FIBLI FSNSIO BIB BSN

Management message SLC OPC DPC Type A: MTP management messages

Signaling messageCIC

OPC DPC Type B: TUP messagesSLS

Signaling message OPC DPC Type C: ISUP messagesCIC SLC

F

SCCP user data SLS OPC DPC Type D: SCCP messages

Figure 3-1 Label structure of the four types

Heading code

The heading code is a field following the label It is composed of the 4-bit heading

code H0 and the 4-bit heading code H1, and identifies the message group and the

message type. For instance, in a TUP message, the heading code H0 coded 0001

and the heading code H1 coded 0001 indicate an Initial Address Message (IAM); the

heading code H0 coded 0001 and the heading code H1 coded 0100 indicate an

Address Complete Message (ACM). Another example is about a signaling network

management message. The H0 coded 0001 and the H1 coded 0001 indicate a

Changeover-order signal (COO); the H0 coded 0001 and the H1 coded 0100 indicate

a Transfer-prohibited signal. As both the H0 and the H1 occupy 4 bits, the maximum

capacity of a class of user messages is 256.

Signaling information

The signaling information part is also named service information part. This part is

further divided into several sub-fields. These sub-fields may be mandatory or optional

with fixed length or variable length in order to meet the requirements of various

functions and supplements, which makes it possible for message signal units to be

suitable for a variety of user messages and also makes it possible for the variety of

user message to be conveyed through common signaling channels.

For the format and encoding of the service information field, please reference the

user messages.

II. MTP Messages

In a signal unit, the flag, the backward sequence number, the backward indicator bit,

the forward sequence number, the forward indicator bit, the length indicator and the

check bits are mainly used for transmission, receiving sequence, error detection and

correction of the message signal unit. These fields are all analyzed and handled at

the second functional level of the signaling network, that is, the signaling link level.

10


Fill-in signal units are used for “feeding” purpose on a signaling link and composed of

several fields that mainly involve transmission control. Fill-in signal units are

generated and handled by the level 2 functions.

Link status signal units are used to carry the status indication information of a

signaling link. They are also generated and handled at the functional level 2. The

functional level 2 may base both the related indication from the level 3 and the

judgment of itself to generate a corresponding status signal unit and transmit it out;

the functional level 2 may also accept the status indication of the signaling link from

the peer and process it. If necessary, the information relating to congestion and

processor outage will be reported to the level 3.

Message signal units are divided into three classes according to their role in the

signaling network: the message signal units used for signaling network management

(MSU-SNM), the message signal units used for signaling network testing and

maintenance (MSU-SNT), and the message signal units generated by user parts

(MSU-UP). The first two classes utilize the type A label structure and are transmitted

between the MTPs. They are generated at the functional level 3 of the signaling

network and also processed at the level 3. The third class includes the messages of

type B, C and D label structure. Through the MTP, these messages are delivered to a

particular user part. The level 3 functions of the signaling network are responsible for

analyzing the label contained in the message to determine where the message will be

distributed. The generating and handling of the signaling information part (service

information part) is implemented by the functional level 4, that is, the user parts.

The signaling network management messages are critical to the MTP, and described

in details in the following section.

General format for the signaling network management messages

In the signaling network, the signaling network management messages are

distinguished by the configuration 0000 of the service indicator (SI) contained in the

service information octet in the signal unit.

As a type of message signal unit, the signaling information of a signaling network

management message is carried by the service information field. It structure is

illustrated in Figure 3-2.

Figure 3-2 General format for the signaling network management messages

Label

11


It comprises the destination point code (DPC), the originating point code (OPC) and

the signaling link code (SLC).

The destination point code and the originating point code are described the same as

the preceding section.

The signaling link code indicates the signaling link interconnecting the destination and

originating points. If the message is not related to a signaling link, or another

particular code is not specified, it is coded 0000. Currently 4 bits are used. The spare

4 bits are coded 0000.

Heading code

The heading codes include the 4-bit heading code H0 and the 4-bit heading code H1.

The heading code H0 identifies the management message group. The heading code

H1 determines the specific message from the message group. As both the H0 and the

H1 occupy 4 bits, the message capacity reaches 256 types. That is, there are 16

message groups and 16 message types in each group are available. Now not all of

them are used. See Table 3-1.

Table 3-1 Heading code allocation of signaling network management messages

Messa

ge

Group

H1

H0

000

0

000

10010

001

1

010

0

010

1

011

0

011

1

100

0

100

1

101

0

101

1

110

0

110

1

111

0

111

1

000

0

CHM000

1

CO

OCOA

CB

D

CB

A

ECM001

0

EC

OECA

FCM001

1RCT TFC

TFM010

0TFP * TFR TFA *

RSM010

1RST RSR

MIM011

0LIN LUN LIA LUA LID LFU LLT LRT

TRM011

1TRA

12


Messa

ge

Group

H1

H0

000

0

000

10010

001

1

010

0

010

1

011

0

011

1

100

0

100

1

101

0

101

1

110

0

110

1

111

0

111

1

DLM100

0DLC CSS

CN

S

CN

P

100

1

UFC101

0UPU

101

1

110

0

110

1

111

0

111

1

The meaning of the signaling network management messages is listed in Table 3-2.

Table 3-2 Signaling network management messages

Message Full name

CHM Changeover and changeback messages

COO Changeover-order signal

COA Changeover-acknowledgement signal

CBD Changeback-declaration signal

CBA Changeback-acknowledgement signal

ECM Emergency-changeover message

ECO Emergency-changeover-order signal

13


Message Full name

ECA Emergency-changeover-acknowledgement signal

FCM Signaling-traffic-flow-control messages

RCT Signaling-route-set-congestion-test signal

TFC Transfer-controlled signal

TFP Transfer-prohibited signal

TFR Transfer-restricted signal (national option)

TFA Transfer-allowed signal

RSM Signaling-route-set-test message

RST Signaling-route-set-test signal for prohibited destination

RSRSignaling-route-set-test signal for restricted destination

(national option)

MIM Management inhibit messages

LIN Link inhibit signal

LUN Link uninhibit signal

LIA Link inhibit acknowledgement signal

LUA Link uninhibit acknowledgement signal

LID Link inhibit denied signal

LFU Link forced uninhibit signal

LLT Link local inhibit test signal

LRT Link remote inhibit test signal

TRM Traffic-restart-allowed message

TRA Traffic-restart-allowed signal

DLM Signaling-data-link-connection-order message

DLC Signaling-data-link-connection-order signal

CSS Connection-successful signal

CNS Connection-not-successful signal

14


Message Full name

CNP Connection-not-possible signal

UFC User part flow control messages

UPU User part unavailable signal

III. Message Examples

Transfer-allowed message (TFA)

The format of the transfer-allowed message is shown as follows:

Destination HeadingCode H1

HeadingCode H0 Label

DCBA 0100


24 4 4 56

Destination HeadingCode H1

HeadingCode H0 Label

DCBA 0100


24 4 4 56

The heading code H1 contains one signal code as follows:

D C B A

0 1 0 1 Transfer-allowed signal

3.1.4 Signaling Procedures

I. Message Routing

The message routing function is based on the information contained in the routing

label, namely on the destination point code and on the signaling link selection field.

Each signaling point has the routing information that enables it to determine the

signaling link over which a message is sent on the basis of the destination point code

and the signaling link selection field.

Typically the destination point code is associated with more than one signaling link

that may be used to carry the message; the selection of the particular signaling link is

made by means of the signaling link selection field, thus effecting load sharing.

There are two basic cases of load sharing, namely:

load sharing between the links belonging to the same link set;

load sharing between the links not belonging to the same link set.

Messages not related to a signaling link may be assigned any signaling link code

(SLC) to allow load sharing of the messages, or may be assigned a default SLC such

15


as 0000. They are routed in accordance with the normal routing function, where the

(SLC) is used as SLS for load sharing.

II. Changeover

The purpose of the changeover procedure is to ensure the signaling traffic carried by

the unavailable signaling link is diverted to the alternative signaling link(s) as quickly

as possible while avoiding message loss, duplication or mis-sequencing.

To implement this purpose, in the normal case the changeover procedure includes

buffer updating and retrieval, which are performed before reopening the alternative

signaling link(s) to the diverted traffic. Buffer updating consists of identifying all the

messages in the retransmission buffer of the unavailable signaling link which have not

been received by the far end. Retrieval consists of transferring the concerned

messages to the transmission buffer(s) of the alternative link(s).

In the case of unavailability of a signaling link, changeover is initiated at a signaling

point. The following actions are then made:

transmission and acceptance of message signal units on the concerned

signaling link is terminated;

transmission of link status signal units or fill-in signal units takes place;

the alternative signaling link(s) are determined;

a procedure to update the content of the retransmission buffer of the unavailable

signaling link is performed;

signaling traffic is diverted to the alternative signaling link(s).

III. Changeback

The objective of the changeback procedure is to ensure that signaling traffic is

diverted from the alternative signaling link(s) to the signaling link made available as

quickly as possible, while avoiding message loss, duplication or mis-sequencing.

Changeback includes the basic procedures to be used to perform the opposite action

to changeover.

Changeback is initiated at a signaling point when a signaling link is reconnected,

restored, or unblocked, and therefore it becomes once again available. The following

actions are then made:

the alternative signaling link(s) to which traffic normally carried by the signaling

link made available was previously diverted are determined;

transmission of the concerned traffic on the alternative signaling link(s) is

stopped, and such traffic is stored in a changeback buffer;

a changeback declaration is sent to the remote signaling point of the signaling

link made available through the concerned alternative signaling link; this

message indicates that message traffic on the alternative signaling link will be

sent by the signaling link made available;

16


the concerned signaling point will restart diverted traffic over the signaling link

made available when it receives a changeback acknowledgement from the far

signaling point of the link made available.

IV. Signaling Link Activation

When a decision is taken to activate an inactive signaling link, initial alignment starts:

if the initial alignment procedure is successful, the signaling link is active and a

signaling link test is started;

if the signaling link test is successful, the link becomes ready to convey signaling

traffic;

in the case when initial alignment is not possible, new initial alignment

procedures are started on the same signaling link after the timer expires;

if the signaling link test fails, link restoration starts until the signaling link is

activated or a manual intervention is made.

V. Signaling Link Restoration

After a signaling link failure is detected, signaling link initial alignment will take place.

if the initial alignment procedure is successful, a signaling link test is started;

if the signaling link test is successful, the link becomes restored and thus

available for signaling;

if the initial alignment is not possible, new initial alignment procedures may be

started on the same signaling link;

if the signaling link test fails, the restoration procedure is repeated until the link is

restored or a manual intervention made.

VI. Signaling Link Deactivation

An active signaling link may be made inactive by means of a deactivation procedure,

provided that no signaling traffic is carried on that signaling link. When a decision has

been taken to deactivate a signaling link, the signaling terminal of the signaling link is

taken out of service.

VII. Signaling Route Management Procedures

The purpose of the signaling route management function is to ensure a reliable

exchange of information between the signaling points (to ensure the availability of the

signaling routes).

The unavailability, restriction and availability of a signaling route is communicated by

means of the transfer-prohibited, transfer-restricted and transfer-allowed procedures.

17


VIII. Transfer Prohibited

For the purpose of being described conveniently, it is assumed that Y is the

originating signaling point, X is the destination signaling point, and Z is a signaling

transfer point.

when the signaling point Y starts to route signaling destined to the signaling point

X through the signaling transfer point Z which is currently unavailable for the

signaling point Y, the transfer-prohibited message is sent to the signaling transfer

point Z;

when the signaling transfer point Y recognizes the inaccessibility of the signaling

point X, the transfer-prohibited message is sent to all accessible adjacent

signaling points (broadcast method);

when a message destined to the signaling point X is received at the signaling

transfer point Y and Y is unable to transfer the message, the transfer-prohibited

message is sent to the adjacent signaling point from which the concerned

message was received.

3.2 MTP3B

3.2.1 Overview

Broadband MTP provides the transfer capability of broadband signaling cross the

ATM network and consists of Message Transfer Part (broadband) (MTP3B) and

Signaling ATM Adaptation Layer (SAAL).

The major differences between the broadband SS7 and narrowband SS7 are the

relevant modifications of the MTP layer. To widen the signaling bandwidth, the MTP-1

and the MTP-2 are changed to SAAL (Service Specific Connection Oriented Protocol,

Service Specific Coordination Function) and the MTP-3 is changed to MTP3B. In the

aspect of physical connection, E1 trunk connections are changed to ATM (Permanent

Virtual Channel) connections.

In MSOFTX3000, the broadband MTP provides signaling transfer services for the

SCCP, BICC and H.248 protocols, as shown in Figure 3-3.

18


ATM

AAL5

SSCOP

SSCF AT NNI

MTP3b

LM

SAAL

SCCP/BICC/H.248User Part

Broadband MTP

ATM

AAL5

SSCOP

SSCF AT NNI

MTP3b

LM

SAAL

SCCP/BICC/H.248User Part

Broadband MTP

Figure 3-3 Structure of the broadband MTP

Currently in UMTS, the broadband MTP is mainly applicable to the Iu-CS interface

and provides signaling transfer services for the RANAP/SCCP. If necessary, the

broadband MTP is also used on the Nc interface and provides services for the BICC

protocol.

3.2.2 Introduction of MTP3B

MTP3B is a protocol specification designed for ATM features on the basis of the

MTP3. The MTP3B is not only responsible for carrying signaling messages, but also

responsible for managing the signaling network and signaling links. The MTP3B uses

the services provided by the SAAL for message exchange.

I. MTP3B Structure

Similar to the MTP3, the functional structure of the MTP3B protocol is composed of

signaling message handling and signaling network management.

5) Signaling message handling

The purpose of the signaling message handling functions is to ensure that the

signaling messages originated by a particular User Part at a signaling point are

delivered to the same User Part at the destination point indicated by the related field

in the message signal unit (there are only SCCP and STC user parts at the Iu

interface). To achieve these functions, signaling message handling is further divided

into message routing, discrimination and distribution functions.

6) Signaling network management

The purpose of the signaling network management functions is to provide

reconfiguration of the signaling network in the case of failures. Activation and

alignment of a new signaling link is also included. With the enlargement of a signaling

network and increasing of the load over signaling links, congestion may appear in the

signaling network. Thus controlling congestion is one of the signaling network

19


management functions. The signaling network management functions comprise

signaling traffic management, signaling link management and signaling route

management.

II. MTP3B Functions

The major functions provided by the components in the MTP3B protocol structure are

described as follows:

7) Message discrimination

The purpose of the message discrimination function is to examine the standard field

in the message header to judge whether or not a received message from the lower

layer (SAAL) is valid and, if valid, to determine where the message will be delivered.

If the message is not valid, the message will be discarded.

If the message is valid, there are the following possibilities:

a) When the received message is destined to the signaling point itself, the message

will be delivered to the message distribution module;

b) When the received message is not destined to the point itself and the signaling

point has no the transfer capability, the message will be discarded; otherwise, the

message will be delivered to the message routing module for further handling.

8) Message distribution

The purpose of the message distribution function is to direct a received message to

the appropriate upper-layer module which is the destination for processing the

message. If the message does not exist in the particular level 4 module indicating to

process it or the field is not valid, the message will be discarded.

9) Message routing

The purpose of the message routing function is to base the header information of a

received message to select an appropriate route for it, base the route to select a link

set, base the link set to select a link, and use the selected link to finally transmit the

message out. The handled message has the following possibilities:

The message is delivered from the upper-layer. The message routing module

has to determine an available route to transmit it. An exception is there is not

such a satisfactory route.

When the message is not destined to the point itself and the signaling point has

the signaling transfer function, its destination signaling point can be found from

the destination signaling point table at this signaling point, so as to direct the

message out.

When the message is not destined to the point itself and the signaling point has

the signaling transfer function but the destination signaling point of the message

cannot be found from the destination signaling point table at this signaling point,

the message will be discarded.

20


10) Signaling traffic management

The purpose of the signaling traffic management function is to ensure a reliable and

in-sequence transfer of signaling messages. In the case of unreliability or

unavailability of a link, the function is used to divert the messages to one or more

alternative links with the objective of avoiding message loss or mis-sequencing.

11) Signaling route management

The purpose of the signaling route management function is to provide the basis for

message routing and, in the case of unavailability or unreliability of the currently

applied route, provides rerouting function and re-configures the network in order to

provision a reliable route to achieve signaling transfer.

12) Signaling link management

The purpose of the signaling link management function is to perform a proper

handling procedure on a signaling link in the case of unavailability or unreliability, in

order to stop using the unreliable link and repeatedly restart the link with the objective

of making it available again. The link management function also provides the link

testing function which periodically performs testing on a link so as to confirm the

availability of the link.

3.2.3 MTP3B Message Structure

The message structure of the MTP3B is basically same as that of the MTP3. Please

reference “Narrowband MTP” for more information. Here in this chapter only their

differences are covered.

I. Length of User Data

The MTP3B extends the length of the user data contained in a signal unit. The

maximum amount of the user data supported by MTP3B signaling links is 4091 octets

(that supported by narrowband MTP is 272 octets).

II. Service Indicator (SI)

The following codes of the service indicator are additionally used in the MTP3B:

SI code Meaning

1 0 0 1 Broadband ISDN User Part

1 0 1 0 Satellite ISDN User Part

In MSOFTX3000 product, the MTP3B has three users, namely SCCP, BICC and

H.248. The service indicator codes respectively corresponding to them are as follows:

21


SI code Indicating user

0 0 1 1 SCCP

1 1 0 1 BICC

1 1 1 0 H.248

III. Changeover Procedure

By contrast with the narrowband MTP, the MTP3B changeover procedure applies with

the following exceptions and clarifications:

The signaling link failure indication causes by MTP2 link do not apply, here is In

Service to Out Of Service state causes by SAAL or when a request (automatic or

manual) is obtained from a management or maintenance system.

Moreover a signaling link that is available is recognized by level 3 as failed when

an extended changeover order or an emergency changeover order is received.

The changeover message of the signaling network management messages is

modified by using XCO/XCA to replace COO/COA. Heading code allocation of

MTP3B signaling network management messages is shown in the following

table:

Message

GroupH1

H000

00

00

01

00

10

00

11

01

00

01

01

01

10

01

11

10

00

10

01

10

10

10

11

11

00

11

01

11

10

1

1

1

1

0000

CH

M0001

C

O

O

C

O

A

X

C

O

X

C

A

C

B

D

C

B

A

EC

M0010

E

C

O

E

C

A

FC

M0011

R

C

T

T

F

C

22


Message

GroupH1

TFM 0100

T

F

P

*

T

F

R

T

F

A

*

RS

M0101

R

S

T

R

S

R

MIM 0110LI

N

L

U

N

LI

A

L

U

A

LI

D

LF

U

LL

T

L

R

T

TR

M0111

T

R

A

DLM 1000

D

L

C

C

S

S

C

N

S

C

N

P

1001

UFC 1010

U

P

U

1011

1100

1101

1110

1111

3.3 SAAL

3.3.1 SAAL Function Structure

In the broadband network, signaling adaptation is required in the transmission of

signaling information across ATM network. That is to say, signaling information in a

23


variety of message formats has to be converted to a format suitable for transportation

over ATM network and ATM Adaptation Layer (AAL) connections have to be set up for

signaling. What implements this function is the Signaling ATM Adaptation Layer

(SAAL).

The SAAL protocol used in MSOFTX3000 product is in full compliance with the ITU-T

Recommendations Q.2110, Q.2140 and Q.2144.

The SAAL makes use of the specification of AAL type 5 (AAL5). As shown in

Figure 3-1, The SAAL comprises the Convergence Sublayer (CS) and the

Segmentation And Reassembly (SAR). The CS is divided into the Service Specific

Convergence Sublayer (SSCS) and the Common Part Convergence Sublayer

(CPCS). Further, the SSCS includes three parts: the Service Specific Coordination

Function (SSCF) sublayer (ITU-T Q.2140), the Service Specific Connection Oriented

Protocol (SSCOP) sublayer (ITU-T Q.2110), and the Layer Management (LM) (ITU-T

Q.2144).

Figure 3-1 Structure of the SAAL protocol in MSOFTX3000

In MSOFTX3000, the CPCS and the SAR are implemented by the BSG hardware,

thus the SSCOP, the SSCF and the LM constitute the core of the SAAL protocol.

3.3.2 SSCOP

I. SSCOP Functions

The SSCOP performs the following functions:

Sequence integrity: This function preserves the order of SSCOP SD PDUs that

were submitted for transfer by SSCOP.

Error correction by selective retransmission: Through retransmission, sequence

errors are corrected when the receiving SSCOP entity detects missing SSCOP

Service Data Units (SDUs).

24


Flow control: By sending the movement of the sliding window, this function

allows to adjust the information transmission rate to perform flow control.

Error reporting to Layer Management: This function indicates to layer

management errors which have occurred.

Keep alive: This function verifies that the two peer SSCOP entities participating

in a connection are remaining in a link connection established state even in the

case of a prolonged absence of data transfer.

Local data retrieval: This function allows the local SSCOP user to retrieve in-

sequence SDUs which have not yet been released by the SSCOP entity when a

link changeover procedure takes place at the higher layer.

Connection control: This function performs the establishment, release, and

resynchronization of an SSCOP connection. It also allows the transmission of

variable length user-to-user information without a guarantee of delivery.

Transfer of user data: This function is used for the conveyance of user data

between users of the SSCOP. SSCOP supports both assured and unassured

data transfer.

Protocol error detection and recovery: This function detects and recovers from

errors in the operation of the protocol.

Status reporting: This function allows the transmitter and receiver peer entities to

exchange status information.

II. SSCOP Protocol Data Units

What are conveyed between two SSCOP peer layers for the establishment or release

of a connection and for the guarantee of a reliable message transmission are protocol

data units (PDUs) of the SSCOP. Basic PDUs are listed and described as follows:

BGN PDU (Begin): The BGN PDU is used to establish an SSCOP connection

between two peer entities. The BGN PDU requests the clearing of the peer’s

transmitter and receiver buffers, and the initialization of the peer’s transmitter

and receiver state variables and counters.

BGAK PDU (Begin Acknowledge): The BGAK PDU is used to acknowledge the

acceptance of a connection request from the peer.

BGREJ PDU (Begin Reject): The BGREJ PDU is used to reject the connection

request of the peer SSCOP entity.

END PDU (End): The END PDU is used to release an SSCOP connection

between two peer entities.

ENDAK PDU (End Acknowledge): The ENDAK PDU is used to confirm the

release of an SSCOP connection.

RS PDU (Resynchronization): The RS PDU is used for the routine connection-

oriented reset in other connection-oriented protocols. The RS PDU is used to

resynchronize the buffers and the transmitter and receiver state variables

(counters).

25


RSAK PDU (Resynchronization Acknowledge): The RSAK PDU is used to

acknowledge the acceptance of a resynchronization requested by the peer

SSCOP entity.

ER PDU (Error Recovery): The ER PDU is used to recover from protocol errors

in the operation of a connection.

ERAK PDU (Error Recovery Acknowledge): The ERAK PDU is used to

acknowledge the recovery from protocol error.

SD PDU (Sequenced Data): The SD PDU is used to transfer user service data to

the peer entity after an SSCOP connection is set up.

POLL PDU (Status Request): The POLL PDU is used to request, across an

SSCOP connection, status information about the peer SSCOP entity.

STAT PDU (Solicited Status Response): The STAT PDU is used to respond to a

status request (POLL PDU) received from a peer SSCOP entity. It is used to

notify the peer SSCOP entity of correct receipt of concerned SD PDUs and also

used to acknowledge which SD PDUs are successfully accepted and which fail

to be received. It is also used to update the position of the transmitting window.

In this way, the maximum transmitting sequence number of SD PDUs that can

be sent currently is controlled. The STAT PDU also contains the sequence

number [N(PS)] of the POLL PDU to which it is in response.

USTAT PDU (Unsolicited Status Response): The USTAT PDU is used to

respond to a detection of one or more new missing SD PDUs, based on the

examination of the sequence number of the SD PDU. It contains the data for

updating the transmitting window of the peer, but there is not the N(PS) field.

UD PDU (Unnumbered Data): The UD PDU is used for unassured data transfer

between two SSCOP users, without affecting connection-oriented sequencing in

progress, without changing the entities’ counters or variables, without re-

transmitting lost data.

MD PDU (Management Data): The MD PDU is used for unassured management

data transfer between two SSCOP management entities. Similar to the UD PDU,

the MD PDU does not ensure a reliable receipt by the peer.

III. SSCOP States

The states of an SSCOP protocol entity reflect general conditions of the SSCOP

entity in the sequences of signals and PDU exchanges with its user and peer,

respectively. The basic states are:

State 1 - Idle: Each SSCOP entity is conceptually initiated in the Idle state (State

1) and returns to this state upon the release of a connection.

State 2 - Outgoing Connection Pending: An SSCOP entity requesting a

connection with its peer is in the Outgoing Connection Pending state (State 2)

until it receives acknowledgement from its peer

26


State 3 - Incoming Connection Pending: An SSCOP entity that has received a

connection request from its peer and is waiting for its user’s response is in the

Incoming Connection Pending state (State 3).

State 4 - Outgoing Disconnection Pending: An SSCOP entity requesting release

of the peer-to-peer connection goes to the Outgoing Disconnection Pending

state (State 4) until it receives confirmation that the peer entity has released and

transitioned to the Idle state (State 1), after which it does the same.

State 5 - Outgoing Resynchronization Pending: An SSCOP entity requesting

resynchronization of the connection with its peer is in the Outgoing

Resynchronization Pending state (State 5).

State 6 - Incoming Resynchronization Pending: An SSCOP entity that has

received a resynchronization request from its peer and is waiting for its user’s

response is in the Incoming Resynchronization Pending state (State 6).

State 7 - Outgoing Recovery Pending: An SSCOP entity requesting recovery

with its peer of an existing connection is in the Outgoing Recovery Pending state

(State 7).

State 8 - Recovery Response Pending: An SSCOP entity which has completed

recovery, notified its user, and is awaiting response is in the Recovery Response

Pending state (State 8).

State 9 - Incoming Recovery Pending: An SSCOP entity that has received a

recovery request from its peer and is waiting for its user’s response is in the

Incoming Recovery Pending state (State 9).

State 10 - Data Transfer Ready: Upon successful completion of the connection

establishment, resynchronization, or error recovery procedures, both peer

SSCOP entities will be in Data Transfer Ready state (State 10) and assured data

transfer can take place.

IV. SSCOP Operating Mechanism

Connection establishment of SSCOP

In order to establish a connection between two peer SSCOP entities, the SSCF sends

an AA-ESTABLISH.req primitive to the SSCOP. This primitive contains SSCOP-UU

and BR parameters used by SSCOP to generate a BGN message. The BGN

message is sent to the receiving SSCOP where it is decoded, processed and mapped

to an AA-ESTABLISH.ind signal which will be sent to the receiving SSCF. The SSCF

responds to the SSCOP with an AA-ESTABLISH.res primitive containing also

SSCOP-UU and BR primitives. Whereas, the SSCOP sends a BGAK message back

to the originating SSCOP and the originating SSCOP decodes and processes it and

sends it to the SSCF. These actions establish a connection between two SAAL

entities in two broadband signaling exchanges. See Figure 3-2.

27


Figure 3-2 Connection establishment of SSCOP

Data transfer and error recovery of SSCOP

As shown in Figure 3-3, SSCOP A sends to SSCOP B four SD PDUs in the N(S)

sequence numbered from 1 to 4. Only the PDU1 and PDU2 succeed in arriving at

SSCOP B without error. The SSCOP delivers the PDU1 and PDU2 to the proper user.

The SSCOP A sends a POLL PDU. Contained in the message is N(S)=5 indicating

the N(S) value of the next new SD PDU (that is, the next SD PDU to be transmitted).

The POLL also contains N(PS)=1 which is the sequence number of the POLL PDU.

The SSCOP B responds to the POLL PDU with a STAT PDU, and the STAT PDU is

coded N(R)=3 to acknowledge the acceptance of the PDU1 and PDU2. In addition, it

is also indicated that it is expecting the next PDU, that is, PDU3. The N(PS) field

contained in the STAT must be the same as the value of the N(PS) field contained in

the concerned POLL PDU. The list element is set to 3 and 5. The information

indicated by it is described as follows. The odd element (valued 3) indicates the PDU

of a certain loss interval; the even element (valued 5) indicates the first PDU in the

next correctly accepted sequence. This message notifies the SSCOP A that 1) it must

re-transmit PDU3 and PDU4; 2) it can release PDU1 and PDU2 from the buffer; and

3) it must preserve PDU3 and PDU4 as there is not enough information about the

final result of PDU3 and PDU4. The SSCOP A then sends 3 SD PDUs to the SSCOP

B, and only the PDU7 is received. As the SSCOP is not allowed to exchange out-of-

sequence service with the user, the SSCOP B keeps PDU7 in the buffer. It sends to

the SSCOP A a USTAT PDU (where N(R)=3).

28


Figure 3-3 Data transfer of SSCOP

Connection release of SSCOP

After an SSCOP receives a release request message AA-RELEASE.request, it sends

an END PDU to the peer SSCOP. On receipt of the END PDU, the peer sends an AA-

RELEASE.indication. After the connection is released, the peer sends an ENDAK

PDU. After receiving it, the receiving end sends an AA-RELEASE.confirm message to

the concerned SSCF, and releases the connection. See Figure 3-4.

Figure 3-4 Connection release of SSCOP

3.3.3 SSCF

The SSCF is used to coordinate the interface between the SSCOP and the upper-

layer MTP3B. It maps primitives from the MTP3B to required SSCOP signals, and

vice versa. In nature, the SSCF only transfers the signals between the SSCOP and

the MTP3B to and fro, playing an intermediate role. The SSCF does not transmit any

29


PDUs to the peer entity in the receiver; instead, by relying on the SSCOP, its

information is carried in SSCOP PDUs.

I. SSCF Functions

Primitive mapping: The SSCF maps primitives received from SAAL user to

signals defined at the SSCOP upper layer boundary and maps signals received

from the SSCOP to primitives implicitly defined at the MTP-3 lower layer

boundary.

Local retrieve: In the case of a changeover procedure performed on a faulty link,

this function makes it possible to obtain back the data not yet transmitted and

divert the data to alternative link(s).

Flow control: The SSCF reports to the user the congestion level (or no

congestion) to avoid unnecessary cell loss. It also diverts its own PDU flow to the

lower layer in order to prevent from congestion happening at the other end.

Link status maintenance: This SSCF function receives primitives from the MTP-3

or signals from the SSCOP and maintains information pertaining to the status of

the link, such as In Service and Out Of Service. Based on the information, it can

provide primitives/signals to the MTP3 and the SSCOP as an aid to maintaining

the link.

Reporting to layer management: This SSCF function transmits MAAL primitives

to the layer management so that the layer management can perform statistics

and measurements. For instance, upon release of a link, the SSCF reports the

release to the layer management, and then the layer management can measure

the In-service duration. With the help of the layer management, the error

monitoring function can be implemented.

Performing link alignment.

II. SSCF Link Alignment

Alignment procedure: The procedure initiated according to user's request to detect

the status of a link before it is put into service in the case of successful establishment.

On receipt of the user’s (MTP3B) request (by sending a STAR_req primitive), the

SSCF transmits a BGN PDU to the peer entity in the receiving exchange to start the

alignment procedure, and moves a link from the Out Of Service status to the

Alignment status.

These operations require the SSCOP to establish a link between the two exchanges.

After the link is successfully established, the SSCF indicates the layer management

to start the monitoring action. Then the SSCF enters the Proving status for the link.

At this moment, proving PDUs are transported between the exchanges. A links proves

to be good by the means that n (1000 by default) proving PDUs can be successfully

transmitted. In the end, if 1000 proving PDUs are really transmitted successfully and

30


errors are not found then the link is recognized as passing the alignment and can be

put into service.

The SSCF alignment procedure provides a normal or emergency proving. Whether to

begin proving can be initiated by the layer management and the MTP3B. In the

normal proving,

The proving algorithm on SAAL link is based on the alignment error rate monitoring

process used for proving a link. Transmission of testing PDUs of N1 amount (1000 by

default) at a specified rate (one PDU per millisecond by default) must be completed

within 30 seconds from the start to the proving success. If one or two (one by default)

of the transmitted N1 PDUs are re-transmitted, the proving fails. If no error occurs, the

link succeeds in being proved and moves to In Service.

3.3.4 LM

The position of the Layer Management (LM) in the SAAL is shown in Figure 3-1. The

SSCS LM is the layer management entity of the Service Specific Convergence

Sublayer. It makes a direct interaction with the sublayers to implement a number of

Operation Administration and Maintenance (OAM) functions. Therefore, the SSCS LM

is described as an entity having interactions with all SAAL layers since CPCS and

SAR (AAL Type 5) are implemented by the hardware and there are no interactions

defined at these two layers. The SSCS LM is responsible for conducting the following

tasks:

Determining whether a link should be out of service or in service. As a

component of these operations, a link has to be monitored against excessive

delays during service transmission. In order to avoid unnecessary alteration, the

layer management allows a certain number of errors occurring at the link.

Periodically conducting a number of measurements. For instance, the layer

management uses counters to count how long each link is in service, how

frequent faults take place, how frequent congestions happen, as well as other

information.

Performing alarm handling.

The layer management has the following states:

Out Of Service

Alignment

Proving

Aligned Ready

In Service

I. LM Error Monitoring Algorithms

The layer management provides three algorithms for error monitoring. These

algorithms ensure to detect an error burst keeping for more than 400ms.

31


Algorithm 1 is mainly used for heavy load. If the volume of the transmitted data is

too large, the receiver has not enough time to handle the data. This causes the

fact that the data in the sending buffer cannot be released so long that the sum

of the transmission queue continues to increase to a particular value. At this

moment, the link will be released.

Algorithm 2 is mainly used for intermediate load. This algorithm monitors data

retransmissions. When data retransmissions occur so frequently within a

particular interval that the occurrence sum exceeds a threshold, it indicates a

bad quality on the link. Once the delay is beyond tolerance, the link will be

released.

Algorithm 3 is mainly used for light load. If within a particular interval the

difference between the number of transmitted POLL PDUs and the number of

accepted STAT PDUs (the difference is actually the number of lost STAT PDUs)

exceeds a threshold, it also indicates a bad quality on the link. In this case, the

link will be released.

II. SAAL Compound States

The states for coordinative operation among the three sub-layers are defined as

follows: (“m” indicates the state number of SSCF; “n” indicates the state number of

SSCOP; “r” indicates the state number of LM; and “m/n/r” indicates the compound

state of the three sub-layers.)

1/1/1 Out Of Service/Idle: In this state, the connection is idle.

1/4/1 Out Of Service/ Outgoing Disconnection Pending: In this state the MTP3B,

or alternatively the Layer Management, has issued an AAL-STOP-request, or an

AA-RELEASE-request or an MAAL_RELEASE-Request, respectively, which

caused the SSCF to issue an AA-RELEASE-request, and the SSCF is waiting for

a confirmation of the SSCOP connection release, AA-RELEASE-confirm.

2/1/2 Alignment/Idle: In this state, the SAAL user requested the SSCF to provide

an AAL connection. This request was passed to SSCOP by means of an AA-

ESTABLISH-request, but the connection establishment or proving was

unsuccessful. SSCF is waiting to reattempt this process. This process will be

repeated until a supervisory function indicates that the establishment of an AAL

connection is to be abandoned.

2/2/2 Alignment/Outgoing Connection Pending: In this state, the user has issued

an AAL-START-request, and the SSCF is waiting for a confirmation of SSCOP

connection.

2/4/2 Alignment/Outgoing Disconnection Pending: In this state the SSCF, or in

the case of unsuccessful proving, the Layer Management, requested the release

of the SSCOP connection. This request was passed to SSCOP by means of an

AA-RELEASE-request, and the SSCF is waiting for a confirmation of the SSCOP

32


connection release, AA-RELEASE-confirm. This state transition within SSCF is

not indicated to the SAAL user.

3/10/5 In Service/Data Transfer Ready: In this state, the signaling

connection is in service and may be used by the user to transfer signaling

messages.

2/10/3 Proving/Data Transfer Ready: In this state, an SSCOP connection

has been established, and SSCS layer management is conducting alignment

error rate monitoring to verify the quality of the link.

2/10/4 Aligned Ready/Data Transfer Ready: In this state, the SSCF has

completed proving and is awaiting an indication from its peer that the signaling

link can be put into service.

Figure 3-5 is the normal start flow diagram of the SAAL protocol. The transition of the

eight states above mentioned is shown in the figure.

T1167200-94/d06

. . . . . . . . . . . .. . . . . . . . . . . .

AAL-START-req.

MAL-REPORT-ind.

(-,ALN,-)

1 1

2

2

2 2

1 1 1

2

2

3

4

5

3

1/1/1

2/2/2

2/10/3

3/10/5

2/10/4

10 10

1/1/1

2/2/2

2/10/3

2/10/4

3/10/5

5

3

4

3MAAL-PROVING-ind.

T3 expiresC1 > 0

T3 expiresC1 > 0

T3 expiresC1 = 0

MAAL-STOP_PROVING-ind.

AAL-IN_SERVICE-ind.

MAAL-REPORT-ind.

(-,INS,-)

AA-ESTABLISH-req.

AA-ESTABLISH-conf.

AA-DATA-req.(NM)

AA-DATA-ind.(NM)

AA-DATA-req.(IS)

AA-DATA-ind.(IS)

BGN BGN

BGAK BGAK

SD SD

POLL POLL

STAT STAT

POLL

AA-ESTABLISH-req.

AA-ESTABLISH-conf.

AA-DATA-req.(NM)

AA-DATA-ind.(NM)

AA-DATA-req.(IS)

AA-DATA-ind.(IS)

AAL-START-req.

MAL-REPORT-ind.(-,ALN,-)MAAL-PROVING-ind.

T3 expiresC1 > 0

T3 expiresC1 > 0

T3 expiresC1 = 0

MAAL-STOP_PROVING-ind.

AAL-IN_SERVICE-ind.

MAAL-REPORT-ind.(-,INS,-)

LM MTP3 SSCF-NNI SSCOP SSCOP SSCF-NNI MTP3 LM

FIGURE II.1/Q.2140Time flow diagram for connection estabishment Both UPS=Normal, Case 1

AA-DATA-req.(NM)

AA-DATA-ind.(NM)

SD SDAA-DATA-req.(NM)

AA-DATA-ind.(NM)

STAT STAT

SD SD

POLL

1

Figure 3-5 Normal start flow diagram of SAAL

33


34

03-Chapter 3 MTP and MTP3B

Documents

Transcript of 03-Chapter 3 MTP and MTP3B