03_SCCP. 1pdf

7/29/2019 03_SCCP. 1pdf

1/54

7/29/2019 03_SCCP. 1pdf

2/54

Nokia Siemens Networks 2 (54)

Legal notice

Intellectual Property Rights

All copyrights and intellectual property rights for Nokia Siemens Networks training

documentation, product documentation and slide presentation material, all of which areforthwith known as Nokia Siemens Networks training material, are the exclusive property ofNokia Siemens Networks. Nokia Siemens Networks owns the rights to copying, modification,translation, adaptation or derivatives including any improvements or developments. NokiaSiemens Networks has the sole right to copy, distribute, amend, modify, develop, license,sublicense, sell, transfer and assign the Nokia Siemens Networks training material. Individualscan use the Nokia Siemens Networks training material for their own personal self-development only, those same individuals cannot subsequently pass on that same IntellectualProperty to others without the prior written agreement of Nokia Siemens Networks. The NokiaSiemens Networks training material cannot be used outside of an agreed Nokia SiemensNetworks training session for development of groups without the prior written agreement ofNokia Siemens Networks.

Indemnity

The information in this document is subject to change without notice and describes only theproduct defined in the introduction of this documentation. This document is intended for theuse of Nokia Siemens Networks customers only for the purposes of the agreement under

which the document is submitted, and no part of it may be used, reproduced, modified ortransmitted in any form or means without the prior written permission of Nokia SiemensNetworks. The document has been prepared to be used by professional and properly trainedpersonnel, and the customer assumes full responsibility when using it. Nokia SiemensNetworks welcomes customer comments as part of the process of continuous developmentand improvement of the documentation.

The information or statements given in this document concerning the suitability, capacity, orperformance of the mentioned hardware or software products are given as is and all liabilityarising in connection with such hardware or software products shall be defined conclusively ina separate agreement between Nokia Siemens Networks and the customer. However, NokiaSiemens Networks has made all reasonable efforts to ensure that the instructions contained inthe document are adequate and free of material errors and omissions. Nokia SiemensNetworks will, if deemed necessary by Nokia Siemens Networks, explain issues which maynot be covered by the document.

Nokia Siemens Networks will correct errors in the document as soon as possible. IN NOEVENT WILL NOKIA SIEMENS NETWORKS BE LIABLE FOR ERRORS IN THIS

DOCUMENT OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL,DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY MONETARYLOSSES,SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESSINTERRUPTION, BUSINESS OPPORTUNITY OR DATA,THAT MAY ARISE FROM THEUSE OF THIS DOCUMENT OR THE INFORMATION IN IT

This document and the product it describes are considered protected by copyrights and otherintellectual property rights according to the applicable laws.

Wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark ofNokia Corporation. Siemens is a registered trademark of Siemens AG.

Other product names mentioned in this document may be trademarks of their respectiveowners, and they are mentioned for identification purposes only.

Copyright Nokia Siemens Networks 2008. All rights reserved.

7/29/2019 03_SCCP. 1pdf

3/54

Contents


Contents

1 Objectives............................................................................................. 52 Introduction.......................................................................................... 63 SCCP Messages................................................................................. 103.1 Connectionless Service Messages....................................................... 103.2 Connection-oriented Messages............................................................ 133.2.1 Connection Establishment ................................................................... 153.2.2 Data Transfer and Connection Release ............................................... 164 SCCP Formats and Codes................................................................. 184.1 SCCP Message Parameters ................................................................ 214.2 SCCP Segmentation (Connectionless Service).................................... 294.3 SCCP Message Exercise..................................................................... 305 Routing of SCCP Message ................................................................ 326 SCCP Management ............................................................................ 346.1 SCCP Signalling Point Status Management.................. ....................... 356.1.1 Signalling Point Prohibited ................................................................... 356.1.2 Signalling Point Allowed....................................................................... 366.2 SCCP Subsystem Status Management................................................ 366.2.1 Subsystem Allowed.............................................................................. 376.2.2 Subsystem Status Test ........................................................................ 387 SCCP Alarms...................................................................................... 408 SCCP Parameter Handling ................................................................ 428.1 SCCP Signalling Point Parameters...................................................... 42

7/29/2019 03_SCCP. 1pdf

4/54

Summary of changes


Summary of changes

7/29/2019 03_SCCP. 1pdf

5/54

Objectives


1 ObjectivesOn completion of this module, you should be able to:

Describe the functionality of SCCP in SS7 protocol stack

Explain the complete structure of an SCCP message

Understand SCCP services: connection oriented andconnectionless

Understand SCCP routing functions: SCP, SN, GT

Interpret printout of SCCP messages

List SCCP parameters in DX200 NE

7/29/2019 03_SCCP. 1pdf

6/54

Introduction


2 IntroductionThe Signalling Connection Control Part (SCCP) is a User Part of theCommon Channel Signalling System 7 (CCS7). It provides additionalfunctions to the Message Transfer Part (MTP) to cater for bothconnectionless as well as connection-oriented network services to

transfer non-circuit related signalling information between exchanges intelecommunication networks.

The SCCP resides on top of MTP and capable of using services of theMTP as described in ITU-T Q.701-707 and/or MTP3b ITU-T Q.2210.The combination of SCCP and MTP is called Network Service Part(NSP). The NSP follows the principles of OSI reference model providinga subset of the layer 3 services as defined in ITU-T X.213.

SCCP is covered under ITU-T specifications Q.711-719.

Services provided by SCCP (see table 1 for details):

Connectionless service

Connection-oriented service

7/29/2019 03_SCCP. 1pdf

7/54

Introduction


Table 1. Two categories of SCCP protocols

Connectionlessservices

Basic connectionless service (protocol class 0)

The data packets can be delivered out of sequence; thereis no control on the transmission path. The SCCP dataformat is either Unit Data (UDT) or a Unit Data Service(UDTS).

Sequenced connectionless service (protocol class 1)

The data packets are sequenced by using the same path.This is ensured by having the same SLS for each MSU ofthe group.

Connection-oriented services

Basic connection-oriented service (Protocol class 2)

It offers bi-directional transfer of data units by establishing

a temporary connection. The SLS is the same for allMSUs or PDUs in the group. The format protocol of theSignalling unit is called Dataform1 (DT1).

Flow control connection-oriented service (Protocolclass 3)

Not used in BSS/RAN/CN

As the name suggests, a control on the rate of flow ofdata is maintained by either the remote signalling point orby higher layers. A detection of message loss andsequencing is included in the service. If an error occurs,the connection is reset and the remote SCCP is informed.The Format Protocol of MSU or PDU is calledDataform2 (DT2).

In GSM, protocol classes 0 and 2 are used most frequently. Figure 1shows the possible users of SCCP services.

7/29/2019 03_SCCP. 1pdf

8/54

Introduction


MTP

RANAP/

BSSAP

SCCP

TUP/

ISUP

TCAP

MAP/CAP

Connection-oriented ServiceConnectionless Service

Figure 1. Users of SCCP services

Basic

Connectionless

Service

Sequenced

Connectionless

Service

Basic

Connection-

oriented

Service

Flow Control

Connection-

oriented

Service

Connectionless

Services

Connection-oriented

Services

0 1 2 3

Services provided by the SCCP

Protocol

Class

Figure 2. SCCP services

7/29/2019 03_SCCP. 1pdf

9/54

Introduction


SCCP functions can be divided into:

SCCP Connection Oriented ControlProvides procedures for establishing, supervising, and releasing atemporary connection. It also handles data transfer on this

connection.

SCCP Connectionless ControlProvides procedures for connectionless data transfer of user data.SCCP connectionless control also distributes messages fromSCCP Management.

SCCP RoutingProvides point-to-point routing through GT translation capabilities.SCCP routing relies on MTP for the actual data transfer.

SCCP ManagementProvides congestion control procedures to meet the networkperformance by re-routing or throttling the traffic.

SCCP

SCCP Users

SCCP connectionlesscontrol

SCCP RoutingSCCP Management

SCCP ConnectionOriented Control

MTP

MTP - PAUSEMTP - RESUMEMTP - STATUS

SSASSPSST

UDT, UDTS

CR, CC,CREF,RLSD,RLC, DTI,

ERR, IT

N- UNITDATA req.

MTP Transfer req.

MTP Transfer ind.

N- UNITDATA ind.

N- CONNECT req.

N-CONNECT ind.

Figure 3. SCCP functions

7/29/2019 03_SCCP. 1pdf

10/54

SCCP Messages


3 SCCP Messages3.1 Connectionless Service Messages

The connectionless services of protocol class 0 and 1 use six SCCPmessages: Unitdata (UDT), Unitdata Service (UDTS), ExtendedUnitdata (XUDT),Extended Unitdata Service (XUDTS), Long Unitdata(LUDT) and Long Unitdata Service (LUDTS).

A UDT message can be used by an SCCP wanting to send data in aconnectionless mode. A UDTS message is used to indicate to theoriginating SCCP that a UDT sent cannot be delivered to its destination.Exceptionally and subject to protocol interworking considerations, aUDTS might equally be used in response to an XUDT or LUDTmessage. A UDTS message is sent only when the option field in thatUDT is set to return on error

An XUDT message is used by the SCCP wanting to send data (along

with optional parameters) in a connectionless mode. An XUDTSmessages is used to indicate to the originating SCCP that an XUDTcannot be delivered to its destination. Exceptionally and subject toprotocol interworking considerations, an XUDTS might equally be usedin response to a UDT or LUDT message. An XUDTS message is sentonly when the return message on error option in the XUDT (or possiblyLUDT) is set.

A LUDT is used by the SCCP to send data (along with optionalparameters) in a connectionless mode. When MTP capabilitiesaccording to Recommendation Q.2210 are present, it allows sending ofNSDU sizes up to 3952 octets without segmentation. LUDTS messageis used to indicate to the originating SCCP that an LUDT cannot bedelivered to its destination. An LUDTS message is sent only when thereturn message on error option in the LUDT is set.

Table 2 summarizes the connectionless service related messages.

7/29/2019 03_SCCP. 1pdf

11/54

SCCP Messages


Table 2. SCCP connectionless service related messages

Message

Servicetype

Description

UDT 0,1 Unitdata

UDTS 0,1 Unitdata Service. Used to indicate to the originatingSCCP that a UDT cannot be delivered to itsdestination. Sent only if the option field incorresponding UDT message is set to return on error

XUDT 0,1 Extended Unitdata. Used to send data along withoptional parameters.

XUDTS 0,1 Extended Unitdata Service. Used to indicate to theoriginating SCCP that an XUDT cannot be delivered toits destination. Sent only if the option field incorresponding XUDT message is set to return onerror

LUDT 0,1 Long Unitdata. Used to send data along with optionalparameters over MTP3b (Q.2210). Up to 3952 octetswithout segmentation are allowed.

LUDTS 0,1 Long Unitdata Service. Used to indicate to theoriginating SCCP that an LUDT cannot be delivered toits destination. Sent only if the option field incorresponding LUDT message is set to return onerror

UDT(S), XUDT(S) and LUDT(S) contain the addresses of the receiverand the sender. With the UDT, XUDT and LUDT, these addresses aredelivered by the user. When returning a UDT with UDTS, sender andreceiver address are simply interchanged.

Furthermore, UDT(S), XUDT(S) and LUDT(S) contain a user message.In the case of the UDT, XUDT and LUDT, it is the message to betransported whereas, in the case of UDTS, XUDTS and LUDTS, it is themessage which could not be delivered.

Additionally, it is indicated in the UDT, XUDT and LUDT whether itbelongs to protocol class 0 or 1. If the message must be returned withUDTS, XUDTS and LUDTS, the (X/L)UDTS belongs to the sameprotocol class as the preceding (X/L)UDT.

The segmentation parameter of XUDT and XUDTS tells first, if themessage is divided into several segments at all. If yes, there is

information about how many segment are still following, which one is thefirst segment and a reference number, which is common for allsegments of one message. The maximum size of one message is here 4Kbyte.

7/29/2019 03_SCCP. 1pdf

12/54

SCCP Messages


The value of the Hop Counter is decremented on each global titletranslation. The maximum value is 15. The message must arrive at itsdestination, before the counter reaches the value 0.

Finally, the (X)UDTS contains the cause why the message had to be

returned, (e.g. "No translation for this specific address", "Networkfailure", "Network congestion" etc.).

UDT(Sender,Receiver,

Protocol class,User message)

XUDT(Sender,Receiver,

Protocol class, Hop Counter,Segmentation,User message)

SCCP connectionless services positive case

Figure 4. Connectionless SCCP services- positive cases

7/29/2019 03_SCCP. 1pdf

13/54

SCCP Messages


XUDTS(Sender,Receiver,Cause,

User message)

UDT

(Sender,Receiver,Protocol class,User message)

XUDT(Sender,Receiver,

Protocol class, Hop Counter,Segmentation,User message)

XUDTS(Sender,Receiver,

Cause, Hop Counter,Segmentation, User message)

X

SCCP connectionless services negative case

Figure 5. Connectionless SCCP services negative cases

3.2 Connection-oriented Messages

With the connection oriented services of protocol class 2, there are themessages Connect Request (CR), Connect Confirm (CC),

Connection Refused (CREF), Data Form 1 (DT1), Inactivity Test(IT), Protocol Data Unit Error (ERR), Released (RLSD), andRelease Complete (RLC). Further messages, e.g. Data Form 2 (DT2)are defined for protocol class 3 and can be neglected here.

A CR message is initiated by a calling SCCP to a called SCCP torequest the setting up of a signalling connection between the twoentities. The required characteristics of the signalling connection arecarried in various parameter fields. On reception of a CR message, thecalled SCCP initiates the setup of the signalling connection, if possible,and replies the calling SCCP with the CC message.

A CREF message is initiated by the called SCCP or an intermediatenode SCCP to indicate to the calling SCCP that the setup of the

signalling connection has been refused.

CR, CC and CREF messages are used during connection establishmentphase by connection-oriented protocol class 2 or 3.

7/29/2019 03_SCCP. 1pdf

14/54

SCCP Messages


A DT1 message is sent by either end of a signalling connection to passtransparently SCCP user data between two SCCP nodes.

DT1 is used during the data transfer phase in protocol class 2 only.

A ERR message is sent on detection of any protocol errors. It is usedduring the data transfer phase in protocol classes 2 and 3.

An IT message may be sent periodically by either end of a signallingconnection section to check if this signalling connection is active at bothends and to audit the consistency of connection data at both ends.

A RLSD message is sent, in the forward or backward direction, toindicate that the sending SCCP wants to release a signalling connectionand the associated resources at the sending SCCP have been broughtinto the disconnect pending condition. It also indicates that the receivingnode should release the connection and any other associated resourcesas well. A RLC message is sent in response to the RLSD messageindicating that the RLSD message has been received and the

appropriate procedures have been completed.RLSD and RLC messages are used during connection release phase inprotocol classes 2 and 3.

Tabel 3 summarizes the connectionless service related messages.

Table 3. SCCP connection-oriented service related messages

Message

Servicetype

Description

CR 2,3 Connection Request

CC 2,3 Connection Confirm

CREF 2,3 Connection Refused

DT1 2 Data Form 1

DT2 3 Data Form 2

AK 3 Data Acknowledgement. Used to control the windowflow control mechanism selected for the data transferphase.

ED 3 Expedited Data. Similar to DT2 but it can bypass theflow control mechanism.

EA 3 Expedited Data Acknowledgement. Every EDmessage must be acknowledged with EA messagebefore another ED is sent.

7/29/2019 03_SCCP. 1pdf

15/54

SCCP Messages


Message

Servicetype

Description

IT 2,3 Inactivity Test. Sent periodically to check if the

connection is still active at both ands and to audit theconsistency of data.

ERR 2,3 Protocol Data Unit Error. Sent on detection of theSCCP protocol error.

RLSD 2,3 Released

RLC 2,3 Release Complete

RSR 3 Reset Request. Indicates that the SCCP needs toreset the sequence numbers.

RSC 3 Reset Confirm.

These connection-oriented messages are used mainly in 3 phases ofsignalling connection establishment:

Connection establishment phase

Data transfer phase

Connection release phase

3.2.1 Connection Establishment

The connection establishment procedure consists of the functionsrequired to establish a temporary signalling connection between two

users of the SCCP. It is initiated by an SCCP user by invoking the N-CONNECT request primitive. The CR message and the CC messageare used to set up connection sections.

During connection establishment, each of the connection partners,source and destination, selects its local references number(LR)independently to a connection section. Once the destination referencenumber is known, it is a mandatory field for all messages transferred onthat connection section.

In order to set up an SCCP signalling connection, the initiating sideselects a local reference and tells it to its partner by means of themessage "Connect Request" (CR). The partner side will, on reception ofthe CR, select its own local reference and return the message "Connect

Confirm" (CC) which contains both local references. Thus, each sideknows its own and its partners local reference, and the SCCPtransaction is established.

7/29/2019 03_SCCP. 1pdf

16/54

SCCP Messages


In the negative case, however if, for some reason or other, theconnection cannot be set up, the message "Connect Refused" (CREF) isreturned. It contains the local reference of the initiating side and thereason for the refusal (e.g. "Destination address unknown", "End user

congestion", "End user failure" etc.).

A BSelLRA

SelLRB

LRBLRA

CR

(Protocol class, LRA,Receiver,

poss. User message)

CC

(LRB, Protocol class, LRA,poss. User message)

Successful SCCP connection establishment

A BSelLRA

LRA

CR

(Protocol class, LRA,Receiver,

poss. User message)

CREF

(LRA, Cause)

Unsuccessful SCCP connection establishment

X

Figure 6. SCCP connection establishment

3.2.2 Data Transfer and Connection Release

As long as the SCCP transaction exists, both sides can send usermessages over the transaction to the partner. This is done by means ofthe SCCP message "Data Form 1" (DT1). The message contains theuser message and the local reference of the receiving side so that thereceiver can address immediately the appropriate memory area.Furthermore, there is the segmenting, reassembling parameter included,which tells, if the message is divided into several segments. This takesplaces if the message is longer than 255 bytes.

7/29/2019 03_SCCP. 1pdf

17/54

SCCP Messages


When one of the two partners wants to clear down the SCCPtransaction, he sends the SCCP message "Released" (RLSD) to thepartner side. This message contains both local references and the causefor the clear down (e.g. "End user originated", "Network failure" etc.).

The partner side answers with "Release Complete" (RLC); again, thismessage contains both local references. Thus, the SCCP connection iscleared down, and both local references are released.

By the way: user messages can be delivered already during thetransaction set up (in the CR and/or in the CC) and still during thetransaction clear down (in the RLSD, but not in the RLC).

A B

LRBLRA

DT1

(LRB, Segmenting/Reassembling *),User message)

DT1

(LRA, Segmenting/Reassembling *),User message)

LRB LRA

A B

LRBLRA

RLSD

(LRA,LRB, Cause,poss. User message)

LRB LRA

RLC

(LRA,LRB)

SCCP data transfer

SCCP connection release

Figure 7. SCCP data transfer and connection release

7/29/2019 03_SCCP. 1pdf

18/54

SCCP Formats and Codes


4 SCCP Formats and CodesThe SCCP messages are conveyed in the SIF field of MSU of theMTP3/MTP3b. It consists of, after the routing label, the following parts(See figure 8):

The message type code

The mandatory fixed part

The mandatory variable part

The optional part, which may contain fixed length and variablelength fields

D P C

O P C

S L S

Message type code

Mandatory fixed part

Optional part

Mandatory variable part

MTP

RoutingLabel

SCCPMessage

SIF

Figure 8. SCCP message structure: general layout

7/29/2019 03_SCCP. 1pdf

19/54



The SCCP message uses the ASN.1 format. Any messages in thisformat, depending on the type of message, can contain differentparameters. Each parameter has this structure:

Parameter code

Parameter length

Parameter contents

Message type code

Mandatory parameter A

Mandatory parameter F

Pointer to parameter M

Pointer to parameter P

Pointer to start of optional part

Length indicator to parameter M

Mandatory parameter M

Length indicator parameter P

Mandatory parameter P

Identifier parameter X

Length indicator parameter X

Optional parameter X

Identifier parameter Z

Length indicator parameter Z

Optional parameter Z

End of theo ptional parameters

Mandatory fixed partMandatory fixed part.

.

.

.

.

.

.

.

.

.

.

.

Mandatory variable partMandatory variable part

Optional partOptional part

8 | 7 | 6 | 5 | 4 | 3 | 2 | 1

Figure 9. SCCP message structure

The message type code consists of a one octet field and is mandatoryfor all messages. It uniquely defines the function and format of eachSCCP message.

With the mandatory fixed parameters, not only the length but also thesequence is defined (per message type). Therefore, neither identifiers

nor length indicators are required. After the message type, the contentsof the mandatory fixed parameters ensue in the pre-defined sequencewith the pre-defined length.

To each mandatory variable parameter, there is a pointer of 1 bytelength which indicates how many bytes follow until the begin of the

7/29/2019 03_SCCP. 1pdf

20/54



parameter in question. If, for example, the pointer has the value 1, thenthe parameter begins in the subsequent byte; if the pointer-value is 2,the parameter begins in the next byte but one, and so on. The pointersfollow immediately after the last mandatory fixed parameter; again, their

sequence is pre-arranged (per message type), but the order of themandatory variable parameters themselves could vary.

After the pointers to the mandatory variable parameters, the pointer tothe optional part ensues. This pointer is present whenever the messagetype allows the presence of optional parameters. With message typeswhere no optional parameters can exist (e.g. UDT), the pointer to theoptional part is not included either. On the other hand, there aremessage types, which have optional but no mandatory variableparameters (e.g. CC). With these messages, the mandatory variablesection consists of the pointer to the optional part alone.

If a message type allows the presence of optional parameters but aparticular message of this type has none (e.g. a RLSD without user

message), the pointer to the optional part is present but its value is 0. Ifoptional parameters are present, the pointer to the optional part musthave at least the value 1 (since the optional part cannot begin earlier butin the next byte).

The message section consisting of the mandatory fixed parameters, thepointers to the mandatory variable parameters and the pointer to theoptional part is distinguished by a fixed length and order of itscomponents. As soon as the message type is identified, each mandatoryfixed parameter and each mandatory variable parameter can beaccessed by a simple method, and even the begin of the optional pertcan be found without a lengthy search.

The mandatory variable parameters themselves begin with a length

indicator of 1 byte length. After this, as many bytes of parametercontents ensue as the length indicator says.

Finally, the optional parameters can be found in an arbitrary sequence.Each optional parameter begins with an identifier of 1 byte length. Next,there follows a length indicator (again 1 byte) and as many bytes ofcontents as the length indicator says. The length indicator is includedeven if the length is fixed.

If optional parameters are present, after the last parameter (i.e. wherethe next identifier is to be expected) the end of the optional part ismarked. The mark is the byte 0000 0000 = H'00. Thus, no parameterwith the identifier H'00 can exist; rather, H'00 in the position of aparameter identifier marks the end of the optional part and thus the end

of the SCCP message as a whole.

7/29/2019 03_SCCP. 1pdf

21/54



4.1 SCCP Message Parameters

Table X shows different SCCP message parameters. Detailedinformation about all parameters can be found in ITU-T recommendationQ.713.

Table 4. SCCP message parameters

Parameter Name Code CR CC CREF RLSD RLC DT1 UDT UDTS XUDT XUDTS

LUDT LUDTS

Destination LocalReference

01 M M M M M

Source LocalReference

02 M M M M

Called PartyAddress

03 M O O M M M M M M

Calling PartyAddress

04 O M M M M M M

Protocol Classes (0to 3)

05 M M M M M

Segmenting/Reassembling

06 M

Segmentation 10 O O O O

Credit 09 O O

Error Cause 0D

Data 0F O O O O M M M M M

Hop counter 11 O M M M M

Importance 12 O O O O O O O O

Long Data 13 M M

Refusal cause 0E M

Release cause 0A M

Return cause 0B M M M

As an example we take a look at the UDT message. The UDT messagecontains three pointers and the parameters indicated in Table 5.

This Unitdata message type results in the format shown in Figure 10.

7/29/2019 03_SCCP. 1pdf

22/54



Table 5. Message type: Unitdata

Parameter Type Length(octets) Value

Message type Mandatory fixedpart

1 09

Protocol class Mandatory fixedpart

1 0 or 1

Called party address Mandatoryvariable part

3 minimum

Calling party address Mandatoryvariable part

2 minimum

Data Mandatoryvariable part

2-Xa)

a)Due to the ongoing studies on the SCCP called and calling party address,

the maximum length of this parameter needs further study. Note that thetransfer of up to 255 octets of user data is allowed when the SCCP calledand calling party address do not include global title.

F CK SIF SIO LIFIB

FSNBIB

BSN FMTPmessage

First bit

transmitted

8n 8 8 32 4 4 [bit]

User DataPointerto data

Protocolclass

Messagetype

H09 UDT

RoutingLabel

1000NA0

0011SCCP

User data

L

ength

Callingparty

address

L

ength

Calledparty

address

L

ength

DataPtr.

CgPAPtr.

CdPAPtr

SCCPmessage

Figure 10. UDT message structure

7/29/2019 03_SCCP. 1pdf

23/54



The protocol classparameter field is a one-octet parameter field and isstructured as follows:

Bits 1-4 indicating protocol class. It was coded as follows:

Bits4 3 2 1

0 0 0 0 Class 0

0 0 0 1 Class 1

0 0 1 0 Class 2

0 0 1 1 Class 3

Bits 5-8 are used to specify message handling (controlled byVM7FIL) as follows:

Bits

8 7 6 50 0 0 0 No special options

1 0 0 0 Return message on error

When bits 1-4 are coded to indicate a connection-oriented protocolclass (class 2, 3), bits 5-8 are spare.

The called/ calling party addressis a variable length parameter. Itsstructure is shown in Figure 11. It consists of the address indicator andthe address.

The address indicatorshows the type of address information contained

in the address field. The addressconsists of one or any combination ofthe following elements:

Signalling Point Code (SPC)

Subsystem Number (SSN)

Global title

The encoding of the address indicator is as follow:

Bit 1 Point code indicator

1 indicates that the address contains a signalling point code

Bit 2 SSN indicator

1 indicates that the address contains a subsystem number

7/29/2019 03_SCCP. 1pdf

24/54



Reservef

ornational

use

Routingindicator Global title indicator

SSNindicator

Pointcode

indicator

S P C

Subsystem Number

Translation Type (TT)

Numbering Plan (NP) Encoding Scheme

Nature of Address (NA)SpareO/E*)

*) With Typ 1 :Odd-Even-IndicatorWith Typ 4:Spare (0)

2. GT-Digit

4. GT-Digit

1. GT-Digit

3. GT-Digit

0 0

12345678

MSB

LSB

Address IndicatorOctet 1

Octet 2

Octet 3

.

.

.

Octet n

Figure 11. Called/Calling party address

Bit 3-6 Global Title Indicator (GTI)

GTI is encoded as in Table 6:

Bit 7 Routing indicator

1 indicates routing on SSN. Routing should be based on thedestination point code in the MTP routing label and thesubsystem number information in the called party address

0 indicates routing on GT. Routing should be based on theglobal title in the called party address.

Bit 8 Reserved for national use and is always set to zero on aninternational network.

7/29/2019 03_SCCP. 1pdf

25/54



Table 6. Global title indicator coding

Bits 6 5 4 3 Meaning0 0 0 0 No global title included

0 0 0 1 Global title includes nature of address indicator only

0 0 1 0 Global title includes translation type only

0 0 1 1 Global title includes translation type, numbering plan andencoding scheme

0 1 0 0 Global title includes translation type, numbering plan,

encoding scheme and nature of address indicator

0 1 0 1

to

0 1 1 1

Spare international

1 0 0 0

to

1 1 1 0

Spare national

1 1 1 1 Reserved for extension.

The Subsystem Number (SSN)identifies an SCCP user function. Itconsists of one octet codes as shown in Table 7.

Table 7. Subsystem number coding

Bits 8 7 6 5 4 3 2 1 Meaning

0 0 0 0 0 0 0 0 SSN not known/not used

0 0 0 0 0 0 0 1 SCCP management

0 0 0 0 0 0 1 0 Reserved for ITU-T allocation

0 0 0 0 0 0 1 1 ISDN user part

0 0 0 0 0 1 0 0 OMAP (Operation, Maintenance andAdministration Part)

0 0 0 0 0 1 0 1 MAP (Mobile Application Part)

0 0 0 0 0 1 1 0 HLR (Home Location Register)

0 0 0 0 0 1 1 1 VLR (Visitor Location Register)

7/29/2019 03_SCCP. 1pdf

26/54



Bits 8 7 6 5 4 3 2 1 Meaning

0 0 0 0 1 0 0 0 MSC (Mobile Switching Centre)

0 0 0 0 1 0 0 1 EIC (Equipment Identifier Centre)

0 0 0 0 1 0 1 0 AUC (Authentication Centre)

0 0 0 0 1 0 1 1 ISDN supplementary services

0 0 0 0 1 1 0 0 Reserved for international use

0 0 0 0 1 1 0 1 Broadband ISDN edge-to-edge applications

0 0 0 0 1 1 1 0 TC test responder

0 0 0 0 1 1 1 1

To

0 0 0 1 1 1 1 1

Reserved for international use

0 0 1 0 0 0 0 0

To

1 1 1 1 1 1 1 0

Reserved for national networks

1 1 1 1 1 1 1 1 Reserved for expansion of national andinternational SSN

The Global Title (GT)format is of variable length. There are four

possible formats of global title, which are type 1 to 4.The Global Title Type 4 is used for international network applications. Itconsists of translation type, numbering plan, encoding scheme, nature ofaddress indicator and global title address information.

Figure 12-15 illustrates all fields and the corresponding coding.

7/29/2019 03_SCCP. 1pdf

27/54



Bits 87654321 Decimal value Translation type

00000000 0 Unknown

00000001 1

00111111 63

International services

01000000 64

01111111 127

Spare

10000000 128

11111110 254

National network specific

11111111 255 Reserved for expansion

Figure 12. Translation type

Bits 7654321 Nature of address

0000000 Unknown

0000001 Subscriber number

0000010 Reserved for national use

0000011 National significant number

0000100 International number

0000101

1111111

Spare

Figure 13. Nature of address

7/29/2019 03_SCCP. 1pdf

28/54



Bits 8765 Numbering plan

0000 Unknown

0001 ISDN/telephony numbering plan

(Recommendations E.163 and E.164)

0010 Generic numbering plan

0011 Data numbering plan (Recommendation X.121)

0100 Telex numbering plan (Recommendation F.69)

0101 Maritime mobile numbering plan (Recommendations E.210, E.211)

0110 Land mobile numbering plan (Recommendation E.212)

0111 ISDN/mobile numbering plan (Recommendation E.214)

1000

1101

Spare

1110 Private network or network-specific numbering plan

1111 Reserved

Figure 14. Numbering plan

Bits 4321 Encoding scheme

0000 Unknown

0001 BCD, Odd number of digits

0010 BCD, Even number of digits

0011 National specific

0100

1110

Spare

1111 Reserved

Figure 15. Encoding schemes

7/29/2019 03_SCCP. 1pdf

29/54



4.2 SCCP Segmentation (Connectionless Service)

"SCCP connectionless segmentation" is a service provided transparentlyto the SCCP user, which allows connectionless transfer of a block ofuser data larger than can be contained in a single (X)UDT message. TheSCCP provides this service by segmenting a large block of user datainto smaller blocks (called segments), transmitting the segments as userdata in XUDT messages (the use of LUDT messages for this purpose isfor further study), and reassembling the segments in the destinationnode before passing the original block of user data to the (remote)destination SCCP user. At the destination SCCP, this reassemblingprocess is called reassembly.

Segmentation Local Reference

8 7 6 5 4 3 2 1F C Spare Remaining Segment Octet 1

Octet 2

Octet 3

Octet 4

Figure 16. Segmentation field coding

When SCCP segments data an optional field is inserted into XUDTmessage segmentation field. The coding is shown on the Figure 15.Bit F indicates if the segment is the first one or not (F=1 first segment,F=0 all other segments). Bit C indicates the protocol class requested bythe SCCP user (C=1 Class 1, C=0 Class 0 selected). RemainingSegment field indicates the number of remaining segments. The values0000 to 1111 are possible, the value 0000 indicates the last segment.

7/29/2019 03_SCCP. 1pdf

30/54



4.3 SCCP Message Exercise

Decode the following UDT message, according to the SCCP messagestructure:

Octet Value Description

Message Type (Mandatory Parameter with fixed length = 1 octet)

1 Message Type =

Protocol Class (Mandatory Parameter with fixed length = 1 octet)

2 Protocol Class =Called Party Address (Mandatory Parameter with variable length)

3 Pointer =

Length =

Address Indicator =

SPC =

SSN =

GT / TT =

GT / NP =GT / Coding Scheme =

GT / NAI =

GT / DIG =

Calling Party Address (Mandatory Parameter with variable length)

4 Pointer =

Length =

Address Indicator =

SPC =

SSN =

GT / TT =

GT / NP =GT / Coding Scheme =

GT / NAI =

GT / DIG =

Data (Mandatory Parameter with variable length)5 Pointer =

Length =

Data =

7/29/2019 03_SCCP. 1pdf

31/54



Figure 17. SCCP decoding from protocol analyzer

.

7/29/2019 03_SCCP. 1pdf

32/54

Routing of SCCP Message


5 Routing of SCCP MessageFigure 18 shows different routing techniques for SCCP messages.

BSSAP/ RANAP MAP INAP

Is DPC containedin the message?

Yes No (there is a GT)

Routing on label(do nothing)

Routing on GT(GT analysis)

Message handling

Applicationparts

SCCP

MTP

Figure 18. Routing techniques of SCCP message

The MSU can be routed through a signalling point in one of three ways:

The MSU initially is routed based on the SIO, the OPC, and the

DPC. If DPC = Own SPC and NI = own network, the SCCP routesthe message based on the route indicator. In other words, pass themessage to the route indicated in DPC.

7/29/2019 03_SCCP. 1pdf

33/54

Routing of SCCP Message


If the route indicator says SSN, the message is routed to theconcerned user part (refer to the table below).

The route indicator is GT. Routing on GT implies re-analysing thecalled party address, and comparing it with internal GT analysis

tables to route the call.

Table 8. SCCP subsystem number of user parts

User Part SSN

MAP M 08

MAP V 07

MAP H 06

MAP E 09

BSSAP FE

RANAP 8E

7/29/2019 03_SCCP. 1pdf

34/54

SCCP Management


6 SCCP ManagementThe purpose of the SCCP management is to provide procedures tomaintain network performance by rerouting or throttling traffic in theevent of failure in the network.

SCCP management is organized in two sub-functions: signalling point

status management and subsystem status management. SCCPmanagement messages are defined to be transferred using the SCCPconnectionless service. The list of SCCP management messages isgiven below.

Table 9. SCCP management related messages

Message Description

SSA Subsystem Allowed

SOG Subsystem Out Of Service Grant

SOR Subsystem Out Of Service Request

SSP Subsystem Prohibited

SST Subsystem Status Test

SSC Subsystem Congested

SCCP management utilizes the concept of a concerned subsystem orsignalling point. If a subsystem/signalling point is marked as concernedin the local SCCP it means that it needs to be informed about any statechanges in the local SCCP or subsystems. Two methods are employedto inform remote SCCP when such changes occur: to thoseSCCP/subsystems marked as concerned a broadcast method used and

a response method used in other cases.

7/29/2019 03_SCCP. 1pdf

35/54

SCCP Management


6.1 SCCP Signalling Point Status Management

SCCP signalling point status management update translations andstates based on the information of the network failure, recovery orcongestion provided by MTP-PAUSE, MTP-RESUME or MTP-STATUSprimitives. This allows alternative routing to backup signalling pointsand/or backup subsystems.

6.1.1 Signalling Point Prohibited

When SCCP management receives an MTP-PAUSE indication primitiverelating to a destination that becomes inaccessible, or an MTP-STATUSindication primitive relating to an SCCP that becomes unavailable,SCCP management performs the following actions.

1. Informs the translation function to update the translation tables.2. In the case where the SCCP has received an MTP-PAUSE

indication primitive, SCCP management marks as "prohibited" thestatus of the remote signalling point, the remote SCCP and eachsubsystem at the remote signalling point.

In the case where the SCCP has received an MTP-STATUS indicationprimitive relating to an unavailable SCCP, the SCCP marks the status ofthe SCCP and each SSN for the relevant destination to "prohibited" andinitiates a subsystem status test with SSN = 1. If the cause in theMTP-STATUS indication primitive indicates "unequipped user", then nosubsystem status test is initiated.

3. Discontinues all subsystem status tests (including SSN = 1) if an

MTP-PAUSE or MTP-STATUS indication primitive is received witha cause of "unequipped SCCP". The SCCP discontinues allsubsystem status tests, except for SSN = 1, if an MTP-STATUSindication primitive is received with a cause of either "unknown" or"inaccessible".

4. Initiates a local broadcast of "User-out-of-service" information foreach subsystem at that destination.

5. Initiates a local broadcast of "signalling point inaccessible"information for that destination if an MTP-PAUSE indicationprimitive is received.

6. Initiates a local broadcast of "remote SCCP unavailable" if either

an MTP-PAUSE indication primitive or an MTP-STATUS indicationprimitive is received.

7/29/2019 03_SCCP. 1pdf

36/54

SCCP Management


6.1.2 Signalling Point Allowed

When SCCP management receives an MTP-RESUME indicationprimitive relating to a destination that becomes accessible, or when it

receives a subsystem allowed message relating to SSN = 1 at a remotedestination which had been considered "prohibited", or when t imer T(statinfo) expires, SCCP management performs the following actions:

1. Sets the congestion state of that signalling point if anMTP-RESUME indication primitive is received.

2. Instructs the translation function to update the translation tables.

3. Marks as "allowed" the status of that destination, and the SCCP, ifan MTP-RESUME indication primitive is received.

4. Marks as "allowed" the status of the SCCP if a subsystem allowedmessage is received for SSN = 1 or if timer T(stat info) expires.The subsystem status test for SSN = 1, if running, is stopped.

5. Marks as "allowed" the status of remote subsystems. As a nationalnetwork provider option, the subsystem status can be marked as"prohibited" for a list of selected subsystems.

6. Initiates a local broadcast of "signalling point accessible"information for that destination if a MTP-RESUME indicationprimitive is received.

7. Initiates a local broadcast of "remote SCCP accessible" if either anMTP-RESUME indication primitive or a subsystem status allowedmessage is received for SSN = 1 or if timer T(stat info) expires.

8. Initiates a local broadcast of "User-in-service" information for asubsystem associated with the MTP-RESUME indication primitive.

6.2 SCCP Subsystem Status Management

Subsystem status management updates the subsystem status based onthe information of failure, withdrawal, and recovery of subsystems. Thisallows alternative routing to backup subsystems, if appropriate.Concerned local users are informed of the status changes of other

backup subsystems. Subsystem status management procedures arealso used to convey the status of the SCCP as a whole.

SCCP management messages SSP/SSA are used to convey the statusof SCCP subsystems or SCCP itself (SSA=1). A subsystem prohibitedmessage with SSN = 1 is not allowed.

7/29/2019 03_SCCP. 1pdf

37/54

SCCP Management


If SCCP routing control receives a message, whether originated locallyor not, for a prohibited local system, then SCCP routing control invokessubsystem-prohibited control. A Subsystem-Prohibitedmessage is sentto the signalling point identified by the OPC in the MTP-TRANSFER

indication primitive if the originating subsystem is not local. If theoriginating subsystem is local, any action taken is implementationdependent.

Receipt of Subsystem-Prohibited message or N-STATE request primitive or local user failed

Under one of the following conditions:

SCCP management receives a Subsystem-Prohibitedmessageabout a subsystem marked allowed; or

an N-STATE request primitive with "User-out-of-service"information is invoked by a subsystem marked allowed; or

SCCP management detects that a local subsystem has failed;

then SCCP management does the following:

1. instructs the translation function to update the translation tables;

2. marks as "prohibited" the status of that subsystem;

3. initiates a local broadcast of "User-out-of-service" information forthe prohibited subsystem;

4. initiates the subsystem status test procedure if the prohibitedsubsystem is not local;

5. initiates a broadcast of Subsystem-Prohibitedmessages to

concerned signalling points;6. cancels "ignore subsystem status test" and the associated timer if

they are in progress and if the newly prohibited subsystem residesat the local node.

6.2.1 Subsystem Allowed

Under one of the following conditions:

SCCP management receives a Subsystem-Allowedmessageabout a subsystem other than SSN = 1, marked prohibited; or

an N-STATE request primitive with "User-in-Service" information isinvoked by a subsystem marked prohibited;

then SCCP management does the following:

1. Instructs the translation function to update the translation tables.

7/29/2019 03_SCCP. 1pdf

38/54

SCCP Management


2. Marks as "allowed" the status of that subsystem.

3. Initiates as a local broadcast of "User-in-service" information forthe allowed subsystem.

4. Discontinues the subsystem status test relating to that subsystemif such a test was in progress.

5. Initiates a broadcast of Subsystem-Allowedmessages toconcerned signalling points.

6.2.2 Subsystem Status Test

The subsystem status test procedure is an audit procedure to verify thestatus of a SCCP or subsystem marked as prohibited.

A subsystem status test is initiated when a Subsystem-Prohibitedmessage is received. For a list of selected subsystems, the subsystemstatus test may also be initiated on receipt of an MTP-RESUMEindication primitive, a subsystem allowed message with SSN = 1 or thetime-out of timer T(stat. info)

A subsystem status test associated with a prohibited subsystem iscommenced by starting a timer (stat. info) and marking a test inprogress. No further actions are taken until the timer expires. Uponexpiration of the timer, a Subsystem-Status-Testmessage is sent toSCCP management at the node of the prohibited subsystem and thetimer is reset. The cycle continues until the test is terminated by anotherSCCP management function at that node. Termination of the test causesthe timer and the "test progress mark" to be cancelled.

A subsystem status test for SSN = 1 is initiated when an MTP-STATUSindication primitive is received with "remote user inaccessibility" or"unknown" information for the SCCP at a remote signalling point.

After sending an SST (SSN = 1), the node should receive either anSSA(SSN = 1) from the restarting node or it should receive anMTP-STATUS indication primitive stating User Part Unavailable. In thecase where the SST receiving node has the User Part availability controland its SCCP has not yet recovered, MTP sends a User PartUnavailable (UPU) message to the SST sending node. If neither aSSA(SSN = 1) nor a MTP-STATUS indication primitive (User PartUnavailable) is received by the SST sending SCCP during the durationof the T(stat info) timer, then the node should assume that the previouslyunavailable (SCCP) has recovered. (This ensures backward

compatibility with previous versions of the Recommendation.) If theMTP-STATUS indication primitive stating User Part Unavailable isreceived before timer T(stat info) expires, then an SST(SSN = 1) is sentto the unavailable node when timer T(stat info) expires. A subsystemstatus test associated with an inaccessible SCCP is done in the same

7/29/2019 03_SCCP. 1pdf

39/54

SCCP Management


way as for the one associated with a prohibited subsystem, the onlydifference being that it refers to SSN = 1.

Actions at the receiving node

When SCCP management receives a Subsystem-Status-Testmessageand there is no "ignore subsystem status test" in progress, it checks thestatus of the named subsystem. If the subsystem is allowed, then aSubsystem-Allowedmessage is sent to the SCCP management at thenode conducting the test. If the subsystem is prohibited, no reply is sent.

In the case where the Subsystem-Status-Test message is testing thestatus of SCCP management (SSN = 1), if the SCCP at the destinationnode is functioning, then a Subsystem Allowed message with SSN = 1 issent to SCCP management at the node conducting the test. If the SCCPis not functioning, then the MTP cannot deliver the SST message to theSCCP. A UPU message is returned to the SST initiating node by theMTP.

As soon as its SCCP has recovered, the restarting SCCP shouldbroadcast a Subsystem Allowed message for SSN = 1 to all concernednodes. The restarting SCCP should set the status to "allowed" for theSCCP and all subsystems of remote signalling points that it considersavailable, based on the MTP information at the node.

7/29/2019 03_SCCP. 1pdf

40/54

SCCP Alarms


7 SCCP AlarmsThere are some DX200 alarms related to the SCCP level signalling:

1056 Message from network to unknown subsystem

SCCP has received a message from the network. The message'sdestination is an unknown subsystem.

1242 SCCP global title translation result file error

Report on the output disturbances of the SCCP global title translation.The results output record of the global title translation contains incorrectinformation or global title modification cannot be done to the existingglobal title number. The alarm may have an effect to the traffic capacityof the system. A message that contains the global title in question willnot get to its destination.

1584 SCCP message routing error

Sending connectionless SCCP messages failed.

2241 SCCP subsystem prohibited

A subsystem of the SCCP is unavailable. Signalling messages cannotbe transmitted to the subsystem in question. The fault may affect thetraffic capacity.

2246 SCCP routing failure

The SCCP has failed in routing a message received from the user partof the SCCP. The alarm is caused by erroneous configuration of thesystem. The fault may affect the traffic capacity of the system.

7/29/2019 03_SCCP. 1pdf

41/54

SCCP Alarms


2254 SCCP not defined for the network

The SCCP has received a message addressed to a signalling point orsignalling network for which the SCCP has not been defined. Thesystem might be incorrectly configured and the error can affect the traffic

capacity of the system.

7/29/2019 03_SCCP. 1pdf

42/54

SCCP Parameter Handling


8 SCCP Parameter Handling

8.1 SCCP Signalling Point Parameters

The parameter set related to the SCCP signalling point defines theparameters for certain timers that are used in monitoring the signallingconnections, and for managing the subsystems (ITU-T Rec. Q.714). Theparameter set also defines some of the signalling network functions.

Use the command OCI to find out which parameter set the selectedsignalling point is using. Commands in the command group OC can beused to handle the SCCP signalling point parameters.

Table 10 lists the parameter names, all possible parameter values, thequality of the value, and the recommended values, if any, that arerelated to the SCCP signalling point.

Table 10. SCCP signalling point parameters

Number Parametername/meaning

Value

1 Q714_T_CONN_EST 30.. 240 (1s)

Timer for connection setup.Defines the time for waitingfor a response to theconnection requestmessage. Usually, you donot need to change theparameter value.

90

2 Q714_T_IAS 60.. 600 (1s)

Send inactivity timer. Whenthe timer expires, aninactivity test-message (IT)is sent to the connection

90

7/29/2019 03_SCCP. 1pdf

43/54




Value

section. Note that this timershould normally be at least

two times smaller thanQ714_T_IAR at the otherend.

3 Q714_T_IAR 150.. 1260 (1s)

Receive inactivity timer.Connection is released ifno messages have beenreceived when the timerexpires. Note that this timershould normally be at leasttwo times greater thanQ714_T_IAS at the otherend.

270

4 Q714_T_REL 100.. 200 (100ms)

If the first connectionrelease message(Released, RLSD)produces noacknowledgement (releasemessage or ReleaseCompleted, RLC), therelease message isrepeated and a new timesupervision is started(Q714_T_REP_REL).

150

5 Q714_T_INT 45.. 90 (1s)

Control parameter forconnection release time.The release message isbeing repeated during thattime. After time-out, theresources allocated for theconnection are frozen for acertain time and an alarm isset.

60

6 Q714_T_RES 10.. 20 (1s)

Time supervision forresetting the signallingconnectiona serviceclass 3 timer that is not isuse.

15

7 Q714_T_REP_REL 40.. 200 (100ms)If a repeated connectionrelease message(Released, RLSD)produces noacknowledgement (release

100

7/29/2019 03_SCCP. 1pdf

44/54




Value

message or ReleaseCompleted, RLC) during

the set time supervisionperiod, the releasemessage is repeated and anew time supervision isstarted(Q714_T_REP_REL).

8 Q714_T_STAT_1ST

50.. 600 (100ms)

Time supervision, afterwhich the first SubsystemStatus Test (SST) messageis sent out.

600

9 Q714_T_STAT_INC 150.. 3000 (100ms)

Time that is added to the

repeat interval of the SSTmessage after each repeatevent unless the messageSubsystem Allowed (SSA)is not received.

300

10 Q714_T_STAT_MAX 600.. 12000 (100ms)

The maximum time for therepeat interval of the SSTmessage.

600

11 A_INTERFACE YES, NO

Defines whether thesystem uses the A interfacespecification in the direction

of the SP.12 WHITE_BOOK_MGMT_US

EDYES, NO

Defines whether thesystem uses SCCPmanagement proceduresfor the ITU-T, Q711-Q714,1993/3 (White Book) in thedirection of the SP.

NO

13 SS_MANAGEMENT_USED

YES, NO

Defines whether thesubsystem status

management functions areused.

YES

14 XUDT_USED YES, NO

Defines whether ExtendedUnit Data (XUDT)

NO

7/29/2019 03_SCCP. 1pdf

45/54




