ETSI ETS 300 008-2 Annex A
Description: OpenSS7 SS7 ETSI PICS Proforma.
I am still working on these... Most of the Level 2 information has been
filled in, but I am still working on filling in the Level 3 information.
Annex A (normative): PICS proforma for ETS 300 008-1
Notwithstanding the provisions of the copyright clause related to the text
of this ETS, ETSI grands that users of this ETS may freely reproduce the
PICS proforma in this annex so that it can be used for its intended
purposes and may further publish the completed PICS.
A.1 Guidance for completing the PICS proforma
A.1.1 Purpose and structure
The purpose of this PICS proforma is to provide a mechanism whereby a
supplier of an implementation of the requirement define in ETS 300 008-1
[1] may provide information about the implementation in a standardized
manner.
The PICS proforma is subdivided into subclauses for the following
categories of information:
- guidance for completing the PICS proforma;
- identification of the implementation;
- identification of the ETS;
- global statement of conformance;
- capabilities.
A.1.2 Abbreviations and conventions
The PICS proforma contained in this annex is comprised of information in
tabular form in accordance with the guidelines presented in ISO/IEC 9646-7
[4].
- Item column
The item column contains a number which identifies the item in the table.
- Item description column
The item description column describes in free text each respective item
(e.g., parameters, timers, etc.). It implicitly means "is <item
description> supported by the implementation?".
- Status column
The following notations, defined in ISO/IEC 9646-7 [4], are used for the
status column:
| m |
mandatory - the capability is required to be supported |
| o |
optional - the capability may be supported or not |
| n/a |
not applicable - in the given context, it is impossible to use the
capability |
| x |
prohibited (excluded) - there is a requirement not to use this
capability in the given context |
| i |
out of scope ("i" stands for irrelevant) - this capability is
outside the scope of the given base standard and hence irrelevant and
not subject to conformance testing. No answer is requested from the
supplier |
| o.i |
qualified optional - for mutually exclusive or selectable options
from a set. "i" is an integer which identifies a unique group of
related optional items and the logic of their selection which is
defined immediately following the table |
| ci |
conditional - the requirement on the capability ("m", "o", "x" or
"n/a") depends on the support of other optional or conditional items.
"i" is an integer identifying an unique conditional status expression
which is defined immediately following the table |
- Reference column
The reference column make reference to ETS 300 008-1 [1], except where
explicitly stated otherwise.
- Support column
The support column shall be filled in by the supplier of the
implementation. The following common notations, defined in ISO/IEC 9646-7
[4], are used for the support column:
| Y or y |
supported by the implementation |
| N or n |
not supported by the implementation |
| N/A, n/a or - |
no answer required (allowed only if the status is n/a, directly or
after evaluation of a conditional status) |
If this PICS proforma is completed in order to describe a multiple-profile
support in a system, it is necessary to be able to answer that a
capability is supported for one profile and not supported for another. In
that case, the supplier shall enter the unique reference to a conditional
expression, preceded by "?" (e.g. ?3). This expression shall be given in
the space for comments provided at the bottom of the table. It uses
predicates defined in the SCS, each of which refers to a single profile
and which takes the value TRUE if and only if that profile is to be used.
EXAMPLE: ?3: IF prof1 THEN Y ELSE N
It is also possible to provide a comment to an answer in the space
provided at the bottom of the table.
NOTE: As state in ISO/IEC 9646-7 [4], support for a received PDU requires
the ability to parse all valid parameters of that PDU. Supporting a PDU
while having no ability to parse a valid paramter is non-conformant.
Support for a parameter on a PDU means that the semanitics of that
parameter are supported. Unless specifically convered by a table listing
PDU parameters and giving details regarding their status, all parameters
of a PDU are required to be fully supported on sending. Support of a PDU
therefore implies full support of all required PDU parameters.
- Values allowed column
The values allowed column contains the type, the list, the range, or the
length of values allowed. The following notations are used:
| - |
range of values: |
<min value> .. <max value>
example: 5 .. 20
|
| - |
list of values: |
<value1>, <value2>, ......., <valueN>
example: 2, 4, 6, 8, 9
example: `1101'B, `1011'B, `1111'B
example: `0A'H, `34'H, `2F'H
|
| - |
list of named values: |
<name1>(<val1>), <name2>(<val2>), ......., <nameN>(<valN>)
example: reject(1), accept(2)
|
| - |
length: |
size(<min size> .. <max size>)
example: size(1 .. 8)
|
- Values supported column
The values supported column shall be filed in by the supplier of the
implementation. In this column, the values or the ranges of values
supported by the implementation shall be indicated.
Reference to items
For each possible item answer (answer in the support column) within the
PICS proforma a unique reference exists, used, for example, in the
conditional expressions. It is defined as the table identifier, followed
by a solidus character "/", followed by the item number in the table. If
there is more than one support column in a table, the columns are
discriminated by letters (a, b, etc.), respectively.
| EXAMPLE 1: |
A.5/4 is the reference to the answer of item 4 in table 5 of annex A.
|
| EXAMPLE 2: |
A.6/3b is the reference to the second answer (i.e. in the second support
column) of item 3 in table 6 of annex A.
|
A.1.3 Instructions for completing the PIC proforma
The supplier of the implementation shall complete the PICS proforma in
each of the spaces provided. In particular, an explicit answer shall be
entered, in each of the support or supported column boxes provided, using
the notation described in subclause A.1.2.
If necessary, the supplier may provide additional comments in space at the
bottom of the tables, or separately on sheets of paper.
More detailed instructions are given at the beginning of the different
subclauses of the PICS proforma.
A.2 Identification of the Implementation
Identification of the Implementation Under Test (IUT) and the system in
which it resides (the System Under Test)) should be filled in so as to
provide as much detail as possible regarding version numbers and
configuration options.
The product supplier information and client information should both be
filled in if they are different.
A person who can answer queries regarding information supplied in the PICS
should be named as the contact person.
A.2.1 Date of the statement
| Date: |
Sun Oct 15 07:20:04 UTC 2000 |
A.2.2 Implementation Under Test (IUT) identification
| IUT name: |
OpenSS7 |
| IUT version: |
0.7.2 Prerelease1 |
A.2.3 System Under Test (SUT) identification
| SUT name: |
PC |
| Hardware configuration: |
AMD K6 - 350 MHz - Desktop PC |
| Operating system: |
RedHat 7.2 - Linux Kernel 2.4.18 |
A.2.4 Product supplier
A.2.5 Client (if different from product supplier)
A.2.6 RCS contact person
(A person to contact if there are any queries concerning the content of the
PICS)
A.3 Identification of the protocol
This PICS proforma applies to the following standard:
ETS 300 008-1 (1996): "Integrated Services Digital Network (ISDN);
Signalling System No. 7; Message Transfer Part (MTP) to support
international interconnection; Part 1: Protocol specification [ITU-T
Recommendations Q.701 (1993), Q.702 (1988), Q.703 to Q.706 (1993), Q.707
(1988) and Q.708 (1993), modified]".
A.4 Global statement of conformace
Are all mandatory capabilities implemented? (Yes/No): No
| NOTE: |
Anwering "No" to this question indicates non-conformance to the protocol
specification. Non-supported mandatory capabilities are to be identified
in the PICS, with an explanation of why the implementation is
non-conforming, on pages attached to the PICS proforma.
|
A.5 Capabilities
This clause contains the core of the PICS proforma for the MTP protocol, as
specified in ITU-T Recommendations or ETS 300 008-1 [1] where this modifies
the equivalent ITU-T Recommendations, for both MTP level 2 and MTP level 3.
The proforma are presented in the form of tables. Subclauses A.5.1 to A.5.10
contain the individual clauses of the PICS proforma.
A.5.1 Major capabilities - MTP level 2
The supplier of the implementation shall state whether or not the
(signalling) procedures for the MTP level 2 as specified in ITU-T
Recommendation Q.703 as modified by ETS 300 008-1 [1] are supported, in the
tables below.
Table A.1: Signal unit delimitation
| Item |
Procedure |
Reference |
Status |
Support |
| 1/0a |
Additional flags (sending) |
Q.703 - 3.1 |
o |
?1 |
| 1/0b |
Additional flags (receiving) |
Q.703 - 3.1 |
m |
?1 |
| 1/1 |
Zero insertion and deletion |
Q.703 - 3.2 |
m |
?1 |
Comments:
?1: IF acb56 THEN Y ELSE N
Support for these capabilities is dependent upon the hardware which is
used for the signalling link. Current support is only for the ACB56
hardware card.
Table A.2: Acceptance procedure
| Item |
Procedure |
Reference |
Status |
Support |
| 2/1 |
Acceptance of alignment |
Q.703 - 4.1 |
m |
?1 |
| 2/2 |
Error detection |
Q.703 - 4.2 |
m |
?1 |
Comments:
?1: IF acb56 THEN Y ELSE N
Support for these capabilities is dependent upon the hardware which is
used for the signalling link. Current support is only for the ACB56
hardware card.
Table A.3: Basic error correction method
| Item |
Procedure |
Reference |
Status |
Support |
| 3/1 |
Signal Unit Sequence Control |
Q.703 - 5.2.2 |
c031 |
Y |
| 3/2 |
Positive acknowledgement |
Q.703 - 5.2.3 |
c032 |
Y |
| 3/3 |
Negative acknowledgement |
Q.703 - 5.2.4 |
c032 |
Y |
| 3/4 |
Response to Acknowledgement |
Q.703 - 5.3.1 |
c032 |
Y |
| 3/5 |
Repetition of Message Signal Units |
Q.703 - 5.3.3 |
x |
Y(note 1) |
c031: IF A.4/1 THEN o ELSE m
c032: IF A.3/1 THEN m ELSE x
Comments:
Note 1: Repetition of MSUs is not provided even as a national option.
Table A.4: Error correction by preventative cyclic retransmission
| Item |
Procedure |
Reference |
Status |
Support |
| 4/1 |
Signal unit sequence control |
Q.703 - 6.2.2 |
c041 |
N |
| 4/1 |
Positive acknowledgement |
Q.703 - 6.2.3 |
c042 |
N |
| 4/1 |
Preventative cyclic retransmission |
Q.703 - 6.3 |
c042 |
N |
| 4/1 |
Forced retransmission |
Q.703 - 6.4 |
c042 |
N |
c041: IF A.3/1 THEN o ELSE m
c042: IF A.4/1 THEN m ELSE x
Comments:
Preventative cyclic retransmission is not supported in any form in the
0.7.2 Prerelease version of the OpenSS7 stack. PCR capabilities might be
added at a later date.
The protocol_variant sysctl has been provided on a
per-link basis for the activation of preventative cyclic retransmission
once it is made available in a release.
Table A.5: Initial alignment procedure
| Item |
Procedure |
Reference |
Status |
Support |
| 5/1 |
Initial alignment procedure |
Q.703 - 7.3 |
m |
Y |
| 5/2 |
Proving periods |
Q.703 - 7.4 |
m |
Y |
Comments:
These procedures are provided by the SS7 interface code for all drivers.
OpenSS7 does not yet have cards which provide SS7 MTP Level 2 on the card:
these functions are provided by the host. This conformance applies to all
card types.
Table A.6: level 2 flow control
| Item |
Procedure |
Reference |
Status |
Support |
| 6/1 |
Detection of congestion |
Q.703 - 9.2 |
m |
Y(note 1) |
| 6/2 |
Procedure in congestion situation |
Q.703 - 9.3 |
m |
Y |
| 6/3 |
Congestion abatement procedure |
Q.703 - 9.4 |
m |
Y(note 1) |
Comments:
Note 1:
Detection of receive congestion is implementation dependent. The OpenSS7
stack generic SS7 Interface driver provides for detection of receive
congestion. This is performed by the RB_Congestion_Function
in the file linux/drivers/net/ss7if_sm.c. This function sets
Congestion_Accept whenever a backlogged received SU occurs or
Congestion_Discard whenever two backlogged received SUs occur
or when the Linux packet scheduler is dropping network packets (i.e.
netdev_dropping is set).
Congestion abates whenever the backlog drops below 1 received SU and the
Linux packet scheduler is not dropping (i.e. netdev_dropping
is clear).
This function does not check RB (Receive Buffer) occupancy, but rather
checks the number of backlogged SUs between the actual hardware and the
SS7 MTP Level 2 state machines.
Table A.7: Signalling link error monitoring
| Item |
Procedure |
Reference |
Status |
Support |
| 7/1 |
Signalling unit error rate monitor |
Q.703 - 10.2 |
m |
?1 |
| 7/2 |
Alignment error rate monitor |
Q.703 - 10.3 |
m |
?1 |
Comments:
?1: IF acb56 THEN Y ELSE N
Support for these capabilities is dependent upon the hardware which is used
for the signalling link. Current support is only for the ACB56 hardware
card.
Although the SS7 Link state machines implemented in software are capable
of performing the functions of the SUERM and AERM as specified in Q.703,
proper operation depends upon Octet Counting Mode capabilities provided by
the hardware device and driver. Current support is only for the ACB56
hardware card.
Table A.8: Processor outage
| Item |
Procedure |
Reference |
Status |
Support |
| 8/1 |
Remote processor outage beginning |
Q.703 - 8 |
m |
Y |
| 8/2 |
Remote processor outage end |
Q.703 - 8 |
m |
Y |
| 8/3 |
Local processor outage beginning |
Q.703 - 8 |
o (note) |
N(note 1) |
| 8/4 |
Local processor outage end |
Q.703 - 8 |
c081 |
N(note 1) |
|
NOTE: This option is implementation dependent.
|
c081: IF A.8/3 THEN m ELSE n/a
Comments:
Note 1:
Local processor outage is not detected. This is because the SS7 Level 2
state machines are running on the same processor as the SS7 Level 3 state
machines. Should this change (e.g. Level 2 state machines are run on the
interface card) 8/3 and 8/4 may be supported in a later release.
Mechanisms have bee provided to send and receive LPO primitives.
Local processor outage procedures have been implemented in the SS7 Level 2
state machines; however, there is currently no mechanism for detecting a
local processor outage as described above. For the purposes of
conformance testing, it is possible to simulate a local processor outage
condition using the Linux packet_socket opened
directly on the link being tested.
A.5.2 Major capabilities - MTP level 3
The supplier of the implementation shall state whether or not the
(signalling) procedures for the MTP level 3 as specified in ITU-T
Recommendations Q.701 and Q.704 as modified by ETS 300 008-1 [1] are
supported, in the tables below:
Table A.9: Signalling message handling
| Item |
Procedure |
Reference |
Status |
Support |
| 9/1 |
Message routing function |
Q.704 - 2.3 |
m |
Y |
| 9/2 |
Message discrimination function |
Q.704 - 2.4.1 |
m |
Y |
| 9/3 |
STP functionality |
Q.704 - 2.4.1 |
o |
?1 |
| 9/4 |
Message distribution function |
Q.704 - 2.4.2 |
m |
Y |
| 9/5 |
Quasi-associated mode of signalling |
Q.704 - 3.1.2 |
o |
Y |
Comments:
?1: IF transfer_function THEN Y ELSE N
Note: STP functionality is provided for any MTP signalling point in the
implementation which has the sysctl transfer_function
set; if this sysctl is not set, then the STP functionality is not provided
for that signalling point.
The quasi-associated mode of signalling is always supported.
Table A.10: Signalling network management
| Item |
Procedure |
Reference |
Status |
Support |
| 10/1 |
Signalling link failure |
Q.704 - 3.3.1 |
m |
Y |
| 10/2 |
Signalling link restoration |
Q.704 - 3.3.2 |
m |
Y |
| 10/3 |
Signalling link deactivation |
Q.704 - 3.3.3 |
m |
Y |
| 10/4 |
Signalling link activation |
Q.704 - 3.3.4 |
m |
Y |
| 10/5 |
Signalling link blocking |
Q.704 - 3.3.5 |
m |
Y |
| 10/6 |
Signalling link unblocking |
Q.704 - 3.3.6 |
m |
Y |
| 10/7 |
Signalling link inhibiting |
Q.704 - 3.3.7 |
m |
Y |
| 10/8 |
Signalling link uninhibiting |
Q.704 - 3.3.8 |
m |
Y |
| 10/9 |
Signalling route restricted |
Q.704 - 3.5.3 |
x |
Y |
| 10/10 |
Signalling route unavailable |
Q.704 - 3.5.1 |
m |
Y |
| 10/11 |
Signalling route available |
Q.704 - 3.5.2 |
m |
Y |
| 10/12 |
Signalling point unavailable |
Q.704 - 3.7.1 |
m |
Y |
| 10/13 |
Signalling point available |
Q.704 - 3.7.2 |
m |
Y |
| 10/14 |
Signalling point congested |
Q.704 - 3.7.3 |
o (note) |
Y |
| 10/15 |
Procedures used in connection with link congestion status changes |
Q.704 - 3.8.3 |
m |
Y |
| 10/16 |
Congestion status of signalling route sets |
Q.704 - 3.8.4 |
m |
Y |
| 10/17 |
Procedures used in connection with route set congestion status changes |
Q.704 - 3.8.5 |
m |
Y |
|
NOTE: This option is implementation dependent.
|
Comments:
The implementation of 10/14 is based on the Linux packet scheduler. The
Linux packet scheduler has a net_dropping flag which
is set when the system receive packet backlog is greater than a system
configurable number (default 300). This value is set to ensure that the
packet scheduler congests before CPU processing power is sacrificed. The
net_dropping flag is built into the link receive
congestion detection algorithm so that links go into receive congestion
when this backlog is exceeded. This invokes the normal procedures of
congestion accept and congestion discard.
Table A.11: Signalling traffic management
| Item |
Procedure |
Reference |
Status |
Support |
| 11/1 |
Normal routing situation |
Q.704 - 4.2 |
m |
Y |
| 11/2 |
Signalling link unavailability |
Q.704 - 4.3 |
m |
Y |
| 11/3 |
Signalling link availability |
Q.704 - 4.4 |
m |
Y |
| 11/4 |
Signalling route unavailability |
Q.704 - 4.5 |
m |
Y |
| 11/5 |
Signalling route availability |
Q.704 - 4.6 |
m |
Y |
| 11/6 |
Signalling route restriction |
Q.704 - 4.7 |
x |
Y |
| 11/7 |
Signalling point availability |
Q.704 - 4.8 |
m |
Y |
Comments:
Table A.12: Changeover
| Item |
Procedure |
Reference |
Status |
Support |
| 12/1 |
Changeover initiation and actions |
Q.704 - 5.3 |
m |
Y |
| 12/2 |
Buffer updating procedures |
Q.704 - 5.4 |
m |
Y |
| 12/3 |
Retrieval and diversion of traffic |
Q.704 - 5.5 |
m |
Y |
| 12/4 |
Emergency changeover procedures |
Q.704 - 5.6 |
m (note) |
Y |
| 12/5 |
Procedures in abnormal conditions |
Q.704 - 5.7 |
m |
Y |
|
NOTE: The invocation of this procedure may be implementation dependent.
|
Comments:
In this intial implementation (0.7.2), there are few instances where MTP
L3 is incapable of retreiving buffers and FSNC from the link. None of
this information is retained in the link processor, but is retained in the
L3 processor (because we don't have an L2 processor yet). As a result,
the current implementation is always capable of performing a normal
changeover unless another problem exists (e.g. run out of kernel memory).
In future implementations of OpenSS7, where the L2 processor is actually a
separate processor from the L3 processor, different implementation
dependent conditions may cause the need for an emergency changeover
procedure.
Table A.13: Changeback
| Item |
Procedure |
Reference |
Status |
Support |
| 13/1 |
Changeback initiation and actions |
Q.704 - 6.2 |
m |
Y |
| 13/2 |
Sequence control procedures |
Q.704 - 6.3 |
m |
Y |
| 13/3 |
Time-controlled procedure |
Q.704 - 6.4 |
m |
Y |
| 13/4 |
Changeback between linksets always uses time controlled procedures |
Q.704 - 6.2.5 |
o |
Y |
| 13/5 |
Changeback - abnormal conditions |
Q.704 - 6.5 |
m |
Y |
Comments:
Table A.14: Forced rerouting
| Item |
Procedure |
Reference |
Status |
Support |
| 14/1 |
Force rerouting initiation and actions |
Q.704 - 7.2 |
c141 |
?1 |
c141: if A.9/4 THEN m ELSE n/a
Comments:
?1: IF transfer_function THEN Y ELSE n/a
Note: when the sysctl transfer_function is set for the
signalling point, the forced rerouting procedures are automatically
supported; otherwise, the procedures are not applicable.
Table A.15: Controlled rerouting
| Item |
Procedure |
Reference |
Status |
Support |
| 15/1 |
Controlled rerouting initiation and actions |
Q.704 - 8.2 |
c151 |
?1 |
c151: if A.9/5 THEN m ELSE n/a
Comments:
?1: IF transfer_function THEN Y ELSE n/a
Note: when the sysctl transfer_function is set for the
signalling point, the controlled rerouting procedures are automatically
supported; otherwise, the procedures are not applicable.
Table A.16: MTP restart
| Item |
Procedure |
Reference |
Status |
Support |
| 16/1 |
Actions in a restarting signalling point (having the transfer function) |
Q.704 - 9.2.1, 9.2.2, 9.2.4 |
c161 |
? |
| 16/2 |
Actions in a restarting signalling point (having no transfer function) |
Q.704 - 9.2.1, 9.2.3, 9.2.4 |
c162 |
? |
| 16/3 |
Actions in a signalling point X adjacent to a restarting signalling point |
Q.704 - 9.3 |
m |
? |
| 16/4 |
Short term isolations |
Q.704 - 9.4 |
m |
? |
| 16/5 |
Actions in signalling point X on receipt of unexpected TRA message. |
Q.704 - 9.5 |
m |
? |
| 16/6 |
All signalling routes to be allowed on restart in restarting node |
Q.704 - 9.6.1 |
m |
? |
| 16/7 |
All signalling routes through restarted adjacent node allowed unless TFPs
have been received |
Q.704 - 9.6.2 |
c164 |
? |
| 16/8 |
Handling of signalling route set test messages |
Q.704 - 9.6.3 |
c161 |
? |
| 16/9 |
Handling of late link restorations or TFA reception in phase 2 after
sending TFPs |
Q.704 - 9.6.4 1st sentence |
c161 |
? |
| 16/10 |
Handling of late link restorations or TFA reception in phase 2 before
sending TFPs (see note) |
Q.704 - 9.6.4 2nd sentence |
c163 |
? |
| 16/11 |
Linkset failures or TFP reception in phase 2 are handled (within or after
restart) |
Q.704 - 9.6.4 3rd sentence |
c161 |
? |
| 16/12 |
Availability of adjacent node through receipt of TFA or TRA |
Q.704 - 9.6.5 |
c164 |
? |
| 16/13 |
Discarding of messages during restart |
Q.704 - 9.6.6 |
m |
? |
| 16/14 |
Discarding of messages in adjacent point |
Q.704 - 9.6.7 |
m |
? |
| 16/15 |
Co-ordination of different MTP networks during restart |
Q.704 - 9.6.8 |
o |
? |
|
NOTE: Comments on the implementation of this option should be given.
|
c161: IF A.9/3 THEN m ELSE n/a
c162: IF A.9/3 THEN n/a ELSE m
c163: IF A.9/3 THEN o ELSE n/a
c164: IF A.9/3 THEN m ELSE n/a
Comments:
MTP restart procedures are still being implemented at this time.
This PICS Proforma table will be completed when implementation
in the stack have been completed.
Table A.17: Management inhibiting
| Item |
Procedure |
Reference |
Status |
Support |
| 17/1 |
Inhibiting initiations and actions |
Q.704 - 10.2 |
m |
? |
| 17/2 |
Unihibiting initiations and actions |
Q.704 - 10.3 |
m |
? |
| 17/3 |
Receipt of unexpected management inhibition messages |
Q.704 - 10.4 |
m |
? |
| 17/4 |
Management inhibited link status and processor recovery |
Q.704 - 10.5 |
m |
? |
| 17/5 |
Inhibit test procedure |
Q.704 - 10.6 |
m |
? |
Comments:
Management inhibiting procedures are still being implemented at this time.
This PICS Proforma table will be completed when implementation
in the stack have been completed.
Table A.18: Signailling traffic flow control
| Item |
Procedure |
Reference |
Status |
Support |
| 18/1 |
Signalling routeset unavailability |
Q.704 - 11.2.1 |
m |
Y |
| 18/2 |
Signalling routeset availability |
Q.704 - 11.2.2 |
m |
Y |
| 18/3 |
Count on message |
Q.704 - 11.2.3.1 |
o.1 |
Y |
| 18/4 |
Count on octet |
Q.704 - 11.2.3.1 |
o.1 |
N |
| 18/5 |
for the congested routeset |
Q.704 - 11.2.3.1 |
o.2 |
Y |
| 18/6 |
for any link of the congested routeset |
Q.704 - 11.2.3.1 |
o.2 |
N |
| 18/7 |
for any linkset of the congested routeset |
Q.704 - 11.2.3.1 |
o.2 |
N |
| 18/8 |
for any congested link of the congested routeset |
Q.704 - 11.2.3.1 |
o.2 |
N |
| 18/9 |
User Part unavailability control - sending UPU |
Q.704 - 11.2.7 |
o |
Y |
| 18/10 |
User Part availability control - receiving UPU |
Q.704 - 11.2.7 |
m |
Y |
o.1: One, and only one option shall be chosen
o.2: One, and only one option shall be chosen
Comments:
The international network procedures for signalling traffic flow control
are still being implemented; however, it is intended that the per-message
and per routeset procedures will be chosen.
Table A.19: Signalling link management
| Item |
Procedure |
Reference |
Status |
Support |
| 19/1 |
Basic siginalling link management procedures |
Q.704 - 12.2 |
m |
Y |
| 19/2 |
Signalling link management procedures based on automatic allocation of
signalling terminals |
Q.704 - 12.3 |
x |
Y |
| 19/3 |
Signalling link management procedures based on automatic allocation of
signalling data links and signalling terminals |
Q.704 - 12.4 |
x |
Y |
| 19/4 |
Automatic allocation of signalling terminals |
Q.704 - 12.5 |
x |
Y |
| 19/5 |
Automatic allocation of signalling data links |
Q.704 - 12.6 |
x |
Y |
| 19/6 |
Different signalling link management procedures at the two ends of a link
set |
Q.704 - 12.7 |
x |
Y |
|
NOTE: Items 19/2 and 19/4 have no protocol relevance.
|
Comments:
Note: automatic allocation of signalling data terminals and signalling
data links has not been implemented for any protocool variant profile to
this date.
Table A.20: Signalling route management
| Item |
Procedure |
Reference |
Status |
Support |
| 20/1a |
Transfer prohibited |
Q.704 - 13.2.1, 13.2.2 |
c201 |
Y |
| 20/1b |
Transfer prohibited |
Q.704 - 13.2.3, 13.2.4 |
c202 |
Y |
| 20/2a |
Transfer allowed |
Q.704 - 13.3.1, 13.3.2 |
c201 |
Y |
| 20/2b |
Transfer allowed |
Q.704 - 13.3.3, 13.3.4 |
c202 |
Y |
| 20/3 |
Transfer restricted (national option) |
Q.704 - 13.4 |
x |
?1 |
| 20/4 |
Signalling-route-set-test |
Q.704 - 13.5 |
c202 |
Y |
| 20/5 |
Transfer controlled (international network) |
Q.704 - 13.6 |
c203 |
? |
| 20/6 |
Transfer controlled (national option with congestion priorities) |
Q.704 - 13.7 |
x |
? |
| 20/7 |
Transfer controlled (national option without congestion priorities) |
Q.704 - 13.8 |
x |
? |
| 20/8 |
Signalling-route-set-congestion-test (national option) |
Q.704 - 13.9 |
x |
Y |
c201: IF A.9/3 THEN m ELSE x
c202: IF A.9/3 THEN m ELSE n/a
c203: IF A.9/3 THEN m ELSE o
Comments:
?1: IF transfer_restricted THEN N ELSE Y
Implementation is still proceding on international transfer controlled
behaviour; this PICS table will be completed once implementation is
complete.
A.5.3 Timers used in MTP level 2
The supplier of the implementation shall state whether or not the following
timers, used by the MTP level 2 protocol, as specified in ITU-T Recommendation
Q.703 as modified by ETS 300 008-1 [1] are supported and their values or
range(s), in the table below:
Table A.21: Timers - MTP level 2
| Item |
Timer |
Reference |
Status |
Support |
Values allowed |
Values supported |
| 21/1 |
T1(64) |
Q.703 - 12.3 |
m |
Y |
40 - 50 s |
4000 .. 5000 ms |
| 21/2 |
T1(4.8) |
Q.703 - 12.3 |
n/a |
n/a |
500 - 600 s |
- |
| 21/3 |
T2low |
Q.703 - 12.3 |
n/a |
n/a |
5 - 50 s |
- |
| 21/4 |
T2high |
Q.703 - 12.3 |
n/a |
n/a |
70 - 150 s |
- |
| 21/5 |
T3 |
Q.703 - 12.3 |
m |
Y |
1 - 2 s |
1000 .. 2000 ms |
| 21/6 |
T4n(64) |
Q.703 - 12.3 |
m |
Y |
7,5 - 9,5 s |
7500 .. 9500 ms |
| 21/7 |
T4n(4.8) |
Q.703 - 12.3 |
n/a |
n/a |
100 - 120 s |
- |
| 21/8 |
T4e(64) |
Q.703 - 12.3 |
m |
Y |
400 - 600 ms |
400 .. 600 ms |
| 21/9 |
T4e(4.8) |
Q.703 - 12.3 |
n/a |
n/a |
6 - 8 s |
- |
| 21/10 |
T5 |
Q.703 - 12.3 |
m |
Y |
80 - 120 ms |
80 .. 120 ms |
| 21/11 |
T6(64) |
Q.703 - 12.3 |
m |
Y |
3 - 6 s |
3000 .. 6000 ms |
| 21/12 |
T6(4.8) |
Q.703 - 12.3 |
n/a |
n/a |
8 - 12 s |
- |
| 21/13 |
T7(64) |
Q.703 - 12.3 |
m |
Y |
0,5 - 2 s |
500 .. 2000 ms |
| 21/14 |
T7(4.8) |
Q.703 - 12.3 |
n/a |
n/a |
4 - 6 s |
- |
Comments:
Timer ranges, minimums and maximums are as proscribed.
(Timers are not implemented for 4.8 kbit/s operation as 4.8 kbit/s
operation is not supported at this time.)
Timers are only accurate to plus or minus 10 milliseconds. Timer duration
values can only be assigned in 10 millisecond increments (on Linux PC hardware).
A.5.4 Timers used in MTP level 3
The supplier of the implementation shall state whether or not the following
timers, used by the MTP level 3 protocol, as specified in ITU-T Recommendation
Q.704 as modified by ETS 300 008-1 [1] are supported and their values or
range(s), in the table below:
Table A.22: Timers - MTP level 3
| Item |
Timer |
Reference |
Status |
Support |
Values allowed |
Values supported |
| 22/1 |
T1 |
Q.704 - 16.8 |
m |
Y |
500 - 1200 ms |
500 .. 1200 ms |
| 22/2 |
T2 |
Q.704 - 16.8 |
m |
Y |
700 - 2000 ms |
700 .. 2000 ms |
| 22/3 |
T3 |
Q.704 - 16.8 |
c222 |
Y |
500 - 1200 ms |
500 .. 1200 ms |
| 22/4 |
T4 |
Q.704 - 16.8 |
m |
Y |
500 - 1200 ms |
500 .. 1200 ms |
| 22/5 |
T5 |
Q.704 - 16.8 |
m |
Y |
500 - 1200 ms |
500 .. 1200 ms |
| 22/6 |
T6 |
Q.704 - 16.8 |
c222 |
Y |
500 - 1200 ms |
500 .. 1200 ms |
| 22/7 |
T7 |
Q.704 - 16.8 |
n/a |
n/a |
1 - 2 s |
- |
| 22/8 |
T8 |
Q.704 - 16.8 |
c221 |
?1 |
800 - 1200 ms |
800 .. 1200 ms |
| 22/9 |
T9 |
Q.704 - 16.8 |
n/a |
n/a |
- |
- |
| 22/10 |
T10 |
Q.704 - 16.8 |
c222 |
Y |
30 - 60 s |
30 .. 60 s |
| 22/11 |
T11 |
Q.704 - 16.8 |
n/a |
n/a |
30 - 90 s |
- |
| 22/12 |
T12 |
Q.704 - 16.8 |
m |
Y |
800 - 1500 ms |
800 .. 1500 ms |
| 22/13 |
T13 |
Q.704 - 16.8 |
m |
Y |
800 - 1500 ms |
800 .. 1500 ms |
| 22/14 |
T14 |
Q.704 - 16.8 |
m |
Y |
2 - 3 s |
2 .. 3 s |
| 22/15 |
T15 |
Q.704 - 16.8 |
n/a |
n/a |
2 - 3 s |
- |
| 22/16 |
T16 |
Q.704 - 16.8 |
n/a |
n/a |
1.4 - 2 s |
- |
| 22/17 |
T17 |
Q.704 - 16.8 |
m |
Y |
800 - 1500 ms |
800 .. 1500 ms |
| 22/18 |
T19 |
Q.704 - 16.8 |
c221 |
?1 |
implementation dependent & < T20 |
0 .. 58.90 s |
| 22/19 |
T19 |
Q.704 - 16.8 |
m |
Y |
67 - 69 s |
67 .. 69 s |
| 22/20 |
T20 |
Q.704 - 16.8 |
m |
Y |
59 - 61 s |
59 .. 61 s |
| 22/21 |
T21 |
Q.704 - 16.8 |
m |
Y |
63 - 65 s |
63 .. 65 s |
| 22/22 |
T22 |
Q.704 - 16.8 |
m |
Y |
3 - 6 min |
3 .. 6 min |
| 22/23 |
T23 |
Q.704 - 16.8 |
m |
Y |
3 - 6 min |
3 .. 6 min |
| 22/24 |
T24 |
Q.704 - 16.8 |
n/a |
n/a |
500 ms |
- |
c221: IF A.9/3 THEN m ELSE n/a
c222: IF A.9/5 THEN m ELSE n/a
Comments:
?1: IF transfer_function THEN Y ELSE n/a
A.5.5 Messages used in MTP level 2
The supplier of the implementation shall state whether or not the
following messages, used by the MTP level 2 protocol, as specified in
ITU-T Recommendation Q.701 and Q.703 as modified by ETS 300 008-1 [1] are
supported, in the table below:
The supplier shall indicate the status of support for sending and
receiving each message.
Table A.23: Messages - MTP level 2
| Item |
Message |
Reference |
Sending
Status |
Sending
Support |
Receipt
Status |
Receipt
Support |
| 23/1 |
FISU |
Q.703 - 2 |
m |
Y |
m |
Y |
| 23/2 |
LSSU with 1 octet SF size |
Q.703 - 2 |
o.3 |
Y |
m |
Y |
| 23/3 |
LSSU with 2 octets SF size |
Q.703 - 2 |
o.3 |
N |
m |
Y |
| 23/4 |
MSU |
Q.703 - 2 |
m |
Y |
m |
Y |
o.3: At least one option shall be chosen.
Comments:
Table A.24: Treatment of spare fields
| Item |
Procedure |
Reference |
Status |
Support |
| 24/1 |
Spare fields/subfields handling |
Q.701 - 6.2 |
m |
Y |
Comments:
A.5.6 Messages used in MTP level 3
The supplier of the implementation shall state whether or not the
following messages, used by the MTP level 3 protocol, as specified in
ITU-T Recommendation Q.701 and Q.704 as modified by ETS 300 008-1 [1] are
supported, in the table below:
The supplier shall indicate the status of support for sending and
receiving each message.
Table A.25: Messages - MTP level 3
| Item |
Message |
Reference |
Sending
Status |
Sending
Support |
Receipt
Status |
Receipt
Support |
| 25/1 |
COO |
Q.704 - 15.4 |
m |
Y |
m |
Y |
| 25/2 |
COA |
Q.704 - 15.4 |
m |
Y |
m |
Y |
| 25/3 |
CBD |
Q.704 - 15.5 |
m |
Y |
m |
Y |
| 25/4 |
CBA |
Q.704 - 15.5 |
m |
Y |
m |
Y |
| 25/5 |
ECO |
Q.704 - 15.6 |
m |
Y |
m |
Y |
| 25/6 |
ECA |
Q.704 - 15.6 |
m |
Y |
m |
Y |
| 25/7 |
RST |
Q.704 - 15.10 |
c254 |
Y |
c251 |
?1 |
| 25/8 |
RSR |
Q.704 - 15.10 |
x |
Y |
x |
Y |
| 25/9 |
TFC |
Q.704 - 15.15 |
c252 |
Y |
m |
Y |
| 25/10 |
TFP |
Q.704 - 15.7 |
c253 |
Y |
c254 |
Y |
| 25/11 |
TFR |
Q.704 - 15.9 |
x |
Y |
x |
Y |
| 25/12 |
TFA |
Q.704 - 15.8 |
c253 |
Y |
c254 |
Y |
| 25/13 |
RCT |
Q.704 - 15.16 |
x |
Y |
x |
Y |
| 25/14 |
LIN |
Q.704 - 15.11 |
o |
? |
m |
? |
| 25/15 |
LUN |
Q.704 - 15.11 |
m |
? |
m |
? |
| 25/16 |
LIA |
Q.704 - 15.11 |
o |
? |
m |
? |
| 25/17 |
LUA |
Q.704 - 15.11 |
m |
? |
m |
? |
| 25/18 |
LID |
Q.704 - 15.11 |
m |
? |
m |
? |
| 25/19 |
LFU |
Q.704 - 15.11 |
m |
? |
m |
? |
| 25/20 |
LLT |
Q.704 - 15.11 |
o |
? |
m |
? |
| 25/21 |
LRT |
Q.704 - 15.11 |
c256 |
? |
m |
? |
| 25/22 |
TRA |
Q.704 - 15.12 |
m |
? |
m |
? |
| 25/23 |
DLC |
Q.704 - 15.13 |
x |
Y |
x |
Y |
| 25/24 |
CSS |
Q.704 - 15.14 |
x |
Y |
x |
Y |
| 25/25 |
CNS |
Q.704 - 15.15 |
x |
Y |
x |
Y |
| 25/26 |
CNP |
Q.704 - 15.15 |
x |
Y |
x |
Y |
| 25/27 |
UPU |
Q.704 - 15.17 |
c255 |
Y |
m |
Y |
c251: if A.9/3 THEN m ELSE n/a
c252: if A.9/3 THEN m ELSE o
c253: if A.9/3 THEN m ELSE x
c254: if A.9/5 THEN m ELSE n/a
c255: if A.18/9 THEN m ELSE n/a
c256: if A.25/16 THEN m ELSE o
Comments:
?1: IF transfer_function THEN Y ELSE n/a
Note: Link management functions and messages have yet to be implemented;
this PICS Proforma table will be completed when implementation is
complete.
Table A.26: Treatment of spare fields
| Item |
Procedure |
Reference |
Status |
Support |
| 26/1 |
Spare fields/subfields handling |
Q.701 - 6.2 |
m |
Y |
Comments:
A.5.7 Testing and maintenance procedures
A.5.7.1 Major capabilities in testing and maintenance procedures
The supplier of the implementation shall state whether or not the
procedures described in ITU-T Recommendation Q.707 as modified by ETS 300
008-1 [1] are supported, in the table below.
Table A.27: Testing and maintenance procedures
| Item |
Procedure |
Reference |
Status |
Support |
| 27/1 |
Signalling link testing (periodic) |
Q.707 - 2 |
m |
Y |
| 27/2 |
Signalling link testing after activation or restoration |
Q.707 - 2 |
m |
Y |
| 27/3 |
Responding to signalling test message |
Q.707 - 2 |
m |
Y |
| 27/4 |
Signalling link goes out of service when the periodic test signal fails |
Q.707 - 2 |
m |
Y |
|
NOTE: Specify the IUT behaviour if not supported.
|
Comments:
A.5.7.2 Timers used in testing and maintenance procedures
The supplier of the implementation shall state whether or not the
following timers, used by MTP testing and maintenance procedures, as
specified in ITU-T Recommendation Q.707 as modified by ETS 300 008-1 [1],
are supported and their values or range, in the table below:
Table A.28: Timers - Testing and maintenance procedures
| Item |
Timer |
Reference |
Status |
Support |
Values allowed |
Values supported |
| 28/1 |
T1 |
Q.707 - 5.5 |
m |
Y |
4 - 12 s |
4 .. 12 s |
| 28/2 |
T2 |
Q.707 - 5.5 |
c281 |
Y |
30 - 90 s |
30 .. 90 s |
c281: IF A.27/1 THEN m ELSE n/a
Comments:
A.5.7.3 Messages used in testing and maintenance procedures
The supplier of the implementation shall state whether or not the messages
used by MTP testing and maintenance procedures as specified in ITU-T
Recommendation Q.707 as modified by ETS 300 008-1 [1] are supported, in
the table below:
The supplier shall indicate the status of support for sending and
receiving each message.
Table A.29: Messages - Testing and maintenance procedures
| Item |
Message |
Reference |
Sending
Status |
Sending
Support |
Receipt
Status |
Receipt
Support |
| 29/1 |
SLTM |
Q.707 - 5.4 |
m |
Y |
m |
Y |
| 29/2 |
SLTA |
Q.707 - 5.4 |
m |
Y |
m |
Y |
Comments:
A.5.8 Protocol error handling
The supplier of the implementation shall state whether or not the protocol
error handling functions for MTP as specified specified in ITU-T
Recommendation Q.701 as modified by ETS 300 008-1 [1] are supported, in
the table below:
Table A.30: Invalid messages for MTP3
| Item |
Procedure |
Reference |
Status |
Support |
| 30/1 |
Messages containing an unallocated SIO value |
Q.701 - 6.1.1 |
o |
Y |
| 30/2 |
Messages containing an unallocated H0/H1 code |
Q.701 - 6.1.2 |
m |
Y |
| 30/3 |
Messages containing an unallocated value in a recognized field |
Q.701 - 6.1.3 |
m |
Y |
Comments:
A.5.9 Transit time requirements
This paragraph deals with the requirements described in ITU-T
Recommendation Q.706 as modified by ETS 300 008-1 [1] about message
transfer time.
Table A.31: Security requirements
| Item |
Procedure |
Reference |
Status |
Support |
| 31/1 |
Type of security arrangements |
Q.706 - 4.5.1 |
o |
N |
| 31/2 |
Time to initiate changeover |
Q.706 - 4.5.2 |
o |
N |
| 31/3 |
Changeover performance times |
Q.706 - 4.5.3 |
o |
N |
Comments:
Table A.32: Priorities
| Item |
Procedure |
Reference |
Status |
Support |
| 32/1 |
Priorities requirements |
Q.706 - 4.7 |
o |
N |
Comments:
Table A.33: Estimates for message transfer times
| Item |
Procedure |
Reference |
Status |
Support |
| 33/1 |
Estimates for Tcs |
Q.706 - 5.1 |
o |
N |
| 33/2 |
Estimates for STP processor handling time Tph |
Q.706 - 5.3 |
o |
N |
Comments:
A.5.10 Interworking requirements
This subclause deals with interworking (with CCITT Yellow (1980), Red (1984)
and Blue (1988) Books) problems described in ITU-T Recommendation Q.701 as
modified by ETS 300 008-1 [1].
Table A.34: CCITT Red Book (1984) to ITU-T White Book (1993)
| Item |
Procedure |
Reference |
Status |
Support |
| 34/1 |
Solution to the SIF length increase problem |
Q.701 - 7.2.5/6 |
x |
N |
Comments:
Table A.35: CCITT Yellow Book (1980) to ITU-T White Book (1993)
| Item |
Procedure |
Reference |
Status |
Support |
| 35/1 |
Solution to the SIF length increase problem |
Q.701 - 7.2.5/6 |
x |
N |
Comments: