03 - SCCP. 1pdf

Switching Core Network Signalling
Signalling Connection Control Part

Training Document M14/U4
Nokia Siemens Networks
1 (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 are forthwith known as Nokia Siemens Networks training material, are the exclusive property of Nokia Siemens Networks. Nokia Siemens Networks owns the rights to copying, modification, translation, adaptation or derivatives including any improvements or developments. Nokia Siemens Networks has the sole right to copy, distribute, amend, modify, develop, license, sublicense, sell, transfer and assign the Nokia Siemens Networks training material. Individuals can use the Nokia Siemens Networks training material for their own personal selfdevelopment only, those same individuals cannot subsequently pass on that same Intellectual Property to others without the prior written agreement of Nokia Siemens Networks. The Nokia Siemens Networks training material cannot be used outside of an agreed Nokia Siemens Networks training session for development of groups without the prior written agreement of Nokia Siemens Networks. Indemnity The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This document is intended for the use 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 or transmitted in any form or means without the prior written permission of Nokia Siemens Networks. The document has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes customer comments as part of the process of continuous development and improvement of the documentation. The information or statements given in this document concerning the suitability, capacity, or performance of the mentioned hardware or software products are given as is and all liability arising in connection with such hardware or software products shall be defined conclusively in a separate agreement between Nokia Siemens Networks and the customer. However, Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which may not be covered by the document. Nokia Siemens Networks will correct errors in the document as soon as possible. IN NO EVENT 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 MONETARY LOSSES,SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT This document and the product it describes are considered protected by copyrights and other intellectual property rights according to the applicable laws. Wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of Nokia Corporation. Siemens is a registered trademark of Siemens AG. Other product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only. Copyright Nokia Siemens Networks 2008. All rights reserved.
2 (54)
Contents
Contents
1 2 3 3.1 3.2 3.2.1 3.2.2 4 4.1 4.2 4.3 5 6 6.1 6.1.1 6.1.2 6.2 6.2.1 6.2.2 7 8 8.1 Objectives............................................................................................. 5 Introduction.......................................................................................... 6 SCCP Messages................................................................................. 10 Connectionless Service Messages....................................................... 10 Connection-oriented Messages............................................................ 13 Connection Establishment ................................................................... 15 Data Transfer and Connection Release ............................................... 16 SCCP Formats and Codes................................................................. 18 SCCP Message Parameters ................................................................ 21 SCCP Segmentation (Connectionless Service).................................... 29 SCCP Message Exercise ..................................................................... 30 Routing of SCCP Message ................................................................ 32 SCCP Management ............................................................................ 34 SCCP Signalling Point Status Management......................................... 35 Signalling Point Prohibited ................................................................... 35 Signalling Point Allowed ....................................................................... 36 SCCP Subsystem Status Management................................................ 36 Subsystem Allowed.............................................................................. 37 Subsystem Status Test ........................................................................ 38 SCCP Alarms...................................................................................... 40 SCCP Parameter Handling ................................................................ 42 SCCP Signalling Point Parameters ...................................................... 42
3 (54)
Summary of changes
Summary of changes
4 (54)
Objectives
Objectives
On 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 and connectionless Understand SCCP routing functions: SCP, SN, GT Interpret printout of SCCP messages List SCCP parameters in DX200 NE
5 (54)
Introduction
Introduction
The Signalling Connection Control Part (SCCP) is a User Part of the Common Channel Signalling System 7 (CCS7). It provides additional functions to the Message Transfer Part (MTP) to cater for both connectionless as well as connection-oriented network services to transfer non-circuit related signalling information between exchanges in telecommunication networks. The SCCP resides on top of MTP and capable of using services of the MTP 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 providing a 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
6 (54)
Introduction
Table 1. Connectionless services
Two categories of SCCP protocols Basic connectionless service (protocol class 0) The data packets can be delivered out of sequence; there is no control on the transmission path. The SCCP data format 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 of the group.
Connectionoriented 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 all MSUs or PDUs in the group. The format protocol of the Signalling unit is called Dataform1 (DT1). Flow control connection-oriented service (Protocol class 3) Not used in BSS/RAN/CN As the name suggests, a control on the rate of flow of data is maintained by either the remote signalling point or by higher layers. A detection of message loss and sequencing 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 called Dataform2 (DT2).
In GSM, protocol classes 0 and 2 are used most frequently. Figure 1 shows the possible users of SCCP services.
7 (54)
Introduction
MAP/CAP TCAP
TUP/
RANAP/ BSSAP
ISUP
Connectionless Service
Connection-oriented Service
SCCP MTP
Figure 1.
Users of SCCP services
Services provided by the SCCP
Connectionless Services Protocol Class 0 Basic Connectionless Service 1 Sequenced Connectionless Service 2
Connection-oriented Services
3 Basic Connectionoriented Service Flow Control Connectionoriented Service
Figure 2.
SCCP services
8 (54)
Introduction
SCCP functions can be divided into:
SCCP Connection Oriented Control Provides procedures for establishing, supervising, and releasing a temporary connection. It also handles data transfer on this connection. SCCP Connectionless Control Provides procedures for connectionless data transfer of user data. SCCP connectionless control also distributes messages from SCCP Management. SCCP Routing Provides point-to-point routing through GT translation capabilities. SCCP routing relies on MTP for the actual data transfer. SCCP Management Provides congestion control procedures to meet the network performance by re-routing or throttling the traffic.
SCCP Users
N- UNITDATA req. N- UNITDATA ind. SCCP SCCP connectionless control SCCP Connection Oriented Control CR, CC, CREF, RLSD, RLC, DTI, ERR, IT SCCP Routing N- CONNECT req. N-CONNECT ind.
SSA SSP SST SCCP Management
UDT, UDTS
MTP - PAUSE MTP - RESUME MTP - STATUS
MTP Transfer req.
MTP Transfer ind. MTP
Figure 3.
SCCP functions
9 (54)
SCCP Messages
3
3.1
SCCP Messages
Connectionless Service Messages
The connectionless services of protocol class 0 and 1 use six SCCP messages: Unitdata (UDT), Unitdata Service (UDTS), Extended Unitdata (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 a connectionless mode. A UDTS message is used to indicate to the originating SCCP that a UDT sent cannot be delivered to its destination. Exceptionally and subject to protocol interworking considerations, a UDTS might equally be used in response to an XUDT or LUDT message. A UDTS message is sent only when the option field in that UDT 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 XUDTS messages is used to indicate to the originating SCCP that an XUDT cannot be delivered to its destination. Exceptionally and subject to protocol interworking considerations, an XUDTS might equally be used in response to a UDT or LUDT message. An XUDTS message is sent only when the return message on error option in the XUDT (or possibly LUDT) is set. A LUDT is used by the SCCP to send data (along with optional parameters) in a connectionless mode. When MTP capabilities according to Recommendation Q.2210 are present, it allows sending of NSDU sizes up to 3952 octets without segmentation. LUDTS message is used to indicate to the originating SCCP that an LUDT cannot be delivered to its destination. An LUDTS message is sent only when the return message on error option in the LUDT is set. Table 2 summarizes the connectionless service related messages.
10 (54)
SCCP Messages
Table 2. Messa ge UDT UDTS
SCCP connectionless service related messages Service type 0,1 0,1 Unitdata Unitdata Service. Used to indicate to the originating SCCP that a UDT cannot be delivered to its destination. Sent only if the option field in corresponding UDT message is set to return on error Extended Unitdata. Used to send data along with optional parameters. Extended Unitdata Service. Used to indicate to the originating SCCP that an XUDT cannot be delivered to its destination. Sent only if the option field in corresponding XUDT message is set to return on error Long Unitdata. Used to send data along with optional parameters over MTP3b (Q.2210). Up to 3952 octets without segmentation are allowed. Long Unitdata Service. Used to indicate to the originating SCCP that an LUDT cannot be delivered to its destination. Sent only if the option field in corresponding LUDT message is set to return on error Description
XUDT XUDTS
0,1 0,1
LUDT
0,1
LUDTS
0,1
UDT(S), XUDT(S) and LUDT(S) contain the addresses of the receiver and the sender. With the UDT, XUDT and LUDT, these addresses are delivered by the user. When returning a UDT with UDTS, sender and receiver 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 be transported whereas, in the case of UDTS, XUDTS and LUDTS, it is the message which could not be delivered. Additionally, it is indicated in the UDT, XUDT and LUDT whether it belongs to protocol class 0 or 1. If the message must be returned with UDTS, XUDTS and LUDTS, the (X/L)UDTS belongs to the same protocol class as the preceding (X/L)UDT. The segmentation parameter of XUDT and XUDTS tells first, if the message is divided into several segments at all. If yes, there is information about how many segment are still following, which one is the first segment and a reference number, which is common for all segments of one message. The maximum size of one message is here 4 Kbyte.
11 (54)
SCCP Messages
The value of the Hop Counter is decremented on each global title translation. The maximum value is 15. The message must arrive at its destination, 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", "Network failure", "Network congestion" etc.).
SCCP connectionless services positive case

UDT
(Sender,Receiver, Protocol class, User message)
XUDT
(Sender,Receiver, Protocol class, Hop Counter, Segmentation,User message)
Figure 4.
Connectionless SCCP services- positive cases
12 (54)
SCCP Messages
SCCP connectionless services negative case

UDT
(Sender,Receiver, Protocol class, User message)
UDTS
(Sender,Receiver, Cause, User message)
X X
XUDT
(Sender,Receiver, Protocol class, Hop Counter, Segmentation,User message)
XUDTS
(Sender,Receiver, Cause, Hop Counter, Segmentation, User message)
Figure 5. Connectionless SCCP services negative cases
3.2
Connection-oriented Messages
With the connection oriented services of protocol class 2, there are the messages Connect Request (CR), Connect Confirm (CC), Connection Refused (CREF), Data Form 1 (DT1), Inactivity Test (IT), Protocol Data Unit Error (ERR), Released (RLSD), and Release 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 to request the setting up of a signalling connection between the two entities. The required characteristics of the signalling connection are carried in various parameter fields. On reception of a CR message, the called 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 intermediate node 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 establishment phase by connection-oriented protocol class 2 or 3.
13 (54)
SCCP Messages
A DT1 message is sent by either end of a signalling connection to pass transparently 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 used during the data transfer phase in protocol classes 2 and 3. An IT message may be sent periodically by either end of a signalling connection section to check if this signalling connection is active at both ends and to audit the consistency of connection data at both ends. A RLSD message is sent, in the forward or backward direction, to indicate that the sending SCCP wants to release a signalling connection and the associated resources at the sending SCCP have been brought into the disconnect pending condition. It also indicates that the receiving node should release the connection and any other associated resources as well. A RLC message is sent in response to the RLSD message indicating that the RLSD message has been received and the appropriate procedures have been completed. RLSD and RLC messages are used during connection release phase in protocol classes 2 and 3. Tabel 3 summarizes the connectionless service related messages.
Table 3. SCCP connection-oriented service related messages
Messa ge CR CC CREF DT1 DT2 AK
Service type 2,3 2,3 2,3 2 3 3 Connection Request Connection Confirm Connection Refused Data Form 1 Data Form 2
Description
Data Acknowledgement. Used to control the window flow control mechanism selected for the data transfer phase. Expedited Data. Similar to DT2 but it can bypass the flow control mechanism. Expedited Data Acknowledgement. Every ED message must be acknowledged with EA message before another ED is sent.
ED EA
3 3
14 (54)
SCCP Messages
Messa ge IT
Service type 2,3
Description Inactivity Test. Sent periodically to check if the connection is still active at both ands and to audit the consistency of data. Protocol Data Unit Error. Sent on detection of the SCCP protocol error. Released Release Complete Reset Request. Indicates that the SCCP needs to reset the sequence numbers. Reset Confirm.
ERR RLSD RLC RSR RSC
2,3 2,3 2,3 3 3
These connection-oriented messages are used mainly in 3 phases of signalling connection establishment:

Connection establishment phase Data transfer phase Connection release phase
3.2.1
Connection Establishment
The connection establishment procedure consists of the functions required to establish a temporary signalling connection between two users of the SCCP. It is initiated by an SCCP user by invoking the NCONNECT request primitive. The CR message and the CC message are 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 reference number is known, it is a mandatory field for all messages transferred on that connection section. In order to set up an SCCP signalling connection, the initiating side selects a local reference and tells it to its partner by means of the message "Connect Request" (CR). The partner side will, on reception of the CR, select its own local reference and return the message "Connect Confirm" (CC) which contains both local references. Thus, each side knows its own and its partners local reference, and the SCCP transaction is established.
15 (54)
SCCP Messages
In the negative case, however if, for some reason or other, the connection cannot be set up, the message "Connect Refused" (CREF) is returned. It contains the local reference of the initiating side and the reason for the refusal (e.g. "Destination address unknown", "End user congestion", "End user failure" etc.).
Successful SCCP connection establishment

A
Sel LRA CR (Protocol class, LRA, Receiver, poss. User message) CC (LRB, Protocol class, LRA, poss. User message) Sel LRB
LRA
LRB
Unsuccessful SCCP connection establishment

A
Sel LRA CR (Protocol class, LRA, Receiver, poss. User message) CREF (LRA, Cause)
LRA
Figure 6.
SCCP connection establishment
3.2.2
Data Transfer and Connection Release

As long as the SCCP transaction exists, both sides can send user messages over the transaction to the partner. This is done by means of the SCCP message "Data Form 1" (DT1). The message contains the user message and the local reference of the receiving side so that the receiver 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 takes places if the message is longer than 255 bytes.
16 (54)
SCCP Messages
When one of the two partners wants to clear down the SCCP transaction, he sends the SCCP message "Released" (RLSD) to the partner side. This message contains both local references and the cause for the clear down (e.g. "End user originated", "Network failure" etc.). The partner side answers with "Release Complete" (RLC); again, this message contains both local references. Thus, the SCCP connection is cleared down, and both local references are released. By the way: user messages can be delivered already during the transaction set up (in the CR and/or in the CC) and still during the transaction clear down (in the RLSD, but not in the RLC).
SCCP data transfer

A
DT1 (LRB, Segmenting/Reassembling *), User message) LRA DT1 LRB (LRA, Segmenting/Reassembling *), User message) LRA LRB
SCCP connection release

A
RLSD (LRA,LRB, Cause, poss. User message) LRA RLC LRB (LRA,LRB) LRA LRB
Figure 7.
SCCP data transfer and connection release
17 (54)
SCCP Formats and Codes

The SCCP messages are conveyed in the SIF field of MSU of the MTP3/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 variable length fields
DPC OPC SLS

Message type code Mandatory fixed part SCCP Message SIF MTP Routing Label
Mandatory variable part
Optional part
Figure 8.
SCCP message structure: general layout
18 (54)
The SCCP message uses the ASN.1 format. Any messages in this format, depending on the type of message, can contain different parameters. Each parameter has this structure:

Parameter code Parameter length Parameter contents
| 6
Message type code Mandatory parameter A
. . .
Mandatory parameter F Pointer to parameter M
Mandatory Mandatoryfixed fixedpart part
. . .
Pointer to parameter P Pointer to start of optional part Length indicator to parameter M Mandatory parameter M
Mandatory Mandatoryvariable variablepart part
. . .
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 the optional parameters
Optional Optionalpart part
Figure 9.
SCCP message structure
The message type code consists of a one octet field and is mandatory for all messages. It uniquely defines the function and format of each SCCP message. With the mandatory fixed parameters, not only the length but also the sequence is defined (per message type). Therefore, neither identifiers nor length indicators are required. After the message type, the contents of the mandatory fixed parameters ensue in the pre-defined sequence with the pre-defined length. To each mandatory variable parameter, there is a pointer of 1 byte length which indicates how many bytes follow until the begin of the
19 (54)
parameter in question. If, for example, the pointer has the value 1, then the 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 pointers follow immediately after the last mandatory fixed parameter; again, their sequence is pre-arranged (per message type), but the order of the mandatory variable parameters themselves could vary. After the pointers to the mandatory variable parameters, the pointer to the optional part ensues. This pointer is present whenever the message type allows the presence of optional parameters. With message types where no optional parameters can exist (e.g. UDT), the pointer to the optional part is not included either. On the other hand, there are message types, which have optional but no mandatory variable parameters (e.g. CC). With these messages, the mandatory variable section consists of the pointer to the optional part alone. If a message type allows the presence of optional parameters but a particular 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. If optional parameters are present, the pointer to the optional part must have at least the value 1 (since the optional part cannot begin earlier but in the next byte). The message section consisting of the mandatory fixed parameters, the pointers to the mandatory variable parameters and the pointer to the optional part is distinguished by a fixed length and order of its components. As soon as the message type is identified, each mandatory fixed parameter and each mandatory variable parameter can be accessed by a simple method, and even the begin of the optional pert can 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 parameter contents 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 of contents as the length indicator says. The length indicator is included even if the length is fixed. If optional parameters are present, after the last parameter (i.e. where the next identifier is to be expected) the end of the optional part is marked. The mark is the byte 0000 0000 = H'00. Thus, no parameter with the identifier H'00 can exist; rather, H'00 in the position of a parameter identifier marks the end of the optional part and thus the end of the SCCP message as a whole.
20 (54)
4.1
SCCP Message Parameters