Value

messages can be sent tothe mentioned SP.

15 UDT_DENIED YES, NO

Defines when the sendingof Unit Data (UDT)messages to the mentionedSP is denied. Theparameter value is readfrom the parameter set ofthe SP that is called.

NO

16 SEG_X_THRES 1.. 272

The local segmentationthreshold value is X forconnectionless messages.The parameter value

defines the length of thedata part in theconnectionless messagesthat are sent to thenetwork. The X value candefine segmentation on, ifthe value is smaller than Y,depending on the localimplementation. (Thisfeature is not yet in use.)This parameter typicallyhas the same value asparameterSEG_Y_THRES.

272

17 SEG_Y_THRES 67.. 272

Threshold value Y for thesegmentation of theconnectionless messages.The value can be used toadjust the length of datapart in the connectionlessmessages that are sent tothe network. Value Ymainly controls thesegmentation. Thisparameter typically has thesame value as parameterSEG_X_THRES.

272

18 TCAP_LOAD_SHARING_USED

YES, NO

Defines whether loadsharing is used on TCAPmessages. The loadsharing applies only tomessages that start a

NO

7/29/2019 03_SCCP. 1pdf

46/54




Value

TCAP message. Loadsharing means that the

SCCP connectionlessservice distributes theTCAP messages comingfrom the network to the TCunits in a circularsequence. The parametervalue is read from theparameter set of the SPthat sent the message. It isadvisable to use thisparameter if the trafficcoming in to the CCSU isnot evenly distributed.

19 ADD_DPC_IF_RI_SSN YES, NO

Defines whether asignalling point code has tobe added or has to be leftin the called address whenrouting is done according tothe subsystem number.Adding the code is onlypossible with messagesgoing out into the network.The parameter value isread from the parameterset of the SP that is called.This parameter valuetypically does not need tobe modified.

NO

20 ADD_GT_IF_RI_SSN YES, NO

Defines whether a globaladdress has to be added orhas to be left in the calledaddress when routing isdone according to thesubsystem number. Addingthe address is only possiblewith messages going outinto the network. Theparameter value is readfrom the parameter set ofthe destination SP. Thisparameter value typicallydoes not need to bemodified.

NO

21 ADD_DPC_IF_RI_GT YES, NO

Defines whether asignalling point code has tobe added or has to be left

NO

7/29/2019 03_SCCP. 1pdf

47/54




Value

in the called address whenrouting is done according to

the global address. Addingthe code is only possiblewith messages going outinto the network. Theparameter value is readfrom the parameter set ofthe destination SP. Thisparameter value typicallydoes not need to bemodified.

22 ANALYSE_ROOT_OF_CALLING_GT

YES, NO

Parameter indicates ifglobal title root of calling

address is analyzed or not.

NO

23 ALLOWED_GTI_VALUES 1.. 15

Parameter declares globaltitle indicator values thatuse are allowed in callingaddress.

ITU-T 1-4

ANSI 1-2

ETSI 4

24 SSA_FILTER_TIMER 5.. 3000 (100 ms)

Defines the delay of localbroadcast of subsystemallowed (SSA) stateinformation

10

25 SSP_FILTER_TIMER 5.. 3000 (100 ms)

Defines the delay of localbroadcast of subsystemprohibited (SSP) stateinformation.

10

26 LUDT_USED YES, NO

Defines whether the longunit data (LUDT) messagesare used. Note that remoteSP must support thisfunction.

NO

27 CO_SEGM_USED YES, NO

Usage of connection-oriented segmentation.

SCCP subsystem parameters

7/29/2019 03_SCCP. 1pdf

48/54



The parameter set related to the SCCP subsystems defines the timersmonitoring the various subsystems.

Use the command NFJ to find out which parameter set is being used.The command OCJoutputs the values of the parameters included in the

parameter set. Use the command OCN to modify the parameters.

Table 11 lists the parameter names, possible parameter values, qualityof the given parameter value, and the recommended values, if any, forparameters related to the SCCP subsystems.

Table 11. SCCP subsystem parameters


Value

1 Q714_T_COORD_CHG 30.. 240 (1s)

The time supervision periodspent waiting for a reply(Subsystem-Out-of-Grant,SOG, message) as anacknowledgement to theSubsystem-Out-of-Service-Request (SOR) message.This occurs when thesubsystem is beingremoved from service in acontrolled manner.

90

2 Q714_T_IGN_SST 30.. 300 (1s)

Time supervision duringwhich the SST message isnot answered after

receiving an SOGmessage.

60

3 A_INTERF_APPLIC YES, NO

Defines whether the Ainterface specificationparameter of an SP isapplied for this subsystem.

NO

4 A_INTERF_ERR_IGNORED

YES, NO

Defines whether thesystem ignores ProtocolData Unit Errors (ERR)received from the A

interface.

NO

5 TRANSLATION_SELECTION

SCCP

Defines where the globaladdress is modified if the

7/29/2019 03_SCCP. 1pdf

49/54




Value

SCCP routing address (theresult of the modification) is

its own SP. Routing ismade according to theglobal address. Theparameter value is readfrom the called subsystemparameter set.

6 CALLING_ADDR_MODIFICATION

YES, NO

Defines whether the callingaddress is modified if therouting is based on thesubsystem number whenthe global address hasbeen modified and themessage has beenreceived from the SCCPuser. In the calling address,the global address isreplaced by its own pointcode. The parameter valueis read from the calledsubsystem parameter set.

NO

7 CSCC_ALLOWED_OUT YES, NO

Defines whether thesubsystem is allowed torequest a co-ordinatedstate transition.

NO

8 CSCC_ALLOWED_IN YES, NO

Defines whether therequest on a co-ordinatedstate transition is sent tothe subsystem.

NO

9 TRANSLATE_AT_DPC_IF_DPC_SSN_GT

YES, NO

Defines whether the GlobalTitle (GT) is translated inthe SP. It also defineswhich signalling point codeis included in the calledaddress, or which messageis sent to the SP. Thisparameter only applies to

the messages receivedfrom its own user part. Theparameter value is readfrom the called subsystemparameter set.

YES

10 TC_TRANSACTION_IDS_ 25.. 90%

7/29/2019 03_SCCP. 1pdf

50/54

SCCP Parameter HandlingAppendix



Value

THRESHOLD

Threshold for open TCtransaction. If the thresholdis exceeded a statisticsevent log is set.

75

11 SEND_CALLING_SSN_IF_RI_SSN

YES, NO

Indicates whether thecalling address is modifiedso that it includes only SSNwhen the routing of calledaddress is based on SSN.

NO

12 SEND_CALLING_SPC_SSN_IF_RI_GT

YES, NO

Indicates whether thecalling address is modifiedso that it includes SPC andSSN when the routing ofcalled address is based onGT.

NO

7/29/2019 03_SCCP. 1pdf

51/54

Appendix


Appendix

7/29/2019 03_SCCP. 1pdf

52/54

References


References

7/29/2019 03_SCCP. 1pdf

53/54

Glossary


Glossary

7/29/2019 03_SCCP. 1pdf

54/54

Index

Index

03_SCCP. 1pdf

Documents

Transcript of 03_SCCP. 1pdf