home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Standards
/
CD2.mdf
/
ccitt
/
1992
/
q
/
q713.asc
< prev
next >
Wrap
Text File
|
1991-12-31
|
89KB
|
4,402 lines
Recommendation Q.713
SCCP FORMATS AND CODES
1 General
The Signalling Connection Control Part (SCCP) messages are carried on the
signalling data link by means of Signal Units the format of which is described in
Recommendation Q.703, S 2.2.
The Service Information Octet format and coding is described in
Recommendation Q.704, S 14.2. The Service Indicator is coded 0011 for the SCCP.
The Signalling Information Field (SIF) of each Message Signal Unit
containing an SCCP message consists of an integral number of octets.
A message consists of the following parts (see Figure 1/Q.713):
- the routing label;
- the message type code;
- the mandatory fixed part;
- the mandatory variable part;
- the optional part, which may contain fixed length and variable length
fields.
The description of the various parts is contained in the following
sections. SCCP Management messages and codes are provided in S 5 of this
Recommendation.
1.1 Routing label
The standard routing label specified in Recommendation Q.704, S 2.2 is
used. The rules for the generation of the signalling link selection (SLS) code
are described in Recommendation Q.711, S 2.2.1.
Routing label
Message type code
Mandatory fixed part
Mandatory variable part
Optional part
FIGURE 1/Q.713
General layout
Fascicle VI.7 - Rec. Q.713 PAGE1
1.2 Message type code
The message type code consists of a one octet field, and is mandatory for
all messages. The message type code uniquely defines the function and format of
each SCCP message. The allocation of message type codes, with reference to the
appropriate descriptive section of this Recommendation is summarized in Table
1/Q.713. Table 1/Q.713 also contains an indication of the applicability of the
various message types to the relevant classes of protocol.
1.3 Formatting principles
Each message consists of a number of parameters listed and described in S
3. Each parameter has a "name" which is coded as a single octet (see S 3). The
length of a parameter may be fixed or variable, and a "length indicator" of one
octet for each parameter may be included as described below.
The detailed format is uniquely defined for each message type as described
in S 4.
A general SCCP message format is shown in Figure 2/Q.713.
1.4 Mandatory fixed part
Those parameters that are mandatory and of fixed length for a particular
message type will be contained in the "mandatory fixed part". The position,
length and order of the parameters is uniquely defined by the message type. Thus
the names of the parameters and the length indicators are not included in the
message.
1.5 Mandatory variable part
Mandatory parameters of variable length will be included in the mandatory
variable part. The name of each parameter and the order in which the pointers are
sent is implicit in the message type. Parameter names are, therefore, not
included in the message. A pointer is used to indicate the beginning of each
parameter. Because of this, parameters may be sent in an order different from
that of the pointers. Each pointer is encoded as a single octet. The details of
how pointers are encoded is found in S 2.3. The number of parameters, and thus
the number of pointers is uniquely defined by the message type.
A pointer is also included to indicate the beginning of the optional part.
If the message type indicates that no optional part is allowed, then this pointer
will not be present. If the message type indicates that an optional part is
possible, but there is no optional part included in this particular message, then
a pointer field containing all zeros will be used.
All the pointers are sent consecutively at the beginning of the mandatory
variable part. Each parameter contains the parameter length indicator followed by
the contents of the parameter.
Figure 2/Q.713 - CCITT 73070
1.6 Optional part
The optional part consists of parameters that may or may not occur in any
particular message type. Both fixed length and variable length parameters may be
included. Optional parameters may be transmitted in any order1). Each optional
parameter will include the parameter name (one octet) and the length indicator
(one octet) followed by the parameter contents.
1.7 End of optional parameters octet
After all optional parameters have been sent, an end of optional
parameters octet containing all zeroes will be transmitted. This octet is only
included if optional parameters are present in the message.
1.8 Order of transmission
Since all the parameters consist of an integral number of octets, the
formats are presented as a stack of octets. The first octet transmitted is the
one shown at the top of the stack and the last is the one at the bottom (see
Figure 2/Q.713).
Within each octet, the bits are transmitted with the least significant bit
first.
1.9 Coding of spare bits
According to the general rules defined in Rec. Q.700, spare bits are coded
0 unless indicated otherwise at the originating nodes. At intermediate nodes,
they are passed transparently. At destination nodes, they need not be examined.
1.10 National message types and parameters
If message type codes and parameter codes are required for national uses,
1) It is for further study if any constraint in the order of transmission will be
introduced.
PAGE30 Fascicle VI.7 - Rec. Q.713
it is suggested that the codes be selected from the highest code downwards, that
is starting at code 11111110. Code 11111111 is reserved for future use.
2 Coding of the general parts
2.1 Coding of the message type
The coding of the message is shown in Table 1/Q.713.
2.2 Coding of the length indicator
The length indicator field is binary coded to indicate the number of
octets in the parameter content field. The length indicator does not include the
parameter name octet or the length indicator octet.
2.3 Coding of the pointers
The pointer value (in binary) gives the number of octets between the
pointer itself (included) and the first octet (not included) of the parameter
associated with that pointer2).
The pointer value all zeros is used to indicate that, in the case of
optional parameters, no optional parameter is present.
3 SCCP parameters
The parameter name codes are given in Table 2/Q.713 with reference to the
subsections in which they are described.
3.1 End of optional parameters
The "end of optional parameters" parameter field consists of a single
octet containing all zeros.
3.2 Destination local reference
The "destination local reference" parameter field is a three-octet field
containing a reference number which, in outgoing messages, has been allocated to
the connection section by the remote node.
The coding "all ones" is reserved, its use is for further study.
TABLE 1/Q.713
SCCP message types
Classes
Message type 0 1 2 3 S Code
CR Connection Request X X 4.2 0000 0001
CC Connection Confirm X X
2) For example, a pointer value of "00000001" indicates that the associated parameter
begins in the octet immediately following the pointer. A pointer value of "00001010"
indicates that nine octets of information exist between the pointer octet and the first
octet of the parameter associated with that pointer.
Fascicle VI.7 - Rec. Q.713 PAGE1
4.3 0000 0010
CREF Connection Refused X X 4.4 0000 0011
RLSD Released X X 4.5 0000 0100
RLC Release Complete X X 4.6 0000 0101
DT1 Data Form 1 X 4.7 0000 0110
DT2 Data Form 2
PAGE30 Fascicle VI.7 - Rec. Q.713
X 4.8 0000 0111
AK Data Acknowledgement X 4.9 0000 1000
UDT Unitdata X X 4.10 0000 1001
UDTS Unitdata Service X X 4.11 0000 1010
ED Expedited Data X 4.12 0000 1011
EA Expedited Data Acknowledgement
Fascicle VI.7 - Rec. Q.713 PAGE1
X 4.13 0000 1100
RSR Reset Request X 4.14 0000 1101
RSC Reset Confirm X 4.15 0000 1110
ERR Protocol Data Unit Error X X 4.16 0000 1111
IT Inactivity Test X X 4.17
PAGE30 Fascicle VI.7 - Rec. Q.713
0001 0000
X Type of message in this protocol class.
TABLE 2/Q.713
SCCP parameter name codes
Parameter name S Parameter
name code
8765 4321
End of optional parameters 3.1 0000 0000
Destination local reference 3.2 0000 0001
Source local reference 3.3 0000 0010
Called party address 3.4 0000 0011
Calling party address 3.5 0000 0100
Protocol class 3.6 0000 0101
Segmenting/reassembling 3.7 0000 0110
Receive sequence number 3.8 0000 0111
Sequencing/segmenting 3.9
Fascicle VI.7 - Rec. Q.713 PAGE1
0000 1000
Credit 3.10 0000 1001
Release cause 3.11 0000 1010
Return cause 3.12 0000 1011
Reset cause 3.13 0000 1100
Error cause 3.14 0000 1101
Refusal cause 3.15 0000 1110
Data 3.16 0000 1111
PAGE30 Fascicle VI.7 - Rec. Q.713
3.3 Source local reference
The "source local reference" parameter field is a three-octet field
containing a reference number which is generated and used by the local node to
identify the connection section.
The coding "all ones" is reserved, its use is for further study.
3.4 Called party address
The "called party address" is a variable length parameter. Its structure
is shown in Figure 3/Q.713.
8 7 6 5 4 3 2 1
Octet Address indicator
1
Octet
2
.
Fascicle VI.7 - Rec. Q.713 PAGE1
. Address
.
Octet
n
FIGURE 3/Q.713
Called/Calling party address
3.4.1 Address indicator
The "address indicator" indicates the type of address information
contained in the address field (see Figure 4/Q.713). The address consists of one
or any combination of the following elements:
- signalling point code;
- global title (for instance, dialled digits);
- subsystem number.
PAGE30 Fascicle VI.7 - Rec. Q.713
8 7 6 5 4 3 2 1
Reserved Rtg Global title SSN Point code
for indicator indicator indicator indicator
national
use
FIGURE 4/Q.713
Address indicator encoding
Fascicle VI.7 - Rec. Q.713 PAGE1
A "1" in bit 1 indicates that the address contains a signalling point
code.
A "1" in bit 2 indicates that the address contains a subsystem number.
Bits 3-6 of the address indicator octet contain the global title
indicator, which is encoded as follows:
Bit 6 5 4
s 3
0 0 0 No global title included
0
0 0 0 Global title includes nature of address indicator
1 only
0 0 1 Global title includes translation type only3)
0
0 0 1 Global title includes translation type, numbering
1 plan and encoding scheme3)
0 1 0 Global title includes translation type, numbering
0 plan, encoding scheme and nature of address indicator
0 1 0 ü
1
to ì spare international
0 1 1 Φ
1
1 0 0 ü
0
to
3) Full E.164 numbering plan address is used in these two cases for Recommendation E.164
based global titles.
PAGE30 Fascicle VI.7 - Rec. Q.713
ì spare national
1 1 1 Φ
0
1 1 1 reserved for extension.
1
When a global title is used in the called party address, it is suggested
that the called party address contain a subsystem number. This serves to simplify
message reformatting following global title translation. The subsystem number
should be encoded "00000000" when the subsystem number is not known, e.g., before
translation.
Bit 7 of the address indicator octet contains routing information
identifying which address element should be used for routing.
A "0" in bit 7 indicates that routing should be based on the global title
in the address.
A "1" in bit 7 indicates that routing should be based on the destination
point code in the MTP routing label and the subsystem number information in the
called party address.
Bit 8 of the address indicator octet is designated for national use.
3.4.2 Address
The various elements, when provided, occur in the order: point code,
subsystem number, global title, as shown in Figure 5/Q.713.
8 7 6 5 4 3 2 1
Signalling point code
Subsystem number
Global title
FIGURE 5/Q.713
Ordering of address elements
3.4.2.1 Signalling point code
The signalling point code, when provided, is represented by two octets.
Bits 7 and 8 in the second octet are set to zero (see Figure 6/Q.713).
8 7 6 5 4 3 2 1
Fascicle VI.7 - Rec. Q.713 PAGE1
0 0
FIGURE 6/Q.713
Signalling point code encoding
3.4.2.2 Subsystem number
The subsystem number (SSN) identifies an SCCP user function and, when
provided, consists of one octet coded as follows:
Bit 8 7 6 5 4 3
s 2 1
0 0 0 0 0 0 SSN not known/not used
0 0
0 0 0 0 0 0 SCCP management
0 1
0 0 0 0 0 0 reserved for CCITT allocation
1 0
0 0 0 0 0 0 ISDN user part
1 1
0 0 0 0 0 1 OMAP
0 0
PAGE30 Fascicle VI.7 - Rec. Q.713
0 0 0 0 0 1 MAP (Mobile Application Part)
0 1
0 0 0 0 0 1 ü
1 0
to ì spare
1 1 1 1 1 1 Φ
1 0
1 1 1 1 1 1 reserved for expansion.
1 1
Network specific subsystem numbers should be assigned in descending order
starting with "11111110".
3.4.2.3 Global title4)
The format of the global title is of variable length. Figure 7/Q.913,
Figure 9/Q.713, Figure 10/Q.713 and Figure 11/Q.713 show four possible formats
for global title.
3.4.2.3.1 Global title indicator = 0001
8 7 6 5 4 3 2 1
O/E Nature of address indicator octet 1
Address information octet 2 and
further
FIGURE 7/Q.713
4) Incorporation of NSAP address in the SCCP global title is for further study.
Fascicle VI.7 - Rec. Q.713 PAGE1
Global title format for indicator 0001
Bits 1 to 7 of octet 1 contain the nature of address indicator and are
coded as follows:
Bit 7 6 5 4 3 2
s 1
0 0 0 0 0 0 spare
0
0 0 0 0 0 0 subscriber number
1
0 0 0 0 0 1 reserved for national use
0
0 0 0 0 0 1 national significant number
1
0 0 0 0 1 0 international number
0
0 0 0 0 1 0 ü
1
to ì spare
1 1 1 1 1 1 Φ
1
Bit 8 of octet 1 contains the odd/even indicator and is coded as follows:
Bit 8
0 even number of address signals
1 odd number of address signals
The octets 2 and further contain a number of address signals and possibly
PAGE30 Fascicle VI.7 - Rec. Q.713
a filler as shown in Figure 8/Q.713.
8 7 6 5 4 3 2 1
2nd address signal 1st address signal octet 2
4th address signal
3rd address
signaloctet 3
. . .
filler (if nth address signal octet m
necessary)
FIGURE 8/Q.713
Address information
Fascicle VI.7 - Rec. Q.713 PAGE1
Each address signal is coded as follows:
The application of these codes in actual networks is for further study. 0000
digit 0
0001 digit 1
0010 digit 2
0011 digit 3
0100 digit 4
0101 digit 5
0110 digit 6
0111 digit 7
1000 digit 8
1001 digit 9
1010 spare
1011 code 115)
1100 code 125)
1101 spare
1110 spare
1111 ST
In case of an odd number of address signals, a filler code 0000 is
inserted after the last address signal.
3.4.2.3.2 Global title indicator = 0010
Figure 9/Q.713 shows the format of the global title, if the global title
indicator equals "0010".
8 7 6 5 4 3 2 1
Translation type octet 1
Address information octet 2 and
further
FIGURE 9/Q.713
Global title format for indicator 0010
The translation type is a one-octet field that is used to direct the
message to the appropriate global title translation function.6) Thus, it may be
possible for the address information to be translated into different values for
and different combinations of DPCs, SSNs and GTs.
This octet will be coded "00000000" when not used. Translation types for
internetwork services will be assigned in ascending order starting with
00000001". Translation types for network specific services will be assigned in
descending order starting with "11111110". The code "11111111" is reserved for
expansion. However, the exact coding of translation types in the international
network is for further study. Additional requirements may be placed on this field
as a result of further work on Transaction Capabilities and the ISDN User Part.
In the case of this global title format (0010), the translation type may
also imply the encoding scheme, used to encode the address information, and the
numbering plan.
3.4.2.3.3 Global title indicator = 0011
8 7 6 5 4 3 2 1
Translation type octet 1
Numbering plan Encoding scheme octet 2
Address information
5) The application of these codes in actual networks is for further study.
6) A translation type may for instance imply a specific service to be provided by the SCCP
user, such as free phone number translation, or identify the category of service to be
provided, for example, dialed number screening, password validation or transmission of
digits to telephone network address.
PAGE30 Fascicle VI.7 - Rec. Q.713
octet 3 and
further
FIGURE 10/Q.713
Global title format for indicator 0011
The translation type is as described in S 3.4.2.3.2.
The numbering plan is encoded as follows7):
Bit 8 7 6
s 5
0 0 0 unknown
0
0 0 0 ISDN/Telephony Numbering Plan (Recommendations E.163 and
1 E.164)
0 0 1 spare
0
0 0 1 Data Numbering Plan (Recommendation X.121)
1
0 1 0 Telex Numbering Plan (Recommendation F.69)
0
0 1 0 Maritime Mobile Numbering Plan (Recommendations E.210, 211)
1
0 1 1 Land Mobile Numbering Plan (Recommendation E.212)
0
0 1 1 ISDN/Mobile numbering plan (Recommendation E.214)
1
1 0 0 ü
0
7) The support of all numbering plans is not mandatory.
Fascicle VI.7 - Rec. Q.713 PAGE1
to ì spare
1 1 1 Φ
0
1 1 1 reserved
1
The encoding scheme is encoded as follows:
Bit 4 3 2
s 1
0 0 0 unknown
0
0 0 0 BCD, odd number of digits
1
0 0 1 BCD, even number of digits
0
0 0 1 ü
1
to ì spare
1 1 1 Φ
0
1 1 1
PAGE30 Fascicle VI.7 - Rec. Q.713
1 reserved.
If the encoding scheme is binary coded decimal, the global title value,
starting from octet 3, is encoded as shown in Figure 8/Q.713.
3.4.2.3.4 Global title indicator = 0100
8 7 6 5 4 3 2 1
Translation type octet 1
Numbering plan Encoding scheme octet 2
Spa Nature of address indicator octet 3
re
Address information octet 4 and
further
FIGURE 11/Q.713
Global title format for indicator 0100
The field "translation type" is as described in S 3.4.2.3.2. The fields
"numbering plan" and "encoding scheme" are as described in S 3.4.2.3.3. The field
Snature of address indicator" is as described in S 3.4.2.3.1.
If the encoding scheme is binary coded decimal, the global title value,
starting from octet 4, is encoded as shown in Figure 8/Q.713.
3.5 Calling party address
The "calling party address" is a variable length parameter. Its structure
is the same as the "called party address".
When the calling party address is a mandatory parameter but is not
available or must not be sent, the calling party address parameter only consists
of the address indicator octet, where bits 1 to 7 are coded all zeros.
3.6 Protocol class
The "protocol class" parameter field is a four bit field containing the
protocol class.
Bits 1-4 are coded as follows:
4321
0000 class 0
0001 class 1
0010 class 2
0011 class 3
When bits 1-4 are coded to indicate a connection-oriented-protocol class
(class 2, class 3), bits 5-8 are spare.
Fascicle VI.7 - Rec. Q.713 PAGE1
When bits 1-4 are coded to indicate a connectionless protocol class (class
0, class 1), bits 5-8 are used to specify message handling as follows:
Bit 8 7 6
s 5
0 0 0 no special options
0
0 0 0 ü
1
to ì spare
0 1 1 Φ
1
1 0 0 return message on error
0
1 0 0 ü
1
to ì spare
1 1 1 Φ
1
3.7 Segmenting/reassembling
The "segmenting/reassembling" parameter field is a one octet field and is
structured as follows:
8 7 6
PAGE30 Fascicle VI.7 - Rec. Q.713
5 4 3 2 1
reserve M
Bits 8-2 are spare.
Bit 1 is used for the More Data indication and is coded as follows:
0 = no more data
1 = more data
3.8 Receive sequence number
The "receive sequence number" parameter field is a one octet field and is
structured as follows:
8 7 6 5 4 3 2 1
P(R) /
Bits 8-2 contain the receive sequence number P(R) used to indicate the
sequence number of the next expected message. P(R) is binary coded and bit 2 is
the LSB.
Bit 1 is spare.
Fascicle VI.7 - Rec. Q.713 PAGE1
3.9 Sequencing/segmenting
The sequencing/segmenting parameter field consists of two octets and is
structured as follows:
8 7 6 5 4 3 2 1
octet 1 P(S) /
octet 2 P(R) M
Bits 8-2 of octet 1 are used for indicating the send sequence number P(S).
P(S) is binary coded and bit 2 is the LSB.
Bit 1 of octet 1 is spare.
Bits 8-2 of octet 2 are used for indicating the receive sequence number
P(R). P(R) is binary coded and bit 2 is the LSB.
Bit 1 of octet 2 is used for the More Data indication and is coded as
follows:
0 = no more data
1 = more data
The sequencing/segmenting parameter field is used exclusively in protocol
class 3.
3.10 Credit
The "credit" parameter field is a one-octet field used in the protocol
classes which include flow control functions. It contains the window size value
coded in pure binary.
3.11 Release cause
The release cause parameter field is a one-octet field containing the
reason for the release of the connection.
The coding of the release cause field is as follows:
Bit 8 7 6 5 4 3 2
s 1
0 0 0 0 0 0 0 end user originated
0
0 0 0 0 0 0 0 end user congestion
1
PAGE30 Fascicle VI.7 - Rec. Q.713
0 0 0 0 0 0 1 end user failure
0
0 0 0 0 0 0 1 SCCP user originated
1
0 0 0 0 0 1 0 remote procedure error
0
0 0 0 0 0 1 0 inconsistent connection data
1
0 0 0 0 0 1 1 access failure
0
0 0 0 0 0 1 1 access congestion
1
0 0 0 0 1 0 0 subsystem failure
0
0 0 0 0 1 0 0 subsystem congestion8)
1
0 0 0 0 1 0 1 network failure
0
0 0 0 0 1 0 1 network congestion
1
0 0 0 0 1 1 0 expiration of reset timer
0
8) Subsystem congestion control procedure is for further study.
Fascicle VI.7 - Rec. Q.713 PAGE1
0 0 0 0 1 1 0 expiration of receive inactivity timer
1
0 0 0 0 1 1 1 not obtainable
0
0 0 0 0 1 1 1 unqualified
1
0 0 0 1 0 0 0 ü
0
to ì spare
1 1 1 1 1 1 1 Φ
1
Note - A more comprehensive list of causes covering X.96 call progress
information is for further study.
PAGE30 Fascicle VI.7 - Rec. Q.713
3.12 Return cause
In the Unitdata Service message, the ½return cause╗ parameter field is a
one octet field containing the reason for message return. Bits 1-8 are coded as
follows:
Bit 8 7 6 5 4 3 2
s 1
0 0 0 0 0 0 0 no translation for an address of such nature
0
0 0 0 0 0 0 0 no translation for this specific address
1
0 0 0 0 0 0 1 subsystem congestion9)
0
0 0 0 0 0 0 1 subsystem failure
1
0 0 0 0 0 1 0 unequipped user
0
0 0 0 0 0 1 0 network failure
1
0 0 0 0 0 1 1 network congestion
0
0 0 0 0 0 1 1 unqualified
1
0 0 0 0 1 0 0 ü
0
9) Subsystem congestion control procedure is for further study.
Fascicle VI.7 - Rec. Q.713 PAGE1
to ì spare
1 1 1 1 1 1 1 Φ
1
3.13 Reset cause
The "reset cause" parameter field is a one octet field containing the
reason for the resetting of the connection.
The coding of the reset cause field is as follows:
Bit 8 7 6 5 4 3 2
s 1
0 0 0 0 0 0 0 end user originated
0
0 0 0 0 0 0 0 SCCP user originated
1
0 0 0 0 0 0 1 message out of order - incorrect P(S)
0
0 0 0 0 0 0 1 message out of order - incorrect P(R)
1
0 0 0 0 0 1 0 remote procedure error - message out of window
0
0 0 0 0 0 1 0 remote procedure error - incorrect P(S) after
1 (re)initialization
0 0 0 0 0 1 1 remote procedure error - general
0
0 0 0 0 0 1 1
PAGE30 Fascicle VI.7 - Rec. Q.713
1 remote end user operational
0 0 0 0 1 0 0 network operational
0
0 0 0 0 1 0 0 access operational
1
0 0 0 0 1 0 1 network congestion
0
0 0 0 0 1 0 1 not obtainable
1
0 0 0 0 1 1 0 unqualified
0
0 0 0 0 1 1 0 ü
1
to ì spare
1 1 1 1 1 1 1 Φ
1
3.14 Error cause
The "error cause" parameter field is a one octet field containing the
indication of the exact protocol error.
The coding of the error cause field is as follows:
Bit 8 7 6 5 4 3 2
s 1
0 0 0 0 0 0 0
Fascicle VI.7 - Rec. Q.713 PAGE1
0 local reference number (LRN) mismatch - unassigned
destination LRN
0 0 0 0 0 0 0 local reference number (LRN) mismatch - inconsistent source
1 LRN
0 0 0 0 0 0 1 point code mismatch10)
0
0 0 0 0 0 0 1 service class mismatch
1
0 0 0 0 0 1 0 unqualified
0
0 0 0 0 0 1 0 ü
1
to ì spare
1 1 1 1 1 1 1 Φ
1
10) National option.
PAGE30 Fascicle VI.7 - Rec. Q.713
3.15 Refusal cause
The refusal cause parameter field is a one octet field containing the
reason for the refusal of the connection.
The coding of the refusal cause field is as follows:
Bit 8 7 6 5 4 3 2
s 1
0 0 0 0 0 0 0 end user originated
0
0 0 0 0 0 0 0 end user congestion
1
0 0 0 0 0 0 1 end user failure
0
0 0 0 0 0 0 1 SCCP user originated
1
0 0 0 0 0 1 0 destination address unknown
0
0 0 0 0 0 1 0 destination inaccessible
1
0 0 0 0 0 1 1 network resource - QOS not available/non-transient
0
0 0 0 0 0 1 1 network resource - QOS not available/transient
1
0 0 0 0 1 0 0 access failure
0
Fascicle VI.7 - Rec. Q.713 PAGE1
0 0 0 0 1 0 0 access congestion
1
0 0 0 0 1 0 1 subsystem failure
0
0 0 0 0 1 0 1 subsystem congestion11)
1
0 0 0 0 1 1 0 expiration of the connection establishment timer
0
0 0 0 0 1 1 0 incompatible user data
1
0 0 0 0 1 1 1 not obtainable
0
0 0 0 0 1 1 1 unqualified
1
0 0 0 1 0 0 0 ü
0
to ì spare
1 1 1 1 1 1 1 Φ
1
Note 1 - The inclusion of the routing failure causes as specified for the
"return cause" parameter in Recommendation Q.713, S 3.12, is for further study.
Note 2 - A more comprehensive list of causes covering CCITT Recommendation
X.96 call progress information is for further study.
3.16 Data
The "data" parameter field is a variable length field containing SCCP-user
data to be transferred transparently between the SCCP user functions.
4 SCCP messages and codes
4.1 General
11) Subsystem congestion control procedure is for further study.
PAGE30 Fascicle VI.7 - Rec. Q.713
4.1.1 In the following sections, the format and coding of the SCCP messages is
specified.
For each message a list of the relevant parameters is given in a tabular
form.
4.1.2 For each parameter the table also includes:
- a reference to the section where the formatting and coding of the
parameter content is specified;
- the type of the parameter. The following types are used in the tables:
F = mandatory fixed length parameter;
V = mandatory variable length parameter;
O = optional parameter of fixed or variable length;
- the length of the parameter. The value in the table includes:
- for type F parameters the length, in octets, of the parameter
content;
- for type V parameters the length, in octets, of the length
indicator and of the parameter content; (The minimum and the
maximum length are indicated.)
- for type O parameters the length, in octets, of the parameter name,
length indicator and parameter content. (For variable length
parameters the minimum and maximum length is indicated.)
4.1.3 For each message the number of pointers included is also specified.
4.1.4 For each message type, type F parameters and the pointers for the type V
parameters must be sent in the order specified in the following tables.
4.2 Connection request (CR)
The CR message contains:
- the routing label,
- 2 pointers,
- the parameters indicated in Table 3/Q.713.
4.3 Connection confirm (CC)
The CC message contains:
- the routing label,
- 1 pointer,
- the parameters indicated in Table 4/Q.713.
4.4 Connection refused (CREF)
The message contains:
- the routing label,
- 1 pointer,
- the parameters indicated in Table 5/Q.713.
4.5 Released (RLSD)
The RLSD message contains:
- the routing label,
- 1 pointer,
- the parameters indicated in Table 6/Q.713.
4.6 Release complete (RLC)
The RLC message contains:
- the routing label,
- no pointers,
- the parameters indicated in Table 7/Q.713.
4.7 Data form 1 (DT1)
Fascicle VI.7 - Rec. Q.713 PAGE1
The DT1 message contains:
- the routing label,
- 1 pointer,
- the parameters indicated in Table 8/Q.713.
4.8 Data form 2 (DT2)
The DT2 message contains:
- the routing label,
- 1 pointer,
- the parameters indicated in Table 9/Q.713.
TABLE 3/Q.713
Message type: Connection request
Parameter S Type (F V Length
O) (octets)
Message type code 2.1 F 1
Source local reference 3.3 F 3
Protocol class 3.6 F 1
Called party address 3.4 V 3 minimum
Credit 3.10 O 3
PAGE30 Fascicle VI.7 - Rec. Q.713
Calling party address 3.5 O 4 minimum
Data 3.16 O 3 - 130
End of optional parameters 3.1 O 1
TABLE 4/Q.713
Message type: Connection confirm
Parameter S Type (F V Length
O) (octets)
Message type 2.1 F 1
Destination local reference 3.2 F 3
Source local reference 3.3 F 3
Protocol class 3.6 F
Fascicle VI.7 - Rec. Q.713 PAGE1
1
Credit 3.10 O 3
Called party address 3.4 O 4 minimum
Data 3.16 O 3 - 130
End of optional parameter 3.1 O 1
TABLE 5/Q.713
Message type: Connection refused
Parameter S Type (F V Length
O) (octets)
Message type 2.1 F 1
Destination local reference 3.2 F 3
Refusal cause 3.15
PAGE30 Fascicle VI.7 - Rec. Q.713
F 1
Called party address 3.4 O 4 minimum
Data 3.16 O 3 - 130
End of optional parameter 3.1 O 1
TABLE 6/Q.713
Message type: Released
Parameter S Type (F V Length
O) (octets)
Message type 2.1 F 1
Destination local reference 3.2 F 3
Source local reference 3.3 F 3
Release cause
Fascicle VI.7 - Rec. Q.713 PAGE1
3.11 F 1
Data 3.16 O 3 - 130
End of optional parameter 3.1 O 1
PAGE30 Fascicle VI.7 - Rec. Q.713
TABLE 7/Q.713
Message type: Release complete
Parameter S Type (F V Length
O) (octets)
Message type 2.1 F 1
Destination local reference 3.2 F 3
Source local reference 3.3 F 3
TABLE 8/Q.713
Message type: Data form 1
Parameter S Type (F V Length
O) (octets)
Message type 2.1 F 1
Destination local reference 3.2 F 3
Segmenting/reassembling
Fascicle VI.7 - Rec. Q.713 PAGE1
3.7 F 1
Data 3.16 V 2 - 256
TABLE 9/Q.713
Message type: Data form 2
Parameter S Type (F V Length
O) (octets)
Message type 2.1 F 1
Destination local reference 3.2 F 3
Sequencing/Segmenting 3.9 F 2
Data 3.16 V 2 - 256
PAGE30 Fascicle VI.7 - Rec. Q.713
4.9 Data acknowledgement (AK)
The AK message contains:
- the routing label,
- no pointers,
- the parameters indicated in Table 10/Q.713.
TABLE 10/Q.713
Message type: Data acknowledgement
Parameter S Type (F V Length
O) (octets)
Message type 2.1 F 1
Destination local reference 3.2 F 3
Receive sequence number 3.8 F 1
Credit 3.10 F 1
4.10 Unitdata (UDT)
The UDT message contains:
- the routing label,
- 3 pointers,
- the parameters indicated in Table 11/Q.713.
TABLE 11/Q.713
Message type: Unitdata
Parameter
Fascicle VI.7 - Rec. Q.713 PAGE1
S Type (F V Length
O) (octets)
Message type 2.1 F 1
Protocol class 3.6 F 1
Called party address 3.4 V 3 minimum
Calling party address 3.5 V 2 minimum
Data 3.16 V 2 - X a)
a) Due to the ongoing studies on the SCCP called and calling party
address, the maximum length of this parameter needs further study. It
is also noted 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.
PAGE30 Fascicle VI.7 - Rec. Q.713
4.11 Unitdata service (UDTS)
The UDTS message contains:
- the routing label,
- 3 pointers,
- the parameters indicated in Table 12/Q.713.
TABLE 12/Q.713
Message type: Unitdata service
Parameter S Type (F V Length
O) (octets)
Message type 2.1 F 1
Return cause 3.12 F 1
Called party address 3.4 V 3 minimum
Calling party address 3.5 V 2 minimum
Data 3.16 V 2 - X a)
a) See a) Table 11/Q.713.
4.12 Expedited data (ED)
The ED message contains:
- the routing label,
Fascicle VI.7 - Rec. Q.713 PAGE1
- 1 pointer,
- the parameters indicated in Table 13/Q.713.
TABLE 13/Q.713
Message type: Expedited data
Parameter S Type (F V Length
O) (octets)
Message type 2.1 F 1
Destination local reference 3.2 F 3
Data 3.16 V 2 - 33
PAGE30 Fascicle VI.7 - Rec. Q.713
4.13 Expedited data acknowledgement (EA)
The EA message contains:
- the routing label,
- no pointers,
- the parameters indicated in Table 14/Q.713.
TABLE 14/Q.713
Message type: Expedited data acknowledgement
Parameter S Type (F V Length
O) (octets)
Message type 2.1 F 1
Destination local reference 3.2 F 3
4.14 Reset request (RSR)
The RSR message contains:
- the routing label,
- 1 pointer,
- the parameters indicated in Table 15/Q.713.
TABLE 15/Q.713
Message type: Reset request
Parameter S Type (F V Length
O) (octets)
Message type 2.1 F 1
Destination local reference
Fascicle VI.7 - Rec. Q.713 PAGE1
3.2 F 3
Source local reference 3.3 F 3
Reset cause 3.13 F 1
PAGE30 Fascicle VI.7 - Rec. Q.713
4.15 Reset confirm (RSC)
The RSC message contains:
- the routing label,
- no pointers,
- the parameters indicated in Table 16/Q.713.
TABLE 16/Q.713
Message type: Reset confirmation
Parameter S Type (F V Length
O) (octets)
Message type 2.1 F 1
Destination local reference 3.2 F 3
Source local reference 3.3 F 3
4.16 Protocol data unit error (ERR)
The ERR message contains:
- the routing label,
- 1 pointer,
- the parameters indicated in Table 17/Q.713.
TABLE 17/Q.713
Message type: Protocol data unit error
Parameter S Type (F V Length
O) (octets)
Message type
Fascicle VI.7 - Rec. Q.713 PAGE1
2.1 F 1
Destination local reference 3.2 F 3
Error cause 3.14 F 1
PAGE30 Fascicle VI.7 - Rec. Q.713
4.17 Inactivity test (IT)
The IT message contains:
- the routing label,
- no pointers,
- the parameters indicated in Table 18/Q.713.
TABLE 18/Q.713
Message type: Inactivity test
Parameter S Type (F V Length
O) (octets)
Message type 2.1 F 1
Destination local reference 3.2 F 3
Source local reference 3.3 F 3
Protocol class 3.6 F 1
Sequencing/segmenting a) 3.9 F 2
Credit a) 3.10 F
Fascicle VI.7 - Rec. Q.713 PAGE1
1
a) Information in these parameter fields reflect those values sent
in the last data Form 2 or Data acknowledgement message. They are
ignored if the protocol class parameter indicates class 2.
5 SCCP Management messages and codes
5.1 General
Management (SCMG) messages are
carried using the connectionless service of the SCCP. When
transferring SCMG messages, class 0 is requested with the "discard
message on error" option. SCCP management message parts are
provided in the "data" parameter of the Unitdata message.
The Unitdata message contains:
- the routing label,
- 3 pointers,
- the parameters indicated in Table 19/Q.713.
Descriptions of the various parts are contained in the following sections.
TABLE 19/Q.713
SCCP management message format
Parameter S Type (F V Length
O) (octets)
Message type 2.1 F 1
(= Unitdata)
Protocol class 3.6 F 1
(= Class 0, no return)
Called party address 3.4 V 3 minimum
(SSN = SCCP management)
Calling party address 3.5 V 3 minimum a)
(SSN = SCCP management)
Data 3.16 V 6
(Data consists of an SCMG
message with form as in Table
22/Q.713)
PAGE30 Fascicle VI.7 - Rec. Q.713
a) SSN is always present.
5.1.1 SCMG format identifier
The SCMG format identifier consists of a one-octet field, which is
mandatory for all SCMG messages. The SCMG format identifier uniquely defines the
function and format of each SCMG message. The allocation of SCMG format
identifiers is shown in Table 20/Q.713.
TABLE 20/Q.713
SCMG format identifiers
Message Code 87654321
SSA Subsystem-Allowed 00000001
SSP Subsystem-Prohibited 00000010
SST Subsystem-Status-Test 00000011
SOR Subsystem-Out-of-Service-Request 00000100
SOG Subsystem-Out-of-Service-Grant 00000101
Fascicle VI.7 - Rec. Q.713 PAGE1
5.1.2 Formatting principles
The formatting principles used for SCCP messages, as described in SS 1.3,
1.4, 1.5, 1.6, 2.2 and 2.3 apply to SCMG messages.
5.2 SCMG message parameters
SCMG parameter name codes are given in Table 21/Q.713 with reference to
the subsections in which they are described. Presently, these parameter name
codes are not used since all SCMG messages contain mandatory fixed parameters
only.
TABLE 21/Q.713
SCMG parameter name codes
Parameter name S Parameter name
code 87654321
End of optional parameters 5.2.1 00000000
Affected SSN 5.2.2 00000001
Affected PC 5.2.3 00000010
Subsystem multiplicity indicator 5.2.4 00000011
5.2.1 End of optional parameters
The "end of optional parameters" parameter field consists of a single
octet containing all zeros.
5.2.2 Affected SSN
The "affected subsystem number (SSN)" parameter field consists of one
octet coded as directed for the called party address field, S 3.4.2.1.
5.2.3 Affected PC
The "affected signalling point code (PC)" parameter field is represented
by two octets which are coded as directed for the called party address field, S
3.4.2.2.
5.2.4 Subsystem multiplicity indicator
The "subsystem multiplicity indicator" parameter field consists of one
octet coded as shown in Figure 12/Q.713.
8 7 6 5 4 3 2 1
spare
PAGE30 Fascicle VI.7 - Rec. Q.713
SMI
FIGURE 12/Q.713
Subsystem multiplicity indicator format
Fascicle VI.7 - Rec. Q.713 PAGE1
The coding of the SMI field is as follows:
Bits 21
00 affected subsystem multiplicity unknown
01 affected subsystem is solitary
10 affected subsystem is duplicated
11 spare
Bits 3-8 are spare.
5.3 SCMG messages
Presently, all SCMG messages contain mandatory fixed parameters only. Each
SCMG message contains:
- 0 pointers
- the parameters indicated in Table 22/Q.713.
TABLE 22/Q.713
SCMG Message
Parameter S Type (F V Length
O) (octets)
SCMG format identifier 5.1.1 F 1
(Message type code)
Affected SSN 5.2.2 F 1
Affected PC 5.2.3 F 2
Subsystem multiplicity 5.2.4 F 1
indicator
ANNEX A
(to Recommendation Q.713)
Mapping for cause parameter values
A.1 Introduction
During connection refusal/release/reset, the SCCP and its users could take
necessary corrective actions, if any, only upon relevant information available to
them. Thus, it would be very helpful if those information could be conveyed
correctly.
During connection release, the "release cause" parameter in the Released
(RLSD) message and the N-DISCONNECT primitive (with parameters "originator" and
"reason") are used together to convey those information on the initiator and the
cause of the connection release. In addition, the N-DISCONNECT primitive is also
used together with the "refusal cause" parameter in the Connection Refused (CREF)
message to convey those information during connection refusal. During connection
reset, the "reset cause" parameter in the Reset Request (RSR) message and the
N-RESET primitive (with parameters "originator" and "reason") are used together
similarly.
In order to convey those information correctly, this Annex provides a
guideline for the mapping of values between the cause parameters and the
corresponding N-primitive parameters during various scenarios.
PAGE30 Fascicle VI.7 - Rec. Q.713
A.2 Connection refusal
Table A-1/Q.713 describes the mapping of values between the "refusal
cause" parameter (S 3.15, Rec. Q.713) and the "originator", "reason" parameters
in the N-DISCONNECT primitive (S 2.1.1.2.4, Rec. Q.711).
A.3 Connection release
Table A-2/Q.713 describes the mapping of values between the "release
cause" parameter (S 3.11, Rec. Q.713) and the "originator", "reason" parameters
in the N-DISCONNECT primitive (S 2.1.1.2.4, Rec. Q.711).
A.4 Connection reset
Table A-3/Q.713 describes the mapping of values between the "reset cause"
parameter (S 3.13, Rec. Q.713) and the "originator", "reason" parameters in the
N-RESET primitive (S 2.1.1.2.3, Rec. Q.711).
TABLE A-1/Q.713
Mapping during connection refusal
CREF Message N-DISCONNECT primitive
Code Refusal cause Reason Originat
or
00000000 end user originated connection refusal - end user NSU
originated
00000001 end user congestion connection refusal - end user NSU
congestion
00000010 end user failure connection refusal - end user NSU
failure
00000011 SCCP user originated connection refusal - SCCP NSU
user originated
00000100 destination address unknown connection refusal - NSP
destination address unknown
(non-transient condition)
00000101 destination inaccessible connection refusal -
Fascicle VI.7 - Rec. Q.713 PAGE1
destination NSP
inaccessible/transient
condition
00000110 network resource - QOS connection refusal - QOS NSP a)
unavailable/non-transient unavailable/non-transient
condition
00000111 network resource - QOS connection refusal - QOS NSP a)
unavailable/transient unavailable/transient
condition
00001000 access failure connection refusal - access NSU
failure
00001001 access congestion connection refusal - access NSU
congestion
00001010 subsystem failure connection refusal - NSP
destination
inaccessible/non-transient
condition
00001011 subsystem congestion connection refusal - NSU
subsystem congestion
00001100 expiration of connection connection refusal - reason NSP a)
estimated timer unspecified/transient
00001101 inconsistent user data connection refusal -
PAGE30 Fascicle VI.7 - Rec. Q.713
incompatible information in NSU
NSDU
00001110 not obtainable connection refusal - reason NSP a)
unspecified/transient
00001110 not obtainable connection refusal - undefine
undefined d
00001111 unqualified connection refusal - reason NSP a)
unspecified/transient
00001111 unqualified connection refusal - undefine
undefined d
NSU Network Service User
NSP Network Service Provider
a) Only those cases will be applicable if the SCCP originates the refusal procedure in
response to REQUEST interface element.
TABLE A-2/Q.713
Mapping during connection release
RLSD Message N-DISCONNECT primitive
Code Release cause Reason Originat
or
00000000 end user originated disconnection - normal NSU
condition
00000001 end user congestion disconnection - end user
Fascicle VI.7 - Rec. Q.713 PAGE1
congestion NSU
00000010 end user failure disconnection - end user NSU
failure
00000011 SCCP user originated disconnection - SCCP user NSU
originated
00000100 remote procedure error disconnection - abnormal NSP
condition of transient nature
00000101 inconsistent connection data disconnection - abnormal NSP
condition of transient nature
00000110 access failure disconnection - access NSU
failure
00000111 access congestion disconnection - access NSU
congestion
00001000 subsystem failure disconnection - abnormal NSP
condition of non-transient
nature
00001001 subsystem congestion disconnection - subsystem
PAGE30 Fascicle VI.7 - Rec. Q.713
congestion NSU
00001010 network failure disconnection - abnormal NSP
condition of non-transient
nature
00001011 network congestion disconnection - abnormal NSP
condition of transient nature
00001100 expiration of reset timer disconnection - abnormal NSP
condition of transient nature
00001101 expiration of receive disconnection - abnormal NSP
inactivity timer condition of transient nature
00001110 not obtainable a) disconnection - undefined NSP
00001110 not obtainable a) disconnection - undefined undefine
d
00001111 unqualified disconnection - abnormal NSU
condition
00001111 unqualified disconnection - undefined
Fascicle VI.7 - Rec. Q.713 PAGE1
NSP
00001111 unqualified disconnection - undefined undefine
d
NSU Network Service User
NSP Network Service Provider
a) The need for this value is for further study.
TABLE A-3/Q.713
Mapping during connection reset
RSR Message N-RESET primitive
Code Reset cause Reason Originat
or
00000000 end user originated reset - user synchronization NSU
00000001 SCCP user originated reset - user synchronization NSU
00000010 message out of order - reset - unspecified NSP
incorrect P(S)
00000011 message out of order - reset - unspecified NSP
incorrect P(R)
00000100 remote procedure error - reset - unspecified NSP
message out of window
PAGE30 Fascicle VI.7 - Rec. Q.713
00000101 remote procedure error - reset - unspecified NSP
incorrect P(S) after
initialization
00000110 remote procedure error - reset - unspecified NSP
general
00000111 remote end user operational reset - user synchronization NSU
00001000 network operational reset - unspecified NSP
00001001 access operational reset - user synchronization NSU
00001010 network congestion reset - network congestion NSP
00001011 not obtainable a) reset - unspecified NSP
00001011 not obtainable a) reset - undefined undefine
d
00001100
Fascicle VI.7 - Rec. Q.713 PAGE1
unqualified reset - unspecified NSP
00001100 unqualified reset - undefined undefine
d
NSU Network Service User
NSP Network Service Provider
a) The need for this value is for further study.
PAGE30 Fascicle VI.7 - Rec. Q.713