Table X shows different SCCP message parameters. Detailed information about all parameters can be found in ITU-T recommendation Q.713.
Table 4. SCCP message parameters
CREF M RLSD M M O RLC M M M M M M O O O O O O M M M M M M M M M M M M M DT1 M UDT UDTS XUDT XUDT S LUDT LUDT S
Parameter Name Destination Local Reference Source Local Reference Called Party Address Calling Party Address Protocol Classes (0 to 3) Segmenting/ Reassembling Segmentation Credit Error Cause Data Hop counter Importance Long Data Refusal cause Release cause Return cause
Code 01 02 03 04 05 06 10 09 0D 0F 11 12 13 0E 0A 0B
CR
CC M
M M O M
M O
O O O
M M
M M O M O M M O M
M M M M M
As an example we take a look at the UDT message. The UDT message contains three pointers and the parameters indicated in Table 5. This Unitdata message type results in the format shown in Figure 10.
21 (54)
Table 5.
Message type: Unitdata
Parameter Message type Protocol class Called party address Calling party address Data
a)
Type Mandatory fixed part Mandatory fixed part Mandatory variable part Mandatory variable part Mandatory variable part
Length (octets) 1 1 3 minimum 2 minimum 2-X

a)
Value 09 0 or 1
Due to the ongoing studies on the SCCP called and calling party address, the maximum length of this parameter needs further study. Note that the transfer of up to 255 octets of user data is allowed when the SCCP called and calling party address do not include global title.
MTP message
F CK
SIF
SIO
LI
F I B
FSN
B I B
BSN F
First bit transmitted
SCCP message
User Data
Pointer to data
Protocol class
Message type H09 UDT
Routing Label
1000 0011 NA0 SCCP
8n
32
[bit]
User data
L e n g t h
Calling party address
L e n g t h
Called party address
L e n g t h
DataCgPA CdPA Ptr. Ptr. Ptr
Figure 10.
UDT message structure
22 (54)
The protocol class parameter field is a one-octet parameter field and is structured as follows:
Bits 1-4 indicating protocol class. It was coded as follows: Bits 4321 0000 0001 0010 0011 Class 0 Class 1 Class 2 Class 3
Bits 5-8 are used to specify message handling (controlled by VM7FIL) as follows: Bits 8765 0000 1000 No special options Return message on error
When bits 1-4 are coded to indicate a connection-oriented protocol class (class 2, 3), bits 5-8 are spare. The called/ calling party address is a variable length parameter. Its structure is shown in Figure 11. It consists of the address indicator and the address. The address indicator shows the type of address information contained in the address field. The address consists of one or any combination of the following elements:

Signalling Point Code (SPC) Subsystem Number (SSN) Global title Point code indicator 1 indicates that the address contains a signalling point code SSN indicator 1 indicates that the address contains a subsystem number
The encoding of the address indicator is as follow: Bit 1 Bit 2
23 (54)
8 Octet 1 Octet 2
Reservef Routing or national indicator use
Global title indicator
Point SSN code Address Indicator indicator indicator

LSB
SPC
Octet 3 . . . 0 0 MSB
Subsystem Number Translation Type (TT) Numbering Plan (NP) Spare O/E*) Encoding Scheme
Nature of Address (NA) 2. GT-Digit 4. GT-Digit 1. GT-Digit 3. GT-Digit
Octet n
*) With Typ 1 : Odd-Even-Indicator With Typ 4: Spare (0)
Figure 11.
Called/Calling party address
Bit 3-6 Bit 7
Global Title Indicator (GTI) GTI is encoded as in Table 6: Routing indicator 1 indicates routing on SSN. Routing should be based on the destination point code in the MTP routing label and the subsystem number information in the called party address 0 indicates routing on GT. Routing should be based on the global title in the called party address.
Bit 8
Reserved for national use and is always set to zero on an international network.
24 (54)
Table 6.
Global title indicator coding
Bits
6543 0000 0001 0010 0011 0100
Meaning No global title included Global title includes nature of address indicator only Global title includes translation type only Global title includes translation type, numbering plan and encoding scheme Global title includes translation type, numbering plan, encoding scheme and nature of address indicator
0101 to 0111 1000 to 1110 1111 Reserved for extension. Spare national Spare international
The Subsystem Number (SSN) identifies an SCCP user function. It consists of one octet codes as shown in Table 7.
Table 7. Subsystem number coding
Bits
87654321 00000000 00000001 00000010 00000011 00000100 00000101 00000110 00000111
Meaning SSN not known/not used SCCP management Reserved for ITU-T allocation ISDN user part OMAP (Operation, Maintenance and Administration Part) MAP (Mobile Application Part) HLR (Home Location Register) VLR (Visitor Location Register)
25 (54)
Bits
87654321 00001000 00001001 00001010 00001011 00001100 00001101 00001110 00001111 To 00011111
Meaning MSC (Mobile Switching Centre) EIC (Equipment Identifier Centre) AUC (Authentication Centre) ISDN supplementary services Reserved for international use Broadband ISDN edge-to-edge applications TC test responder Reserved for international use
00100000 To 11111110
Reserved for national networks
11111111
Reserved for expansion of national and international 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. It consists of translation type, numbering plan, encoding scheme, nature of address indicator and global title address information. Figure 12-15 illustrates all fields and the corresponding coding.
26 (54)
Bits 87654321 00000000 00000001 00111111 01000000 01111111 10000000 11111110 11111111
Decimal value 0 1 63 64 127 128 254 255
Translation type Unknown International services
Spare
National network specific
Reserved for expansion
Figure 12.
Translation type
Bits 7654321 0000000 0000001 0000010 0000011 0000100 0000101 1111111
Nature of address Unknown Subscriber number Reserved for national use National significant number International number Spare
Figure 13.
Nature of address
27 (54)
Bits 8765 0000 0001
Numbering plan Unknown ISDN/telephony numbering plan (Recommendations E.163 and E.164)
0010 0011 0100 0101 0110 0111 1000 1101 1110 1111
Generic numbering plan Data numbering plan (Recommendation X.121) Telex numbering plan (Recommendation F.69) Maritime mobile numbering plan (Recommendations E.210, E.211) Land mobile numbering plan (Recommendation E.212) ISDN/mobile numbering plan (Recommendation E.214) Spare
Private network or network-specific numbering plan Reserved
Figure 14.
Numbering plan
Bits 4321 0000 0001 0010 0011 0100 1110 1111
Encoding scheme Unknown BCD, Odd number of digits BCD, Even number of digits National specific Spare
Reserved
Figure 15.
Encoding schemes
28 (54)
4.2
SCCP Segmentation (Connectionless Service)

"SCCP connectionless segmentation" is a service provided transparently to the SCCP user, which allows connectionless transfer of a block of user data larger than can be contained in a single (X)UDT message. The SCCP provides this service by segmenting a large block of user data into smaller blocks (called segments), transmitting the segments as user data in XUDT messages (the use of LUDT messages for this purpose is for further study), and reassembling the segments in the destination node before passing the original block of user data to the (remote) destination SCCP user. At the destination SCCP, this reassembling process is called reassembly.
8 F
7 C
5 Spare
1 Octet 1 Octet 2
Remaining Segment
Segmentation Local Reference
Octet 3 Octet 4
Figure 16.
Segmentation field coding
When SCCP segments data an optional field is inserted into XUDT message 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 by the SCCP user (C=1 Class 1, C=0 Class 0 selected). Remaining Segment field indicates the number of remaining segments. The values 0000 to 1111 are possible, the value 0000 indicates the last segment.
29 (54)
4.3
SCCP Message Exercise

Decode the following UDT message, according to the SCCP message structure:
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 =
30 (54)
Figure 17.
SCCP decoding from protocol analyzer
31 (54)
Routing of SCCP Message

Figure 18 shows different routing techniques for SCCP messages.
Application parts
BSSAP/ RANAP
MAP
INAP
Yes
Is DPC contained in the message?
No (there is a GT)
SCCP
Routing on label (do nothing)
Routing on GT (GT analysis)
MTP
Message handling
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 routes the message based on the route indicator. In other words, pass the message to the route indicated in DPC.
32 (54)
If the route indicator says SSN, the message is routed to the concerned user part (refer to the table below). The route indicator is GT. Routing on GT implies re-analysing the called party address, and comparing it with internal GT analysis tables to route the call.
SCCP subsystem number of user parts SSN 08 07 06 09 FE 8E
Table 8. User Part MAP M MAP V MAP H MAP E BSSAP RANAP
33 (54)
SCCP Management
SCCP Management
The purpose of the SCCP management is to provide procedures to maintain network performance by rerouting or throttling traffic in the event of failure in the network. SCCP management is organized in two sub-functions: signalling point status management and subsystem status management. SCCP management messages are defined to be transferred using the SCCP connectionless service. The list of SCCP management messages is given below.
Table 9. Message SSA SOG SOR SSP SST SSC Subsystem Allowed Subsystem Out Of Service Grant Subsystem Out Of Service Request Subsystem Prohibited Subsystem Status Test Subsystem Congested SCCP management related messages Description
SCCP management utilizes the concept of a concerned subsystem or signalling point. If a subsystem/signalling point is marked as concerned in the local SCCP it means that it needs to be informed about any state changes in the local SCCP or subsystems. Two methods are employed to inform remote SCCP when such changes occur: to those SCCP/subsystems marked as concerned a broadcast method used and a response method used in other cases.
34 (54)
SCCP Management
6.1 SCCP Signalling Point Status Management

SCCP signalling point status management update translations and states based on the information of the network failure, recovery or congestion provided by MTP-PAUSE, MTP-RESUME or MTP-STATUS primitives. This allows alternative routing to backup signalling points and/or backup subsystems.
6.1.1 Signalling Point Prohibited

When SCCP management receives an MTP-PAUSE indication primitive relating to a destination that becomes inaccessible, or an MTP-STATUS indication primitive relating to an SCCP that becomes unavailable, SCCP management performs the following actions. 1. 2. Informs the translation function to update the translation tables. In the case where the SCCP has received an MTP-PAUSE indication primitive, SCCP management marks as "prohibited" the status of the remote signalling point, the remote SCCP and each subsystem at the remote signalling point.
In the case where the SCCP has received an MTP-STATUS indication primitive relating to an unavailable SCCP, the SCCP marks the status of the SCCP and each SSN for the relevant destination to "prohibited" and initiates a subsystem status test with SSN = 1. If the cause in the MTP-STATUS indication primitive indicates "unequipped user", then no subsystem status test is initiated. 3. Discontinues all subsystem status tests (including SSN = 1) if an MTP-PAUSE or MTP-STATUS indication primitive is received with a cause of "unequipped SCCP". The SCCP discontinues all subsystem status tests, except for SSN = 1, if an MTP-STATUS indication primitive is received with a cause of either "unknown" or "inaccessible". Initiates a local broadcast of "User-out-of-service" information for each subsystem at that destination. Initiates a local broadcast of "signalling point inaccessible" information for that destination if an MTP-PAUSE indication primitive is received. Initiates a local broadcast of "remote SCCP unavailable" if either an MTP-PAUSE indication primitive or an MTP-STATUS indication primitive is received.
4. 5.
6.
35 (54)
SCCP Management
6.1.2 Signalling Point Allowed

When SCCP management receives an MTP-RESUME indication primitive relating to a destination that becomes accessible, or when it receives a subsystem allowed message relating to SSN = 1 at a remote destination which had been considered "prohibited", or when timer T(stat info) expires, SCCP management performs the following actions: 1. 2. 3. 4. Sets the congestion state of that signalling point if an MTP-RESUME indication primitive is received. Instructs the translation function to update the translation tables. Marks as "allowed" the status of that destination, and the SCCP, if an MTP-RESUME indication primitive is received. Marks as "allowed" the status of the SCCP if a subsystem allowed message is received for SSN = 1 or if timer T(stat info) expires. The subsystem status test for SSN = 1, if running, is stopped. Marks as "allowed" the status of remote subsystems. As a national network provider option, the subsystem status can be marked as "prohibited" for a list of selected subsystems. Initiates a local broadcast of "signalling point accessible" information for that destination if a MTP-RESUME indication primitive is received. Initiates a local broadcast of "remote SCCP accessible" if either an MTP-RESUME indication primitive or a subsystem status allowed message is received for SSN = 1 or if timer T(stat info) expires. Initiates a local broadcast of "User-in-service" information for a subsystem associated with the MTP-RESUME indication primitive.
5.
6.
7.
8.
6.2 SCCP Subsystem Status Management

Subsystem status management updates the subsystem status based on the information of failure, withdrawal, and recovery of subsystems. This allows alternative routing to backup subsystems, if appropriate. Concerned local users are informed of the status changes of other backup subsystems. Subsystem status management procedures are also used to convey the status of the SCCP as a whole. SCCP management messages SSP/SSA are used to convey the status of SCCP subsystems or SCCP itself (SSA=1). A subsystem prohibited message with SSN = 1 is not allowed.
36 (54)
SCCP Management
If SCCP routing control receives a message, whether originated locally or not, for a prohibited local system, then SCCP routing control invokes subsystem-prohibited control. A Subsystem-Prohibited message is sent to the signalling point identified by the OPC in the MTP-TRANSFER indication primitive if the originating subsystem is not local. If the originating subsystem is local, any action taken is implementation dependent.
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-Prohibited message about 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; instructs the translation function to update the translation tables; marks as "prohibited" the status of that subsystem; initiates a local broadcast of "User-out-of-service" information for the prohibited subsystem; initiates the subsystem status test procedure if the prohibited subsystem is not local; initiates a broadcast of Subsystem-Prohibited messages to concerned signalling points; cancels "ignore subsystem status test" and the associated timer if they are in progress and if the newly prohibited subsystem resides at the local node.
then SCCP management does the following: 1. 2. 3. 4. 5. 6.
6.2.1 Subsystem Allowed

Under one of the following conditions:

SCCP management receives a Subsystem-Allowed message about a subsystem other than SSN = 1, marked prohibited; or an N-STATE request primitive with "User-in-Service" information is invoked by a subsystem marked prohibited; Instructs the translation function to update the translation tables.
then SCCP management does the following: 1.
37 (54)
SCCP Management
2. 3. 4. 5.
Marks as "allowed" the status of that subsystem. Initiates as a local broadcast of "User-in-service" information for the allowed subsystem. Discontinues the subsystem status test relating to that subsystem if such a test was in progress. Initiates a broadcast of Subsystem-Allowed messages to concerned signalling points.
6.2.2 Subsystem Status Test

The subsystem status test procedure is an audit procedure to verify the status of a SCCP or subsystem marked as prohibited. A subsystem status test is initiated when a Subsystem-Prohibited message is received. For a list of selected subsystems, the subsystem status test may also be initiated on receipt of an MTP-RESUME indication primitive, a subsystem allowed message with SSN = 1 or the time-out of timer T(stat. info) A subsystem status test associated with a prohibited subsystem is commenced by starting a timer (stat. info) and marking a test in progress. No further actions are taken until the timer expires. Upon expiration of the timer, a Subsystem-Status-Test message is sent to SCCP management at the node of the prohibited subsystem and the timer is reset. The cycle continues until the test is terminated by another SCCP management function at that node. Termination of the test causes the timer and the "test progress mark" to be cancelled. A subsystem status test for SSN = 1 is initiated when an MTP-STATUS indication 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 an SSA(SSN = 1) from the restarting node or it should receive an MTP-STATUS indication primitive stating User Part Unavailable. In the case where the SST receiving node has the User Part availability control and its SCCP has not yet recovered, MTP sends a User Part Unavailable (UPU) message to the SST sending node. If neither a SSA(SSN = 1) nor a MTP-STATUS indication primitive (User Part Unavailable) is received by the SST sending SCCP during the duration of the T(stat info) timer, then the node should assume that the previously unavailable (SCCP) has recovered. (This ensures backward compatibility with previous versions of the Recommendation.) If the MTP-STATUS indication primitive stating User Part Unavailable is received before timer T(stat info) expires, then an SST(SSN = 1) is sent to the unavailable node when timer T(stat info) expires. A subsystem status test associated with an inaccessible SCCP is done in the same
38 (54)
SCCP Management
way as for the one associated with a prohibited subsystem, the only difference being that it refers to SSN = 1.
Actions at the receiving node
When SCCP management receives a Subsystem-Status-Test message and there is no "ignore subsystem status test" in progress, it checks the status of the named subsystem. If the subsystem is allowed, then a Subsystem-Allowed message is sent to the SCCP management at the node conducting the test. If the subsystem is prohibited, no reply is sent. In the case where the Subsystem-Status-Test message is testing the status of SCCP management (SSN = 1), if the SCCP at the destination node is functioning, then a Subsystem Allowed message with SSN = 1 is sent to SCCP management at the node conducting the test. If the SCCP is not functioning, then the MTP cannot deliver the SST message to the SCCP. A UPU message is returned to the SST initiating node by the MTP. As soon as its SCCP has recovered, the restarting SCCP should broadcast a Subsystem Allowed message for SSN = 1 to all concerned nodes. The restarting SCCP should set the status to "allowed" for the SCCP and all subsystems of remote signalling points that it considers available, based on the MTP information at the node.
39 (54)
SCCP Alarms
SCCP Alarms
There 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's destination 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 incorrect information or global title modification cannot be done to the existing global title number. The alarm may have an effect to the traffic capacity of the system. A message that contains the global title in question will not 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 cannot be transmitted to the subsystem in question. The fault may affect the traffic capacity. 2246 SCCP routing failure
The SCCP has failed in routing a message received from the user part of the SCCP. The alarm is caused by erroneous configuration of the system. The fault may affect the traffic capacity of the system.
40 (54)
SCCP Alarms
2254
SCCP not defined for the network
The SCCP has received a message addressed to a signalling point or signalling network for which the SCCP has not been defined. The system might be incorrectly configured and the error can affect the traffic capacity of the system.
41 (54)
SCCP Parameter Handling
8.1 SCCP Signalling Point Parameters

The parameter set related to the SCCP signalling point defines the parameters for certain timers that are used in monitoring the signalling connections, and for managing the subsystems (ITU-T Rec. Q.714). The parameter set also defines some of the signalling network functions. Use the command OCI to find out which parameter set the selected signalling point is using. Commands in the command group OC can be used to handle the SCCP signalling point parameters. Table 10 lists the parameter names, all possible parameter values, the quality of the value, and the recommended values, if any, that are related to the SCCP signalling point.
Table 10. Number
1
SCCP signalling point parameters Parameter name/meaning

Q714_T_CONN_EST Timer for connection setup. Defines the time for waiting for a response to the connection request message. Usually, you do not need to change the parameter value.
Value
30.. 240 (1s) 90
Q714_T_IAS Send inactivity timer. When the timer expires, an inactivity test-message (IT) is sent to the connection
60.. 600 (1s) 90
42 (54)
Number
Parameter name/meaning
section. Note that this timer should normally be at least two times smaller than Q714_T_IAR at the other end.
Value
Q714_T_IAR Receive inactivity timer. Connection is released if no messages have been received when the timer expires. Note that this timer should normally be at least two times greater than Q714_T_IAS at the other end.
150.. 1260 (1s) 270
Q714_T_REL If the first connection release message (Released, RLSD) produces no acknowledgement (release message or Release Completed, RLC), the release message is repeated and a new time supervision is started (Q714_T_REP_REL).
100.. 200 (100ms) 150
Q714_T_INT Control parameter for connection release time. The release message is being repeated during that time. After time-out, the resources allocated for the connection are frozen for a certain time and an alarm is set.
45.. 90 (1s) 60
Q714_T_RES Time supervision for resetting the signalling connectiona service class 3 timer that is not is use.
10.. 20 (1s) 15
Q714_T_REP_REL If a repeated connection release message (Released, RLSD) produces no acknowledgement (release
40.. 200 (100ms) 100
43 (54)
Number
message or Release Completed, RLC) during the set time supervision period, the release message is repeated and a new time supervision is started (Q714_T_REP_REL).
Value
Q714_T_STAT_1
ST
50.. 600 (100ms) 600
Time supervision, after which the first Subsystem Status Test (SST) message is sent out. 9 Q714_T_STAT_INC Time that is added to the repeat interval of the SST message after each repeat event unless the message Subsystem Allowed (SSA) is not received. 10 Q714_T_STAT_MAX The maximum time for the repeat interval of the SST message. 11 A_INTERFACE Defines whether the system uses the A interface specification in the direction of the SP. 12 WHITE_BOOK_MGMT_US ED Defines whether the system uses SCCP management procedures for the ITU-T, Q711-Q714, 1993/3 (White Book) in the direction of the SP. 13 SS_MANAGEMENT_USE D Defines whether the subsystem status management functions are used. 14 XUDT_USED Defines whether Extended Unit Data (XUDT)
150.. 3000 (100ms) 300
600.. 12000 (100ms) 600
YES, NO
YES, NO NO
YES, NO YES
YES, NO NO
44 (54)
Number
messages can be sent to the mentioned SP.
Value
15
UDT_DENIED Defines when the sending of Unit Data (UDT) messages to the mentioned SP is denied. The parameter value is read from the parameter set of the SP that is called.
YES, NO NO
16
SEG_X_THRES The local segmentation threshold value is X for connectionless messages. The parameter value defines the length of the data part in the connectionless messages that are sent to the network. The X value can define segmentation on, if the value is smaller than Y, depending on the local implementation. (This feature is not yet in use.) This parameter typically has the same value as parameter SEG_Y_THRES.
1.. 272 272
17
SEG_Y_THRES Threshold value Y for the segmentation of the connectionless messages. The value can be used to adjust the length of data part in the connectionless messages that are sent to the network. Value Y mainly controls the segmentation. This parameter typically has the same value as parameter SEG_X_THRES.
67.. 272 272
18
TCAP_LOAD_SHARING_ USED Defines whether load sharing is used on TCAP messages. The load sharing applies only to messages that start a
YES, NO NO
45 (54)
Number
TCAP message. Load sharing means that the SCCP connectionless service distributes the TCAP messages coming from the network to the TC units in a circular sequence. The parameter value is read from the parameter set of the SP that sent the message. It is advisable to use this parameter if the traffic coming in to the CCSU is not evenly distributed.
Value
19
ADD_DPC_IF_RI_SSN Defines whether a signalling point code has to be added or has to be left in the called address when routing is done according to the subsystem number. Adding the code is only possible with messages going out into the network. The parameter value is read from the parameter set of the SP that is called. This parameter value typically does not need to be modified.
YES, NO NO
20
ADD_GT_IF_RI_SSN Defines whether a global address has to be added or has to be left in the called address when routing is done according to the subsystem number. Adding the address is only possible with messages going out into the network. The parameter value is read from the parameter set of the destination SP. This parameter value typically does not need to be modified.
YES, NO NO
21
ADD_DPC_IF_RI_GT Defines whether a signalling point code has to be added or has to be left
YES, NO NO
46 (54)
Number
in the called address when routing is done according to the global address. Adding the code is only possible with messages going out into the network. The parameter value is read from the parameter set of the destination SP. This parameter value typically does not need to be modified.
Value
22
ANALYSE_ROOT_OF_CA LLING_GT Parameter indicates if global title root of calling address is analyzed or not.
YES, NO
NO
23
ALLOWED_GTI_VALUES Parameter declares global title indicator values that use are allowed in calling address.
1.. 15 ITU-T 1-4 ANSI 1-2 ETSI 4 5.. 3000 (100 ms) 10
24
SSA_FILTER_TIMER Defines the delay of local broadcast of subsystem allowed (SSA) state information
25
SSP_FILTER_TIMER Defines the delay of local broadcast of subsystem prohibited (SSP) state information.
5.. 3000 (100 ms) 10
26
LUDT_USED Defines whether the long unit data (LUDT) messages are used. Note that remote SP must support this function.
YES, NO NO
27
CO_SEGM_USED Usage of connectionoriented segmentation.
YES, NO
SCCP subsystem parameters
47 (54)
The parameter set related to the SCCP subsystems defines the timers monitoring the various subsystems. Use the command NFJ to find out which parameter set is being used. The command OCJ outputs 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, quality of the given parameter value, and the recommended values, if any, for parameters related to the SCCP subsystems.
Table 11. Number
1
SCCP subsystem parameters Parameter name/meaning

Q714_T_COORD_CHG The time supervision period spent waiting for a reply (Subsystem-Out-of-Grant, SOG, message) as an acknowledgement to the Subsystem-Out-of-ServiceRequest (SOR) message. This occurs when the subsystem is being removed from service in a controlled manner.
Value
30.. 240 (1s) 90
Q714_T_IGN_SST Time supervision during which the SST message is not answered after receiving an SOG message.
30.. 300 (1s) 60
A_INTERF_APPLIC Defines whether the A interface specification parameter of an SP is applied for this subsystem.
YES, NO NO
A_INTERF_ERR_IGNORE D Defines whether the system ignores Protocol Data Unit Errors (ERR) received from the A interface.
YES, NO NO
TRANSLATION_SELECTI ON Defines where the global address is modified if the
SCCP
48 (54)
Number
SCCP routing address (the result of the modification) is its own SP. Routing is made according to the global address. The parameter value is read from the called subsystem parameter set.
Value
CALLING_ADDR_MODIFI CATION Defines whether the calling address is modified if the routing is based on the subsystem number when the global address has been modified and the message has been received from the SCCP user. In the calling address, the global address is replaced by its own point code. The parameter value is read from the called subsystem parameter set.
YES, NO NO
CSCC_ALLOWED_OUT Defines whether the subsystem is allowed to request a co-ordinated state transition.
YES, NO NO
CSCC_ALLOWED_IN Defines whether the request on a co-ordinated state transition is sent to the subsystem.
YES, NO NO
TRANSLATE_AT_DPC_IF _DPC_SSN_GT Defines whether the Global Title (GT) is translated in the SP. It also defines which signalling point code is included in the called address, or which message is sent to the SP. This parameter only applies to the messages received from its own user part. The parameter value is read from the called subsystem parameter set.
YES, NO YES
10
TC_TRANSACTION_IDS_
25.. 90%
49 (54)
SCCP Parameter HandlingAppendix
Number
THRESHOLD Threshold for open TC transaction. If the threshold is exceeded a statistics event log is set.
Value
75
11
SEND_CALLING_SSN_IF_ RI_SSN Indicates whether the calling address is modified so that it includes only SSN when the routing of called address is based on SSN.
YES, NO
NO
12
SEND_CALLING_SPC_SS N_IF_RI_GT Indicates whether the calling address is modified so that it includes SPC and SSN when the routing of called address is based on GT.
YES, NO
NO
50 (54)
Appendix
Appendix
51 (54)
References
References
52 (54)
Glossary
Glossary
53 (54)
Index
Index
54 (54)

03 - SCCP. 1pdf

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

03 - SCCP. 1pdf

Uploaded by

Copyright:

Available Formats

Switching Core Network Signalling

Signalling Connection Control Part

Nokia Siemens Networks

Nokia Siemens Networks

Nokia Siemens Networks

Nokia Siemens Networks

Nokia Siemens Networks

Connectionless service Connection-oriented service

Nokia Siemens Networks

Table 1. Connectionless services

Nokia Siemens Networks

Users of SCCP services

Services provided by the SCCP

3 Basic Connectionoriented Service Flow Control Connectionoriented Service

Nokia Siemens Networks

SCCP functions can be divided into:

SSA SSP SST SCCP Management

MTP - PAUSE MTP - RESUME MTP - STATUS

MTP Transfer req.

MTP Transfer ind. MTP

Nokia Siemens Networks

Nokia Siemens Networks

Table 2. Messa ge UDT UDTS

Nokia Siemens Networks

SCCP connectionless services positive case

Connectionless SCCP services- positive cases

Nokia Siemens Networks

SCCP connectionless services negative case

Figure 5. Connectionless SCCP services negative cases

Nokia Siemens Networks

Messa ge CR CC CREF DT1 DT2 AK

Nokia Siemens Networks

Service type 2,3

ERR RLSD RLC RSR RSC

2,3 2,3 2,3 3 3

Connection establishment phase Data transfer phase Connection release phase

Nokia Siemens Networks

Successful SCCP connection establishment

Unsuccessful SCCP connection establishment

SCCP connection establishment

Data Transfer and Connection Release

Nokia Siemens Networks

SCCP data transfer

SCCP connection release

SCCP data transfer and connection release

Nokia Siemens Networks

SCCP Formats and Codes

SCCP Formats and Codes

DPC OPC SLS

Mandatory variable part

SCCP message structure: general layout

Nokia Siemens Networks

SCCP Formats and Codes

Parameter code Parameter length Parameter contents

Message type code Mandatory parameter A

Mandatory Mandatoryfixed fixedpart part

Mandatory Mandatoryvariable variablepart part

Optional Optionalpart part

SCCP message structure

Nokia Siemens Networks

SCCP Formats and Codes

Nokia Siemens Networks