Signal Mtp3b

Technical Manual Signaling & Protocols Table of Contents

Table of Contents

Chapter 3 MTP and MTP3B........................................................................................... ...............13.1 MTP........................................................................................................ ..........................1

3.1.1 Overview............................................................................................................. ....13.1.2 MTP3 Functions...................................................................................................... 23.1.3 Message Format............................................................................................... ......43.1.4 Signaling Procedures.......................................................................................... ..16

3.2 MTP3B............................................................................................................ ................193.2.1 Overview........................................................................................................... ....193.2.2 Introduction of MTP3B............................................................................ ..............203.2.3 MTP3B Message Structure.............................................................................. .....23

3.3 SAAL..................................................................................................................... ..........253.3.1 SAAL Function Structure.............................................................. ........................253.3.2 SSCOP.................................................................................................. ...............263.3.3 SSCF ..................................................................................................... ..............323.3.4 LM....................................................................................................................... ..33

i

Technical Manual Signaling & Protocols 3MTP 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 3.1.1.

SCCP

ISUP

MTP3

MTP2

MTP1

MTP User

MTP

Figure 1.1Structure 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.

1


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.

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 3.1.2.

2


Message distribution

Signaling message processing

Message discrimination

Message routing

Outgoing

Incoming

Signaling traffic management

Signaling network management

Signaling route management

Signaling link management

Signaling network function

Level 4 Level 3 message transfer part Level 2

Test and maintenance

Signaling message stream

---- Indication and control

Incoming

Test and maintenance

Figure 1.2Signaling 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.

3


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 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:

1) 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.

2) 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.

3) 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.

4


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 3.1.3.

MSU F CK SIF SIO LI FIB FSN BIB BSN F

8 16 8N(N2) 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 8Format of a link status signal unit (LSSU)


FISU F CK LI FIB FSN BIB BSN F

8 16 2 6 1 7 1 7 8Format of a fill-in signal unit (FISU)



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




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















Figure 1.3Format 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

5


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 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

6


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

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)

7


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 I:

Table 3.1Meanings 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)

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 I.

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

8


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 1.4Format 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 I. 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 I.

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

9


to indicate the local signaling network or toll signaling network in case of 14-bit 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).

II. 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:

1) 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.

2) 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 2:

Type A MTP management messages

10


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.

F CK SIF FIBLI FSNSIO BIB BSN

Management message SLC OPC DPC Type A: MTP management messages

Signaling messageCIC OPC DPC Type B: TUP messages

SLS

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 messages

SLS

Signaling message OPC DPC Type C: ISUP messagesCIC SLC

F

SCCP user data SLS OPC DPC Type D: SCCP messages

Figure 1.5Label 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

11


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.

III. 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.

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.

12


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 III.

Managementinformation

H1 OPCSLCH0 DPC

8n(n 0)

4 24/1424/144 4 4


Figure 1.6General format for the signaling network management messages

Label

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 III.

13


Table 6.1Heading code allocation of signaling network management messages

Message Group

H1

H0

0000

0001

0010 0011

0100

0101

0110

0111

1000

1001

1010

1011

1100 1101

1110 1111

0000

CHM 0001

COO

COA CBD

CBA

ECM 0010

ECO

ECA

FCM 0011 RCT TFC

TFM 0100

TFP * TFR TFA *

RSM 0101

RST RSR

MIM 0110 LIN LUN LIA LUA LID LFU LLT LRT

TRM 0111 TRA

DLM 1000

DLC CSS CNS

CNP

1001

UFC 1010

UPU

1011

1100

1101

1110

1111

The meaning of the signaling network management messages is listed in III.

Table 6.2Signaling network management messages

Message Full name

CHM Changeover and changeback messages

14


Message Full name

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

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

RSR Signaling-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

15


Message Full name

CNP Connection-not-possible signal

UFC User part flow control messages

UPU User part unavailable signal

IV. Message Examples

Transfer-allowed message (TFA)

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

Destination HeadingCode H1HeadingCode H0 Label

DCBA 0100


24 4 4 56

Destination HeadingCode H1HeadingCode 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.

16


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 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.

17


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;

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.

18


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.

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).

19


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 3.2.1.

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 1.7Structure 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.

20


1) 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.

2) 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 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:

1) 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.

2) Message distribution

21


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.

3) 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.

4) 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.

5) 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.

6) 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

22


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:

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:

23


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

Group

H1

H0 0000

0001

0010

0011

0100

0101

0110

0111

1000

1001

1010

1011

1100

1101

1110

1111

0000

CHM

0001 COO

COA

XCO

XCA

CBD

CBA

ECM

0010 ECO

ECA

FCM

0011 RCT

TFC

TFM 0100 TFP

* TFR

TFA

*

RSM

0101 RST

RSR

MIM 0110 LIN

LUN

LIA

LUA

LID

LFU

LLT

LRT

TRM

0111 TRA

DLM 1000 DLC

CSS

CNS

CNP

1001

24


Message

Group

H1

UFC 1010 UPU

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 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 3.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).

25


SSCF-NNI

SSCOP

L

M

CPCS -SAR

MTP3B

O

M

SAAL

Figure 1.8Structure 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).

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

26


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 peers transmitter and receiver buffers, and the initialization of the peers 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).

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.

27


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

State 3 - Incoming Connection Pending: An SSCOP entity that has received a connection request from its peer and is waiting for its users 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

28


received a resynchronization request from its peer and is waiting for its users 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 users 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 IV.

29


SSCOP A SSCOP B

AA-ESTABLISH.req PDU BGNAA-ESTABLISH.ind.

AA-ESTABLISH.rsp.PDU BGAKAA-ESTABLISH.con.

Figure 1.9Connection establishment of SSCOP

Data transfer and error recovery of SSCOP

As shown in IV, 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).

30


1 (0) 2 (0) 3 (0) 4 (0)

1 2XX

X X

5 (1) 6 (1) 7 (1)

X X 7

T1160080-94/d82

5 (1) 6 (1)

34

X X

Free 1, 2

Action DeliveredTx Rx

FI GU RE I I .9/Q .2110Error r ecovery via solicited and unsolicited ST AT s

of the last transmitted SD PDUs

POLL(5.1)

STAT (3,1,N (MR), {3,5})

USTAT (3, N (MR), {5,7})

Figure 1.10Data 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 IV.

SSCOPA

SSCOPB

END

ENDAK

AA-RELEASE.request

AA-RELEASE.confirm

AA-RELEASE.indication

Figure 1.11Connection release of SSCOP

31


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 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 users (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.

32


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 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 3.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:

33


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.

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-

34


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 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.

II is the normal start flow diagram of the SAAL protocol. The transition of the eight states above mentioned is shown in the figure.

35


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-PRO

VING-ind.

T3 expiresC1 > 0

T3 expiresC1 > 0

T3 expiresC1 = 0

MAAL-STOP_PROVI

NG-ind.

AAL-IN_SERVICE-in

d.

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 1.12Normal start flow diagram of SAAL

36

Chapter 3 MTP and MTP3B3.1 MTP3.1.1 OverviewI. MTP1II. MTP2III. MTP3

3.1.2 MTP3 FunctionsI. Signaling Message HandlingI. Signaling Network Management1)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.2)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.3)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 FormatI. The Part Required by the MTP Processing1)Service indicator (SI)2)Sub-service field (SSF)

II. The Signaling Information Part Processed by a User Part1)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.2)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.

III. MTP MessagesIV. Message Examples

3.1.4 Signaling ProceduresI. Message RoutingII. ChangeoverIII. ChangebackIV. Signaling Link ActivationV. Signaling Link RestorationVI. Signaling Link DeactivationVII. Signaling Route Management ProceduresVIII. Transfer Prohibited

3.2 MTP3B3.2.1 Overview3.2.2 Introduction of MTP3BI. MTP3B Structure1)Signaling message handling2)Signaling network management

II. MTP3B Functions1)Message discrimination2)Message distribution3)Message routing4)Signaling traffic management5)Signaling route management6)Signaling link management

3.2.3 MTP3B Message StructureI. Length of User DataII. Service Indicator (SI)III. Changeover Procedure

3.3 SAAL3.3.1 SAAL Function Structure3.3.2 SSCOPI. SSCOP FunctionsII. SSCOP Protocol Data UnitsIII. SSCOP StatesIV. SSCOP Operating Mechanism

3.3.3 SSCF I. SSCF FunctionsII. SSCF Link Alignment

3.3.4 LMI. LM Error Monitoring AlgorithmsII. SAAL Compound States

Signal Mtp3b

Documents

mtp protocol stackthe

mtp3b message structure

mtp3 functions

network functions mtp3

data link mtp1

link functions mtp2

saal function structure

mtp1signaling data link